🔒 Locked

Aim Low, Shoot Often

Started by rypyr Apr 13, 2007 at 2:06 PM 7 replies 1.9k views

Original Post

Apr 13, 2007 at 2:06 PM

I've had my share of game projects that have started and stopped. Generally speaking, the "stopping" is because I usually dig myself too deep, try to design my own engine, try to make everything architecturally perfect, and in fact, never get to actually building the game (just the infrastructure, so to speak). A couple years ago, I changed my philosophy to one that aligns with "Agile Programming" techniques (without really knowing that is what you call it). That is, short "bursts" or "runs" of development that accomplish some specific (usually observable) goals. This philosophy fits in well with my lack of spare time, since I am a full-time employee doing less interesting software work as well as a full-time dad, etc. I simply cannot commit to a huge project, I need to see some very visible gains every few weeks. Maybe you can summarize my philosophy as "aim low, shoot often". In the process of setting shorter and very specific goals, I've also learned how to adapt and use other people's software/libraries (as opposed to building everything I need from scratch). Sometimes that's the only way to get something done in the timeframe I give myself. Since adapting my approach, I've created some reasonable successful web applications and browser game demos (in my own eyes) and it's given me something to point to and say "Look, I built this". It's led me to start collaborating with a friend on a simple casual PC game that we can work on together using the same development philosophy. The main goals are always in sight, and the first priority is to "get it working" as opposed to "designing the architecture perfectly". It's led to warts and the occasional re-factoring, but so far, we've stayed roughly on track (ok, we had to give ourselves an extra week one run so that we could each do our taxes). What do people think about this? I'm a software engineer by day, so this type of philosophy rubs my "perfectionist" and "architect" side the wrong way, but at the same time I realize that I just don't have the resources (time and money) to invest in a lot of up-front software design for these hobby projects. Especially when it's such a small team of one or two people. Incremental improvements, baby steps, seems to be the only way I can make advances in my hobby development. I'm curious to hear what other people have experienced/learned...

deepsender

Apr 13, 2007 at 3:15 PM

If you go to the Grand Canyon, will you take a 3-day hike to the base and back, or will take a 2-hour helicopter tour? Either way, you'll have something to show your friends when you get done. But, what did you really get out of the trip?

Programming for a hobbyist is kind of like that. I struggle with it too. For a year and a half, I wrote a flight sim using Windows GDI, and finally I moved my development to OpenGL. I felt comfortable doing this only after I wrote my own code for nearly all 3D graphics operations.

But you know what, I spent last Christmas with my Brother and he played my flight sim, and he couldn't stop. He was laughing and having a great time while his wife and I put a jigsaw puzzle together. Call me crazy, but watching him enjoy my game for 2 hours was worth the 1.5 years of toil.

As a hobbyist, whatever path you take is the right one for you.

JasonBlochowiak

Apr 13, 2007 at 3:18 PM

You sort of make it sound like refactoring is a bad thing - it's not. Refactoring frequently indicates that you know more now than when the code was first written. If you're a relative beginner, you should frequently be improving your understanding of the problem domain, and so you should frequently be able to apply your new understanding.

rypyr

Apr 13, 2007 at 3:30 PM

No, I didn't mean to imply that refactoring is a bad thing at all. In case it wasn't clear, I'm a believer in getting it working first, before getting it architecturally perfect - at least for hobby programming.

But it seems to me there's a difference between refactoring some code because an architectural solution is now clearer and writing code in the first place that you know will be reworked later.

pinacolada

Apr 13, 2007 at 3:59 PM

I agree with you totally, and I think a lot of hobbyist programmers go through the same thing. All us programmers are perfectionists to some degree, and when there's no boss breathing down our necks, there's nothing to stop us from rewriting our foundation classes for the 3rd time.

I think that in terms of educational value, you get the most education from the last 10% of a project. That's when you do the polish, the final bug fixes, and the delivery. The last 10% is also when you can look back on all your foundation code and evaluate it. Did your engine really serve your game's needs? Did the final product have a lot of hard-to-fix bugs, and could you have changed your development process to reduce bugs? And of course, having other people actually play your game is both educating and motivating.

If you never make it to that last 10% because you burnt yourself out on rewriting engine code for the 50th time (something I'm very guilty of), then you're denying yourself all those valuable lessons. So I'd much rather have a finished small game than an unfinished large game.

I believe in writing good code, but there's a flip side to the "write good code" coin. The flip side is that your customer will never actually see your code, they only see the final product. The world doesn't end if you leave some imperfect code in there :)

Oluseyi

Apr 13, 2007 at 4:34 PM

Quote:
Original post by pinacolada
All us programmers are perfectionists to some degree...

I pretty much agree with everything else you said. This, though, I take exception to.

The vast majority of programmers are neither skilled nor perfectionists. They're merely incompetent. The reason they are reluctant to use infrastructural code written by others is not because they want a perfectly baroque architecture - though that's the excuse they'll use - but because understanding someone else's code is frequently hard, especially if you have to do deep integration such as may be needed between a graphics renderer and a physics solver under the supervision of a simulation engine, only activated when certain options are toggled. Oh, yeah, and the physics solver gets a simplified version of the object geometry, too.

Most libraries are written in such a fashion that certain operations, outside the bounds of the most common scenarios envisioned by the authors, require redundant invocations and manual parsing or data conversion. Particularly in statically typed, monolithically compiled languages like C++, where imbuing intelligence in the code to figure out the expected parameters/type and automatically convert the requisite values is all but impossible. (Okay, I put "all but" in there just to placate the C++ jocks. It's impossible, since the language [natively] lacks support for introspection and reflection.)

So in addition to making a "Frankengame," from a code perspective, use a prototyping-friendly language, which typically means a dynamically, strongly typed, interpreted or bytecode compiled language with strong bindings to C or C++ so that you can optimize inner loops (after profiling) once you have things working properly.

Now, it may seem like I was quick to jump down your throat. I apologize. Most programmers suck, but most software developers are perfectionists, and I think that's what you were really trying to say. (I make the distinction on the grounds that a software developer designs as well as codes, and does all the things necessary to accomplish sound design - refactoring, tools investigation/usage/authoring, code reviews, prototyping, documentation, etc.)

Happy hacking! [smile]

rypyr

Apr 13, 2007 at 4:59 PM

Quote:
Original post by Oluseyi
The vast majority of programmers are neither skilled nor perfectionists. They're merely incompetent. The reason they are reluctant to use infrastructural code written by others is not because they want a perfectly baroque architecture - though that's the excuse they'll use - but because understanding someone else's code is frequently hard, especially if you have to do deep integration

Oluseyi, speak for yourself :P While I agree with you that integration with other people's code is indeed hard, I don't think it was because I was incompetent or afraid to do it. In fact, in some cases I consciously did realize that using software (let's say an XML parser library) would have been easier than writing my own (i.e. a configuration file parser).

I think the reason I didn't like using code was actually because I love to create - software is about the creation process for me (i.e. the artistic side of writing code coupled with the satisfaction of implementing a logical design). If I ended up using somebody else's engine, well then I had lost an opportunity to create/design - and that usually was enough to convince me that other people's library designs weren't good enough for me.

I admit that this was an arrogant and unrealistic stance to take. Arrogant because I'm not the best coder that ever lived. Unrealistic because of the scope vs. resources problem in hobby game development.

Since that time I think I've overcome my arrogance and realized just how much good and free software there is out there to use. And on the flip-side, it also made me realize that good software design does not necessarily translate into a good software application. And vice versa. Mozilla is a perfect example here: really overly designed and too-complicated software architecture, but in the end they turned it into a good application (Firefox). If you contribute to Mozilla you know what I mean! ;)

Sirisian

Apr 13, 2007 at 6:37 PM

I've stopped trying to program large engines. I'm a minor perfectionist when it comes to how I code, so I always look for the best way to do things that don't seem like a hack job. This can be hard when you have like 20k LOC and you find out a better way to do things.

I just build tech demos now and small engine frameworks. This helps me to quickly find better ways to accomplish things. It also makes my code a lot more usable. If I want to make a game with 2D line of sight, I just find my 2D LOS demo, and such.

I've broken my huge engine and it's infinite complexity into tons of parts and I keep tackling the math and goals one at a time. This has allowed me to progress at a fast rate than jumbling with a huge engine. Oluseyi used a good word, "Frankengame". That's exactly what you don't want to program.

zedz

Apr 13, 2007 at 10:31 PM

Quote:
Original post by rypyr In case it wasn't clear, I'm a believer in getting it working first, before getting it architecturally perfect - at least for hobby programming.

very very important, a game should be playable within a day.

also often an idea which in your head/on paper is great in reality sucks once youve coded it up

do the easy stuff first ( low hanging fruit ).

only code something if its necessary, ie ont code something that maybe useful later on

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.