Lessons Learned Hobby Game Development

Very good article - thanks for that.

I agree with everything, but as a hobby programmer you can spend too much time on the tools. Sometimes a text file is perfectly capable for the job. Unless you're going to release the modding tools for the engine to the public, good documentation may be sufficient in most cases when dealing with text files.

Good to see someone go through with such a large project - so congratulations.

cya

Ah very good article.

I would love to see what you ended up with for your heirachy for organising the various subsystems, out of interest.

Also, what would you recommend to make tools? I'm really only well versed in SDL/C++/OpenGL "game loop", so I'm wondering where to start with "windows" type applications (although, not Win32, preferrably something more open source and cross platformable). Any suggestions?

The various points you make certainly ring home with me and my experiences. As a newbie-intermediate, I really appreciate this article.

I hope to see a followup.

Dan

Quote:

Original post by Zeophlite Also, what would you recommend to make tools? I'm really only well versed in SDL/C++/OpenGL "game loop", so I'm wondering where to start with "windows" type applications (although, not Win32, preferrably something more open source and cross platformable). Any suggestions?

Yes, I was curious too. What software did you use to create your GUI tools? Qt, MFC, Visual Basic, Win32???

Thanks for the article.

Quote:

If you have any comments, please reach me at grafalgar at gmail dot com. I look forward to any feedback!

The writer of the article seems to be welcoming any feedback so you'd probably have better luck replying there (at his email which he gives at the beginning). Probably easier than using this thread, although others may be interested in the same questions. Just a thought.

Cheers
-Scott

Hi All,

Since this is my "first article" I completely forgot about the discussion threads :) So, I'll be happy to take questions here and through email, depending on your choice.

Anyhow, regarding tools and how long it takes to make them:

Yes, sometimes it is just faster to make a text file to describe a level, or a game object or something, but as long as you treat it in the same light as "throwaway code" in the sense that once you have all the surrounding systems implemented, throw away the text file and implement a proper tool for it.

I say that because it's very easy to fall into the trap of "this works, so lets keep it as is" - and pretty soon you'll find yourself with hundreds of different text files all doing slightly different things with slightly different formats.

Even though it'll take me that much longer to make a game when concentrating on tools, the end result is usually me being able to make more games faster.

My dad once said something interesting to me: "If you write a program to do X, other people will do X five times before you're done. But, when you are done, you'll be able to do X ten times before they do it once."

Now, I also agree - don't spend too much time on tools to where you never actually build a game. That's also an extreme to watch out for. That will fall under my one point of "too much forethought". It's a tricky balance, but the way I approached it is to implement one "big" feature at a time in my tool that my game needed, and then I continued working on the game. So the tool and the game sorta grew with each other.

Regarding what I used to build the tool:

I used C#, for a couple of reasons:

* I absolutely love C# and all the surrounding libraries. Microsoft did an awesome job with that, and I have to hand it to them. The language is ridiculously easy to use, I can rapidly prototype features in the tool without having to fudge around obtuse Win32 or MFC features, and the online support is phenomenal. I used to program a lot of small Win32 apps using MFC, and I still have the scars to show for it.

* Cross-platform tools is a very small concern for me. My development machine is a Windows box, and I don't see that changing anytime soon. The tools is perfectly capable of exporting for other platforms, it just doesn't need to run on any of them :)

* When I first built the tool, I was going to write a complete in-engine tool. Meaning, all GUI controls were going to run through my engine. It took me about a week to get a nice button to appear on screen that would take input and respond. I realized that if I was going to build an in-engine tool it was going to take forever, and I played around with C# a bit. The rest is, how you, history ;)

* C#'s XML serialization/deserialization is awesome. I have not seen anything quite so simple to use. I wrote a COLLADA importer in one evening using C#'s XML Serialization libs. That little bit alone has helped me save tons of time while building out the tool.

The engine itself is written in C++, and I hooked my engine's render routines into the editor for a WYSIWYG viewport.

Finally, I seem to be having trouble saving a jpg out of Visio. When that's sorted out I'll post a pic of the engine hierarchy.

Here's the engine hierarchy:



Note, I did not build a class hierarchy - though I really should for some of the "important" systems, like rendering and such. To me, however, it's much more beneficial to stick with a bigger-picture "architecture" than trying to design out individual classes / functions / etc for the full system before you start coding.

So looking at the above picture, the GUI uses the Render engine, as does Particles. However, GUI does not (in any way) use Particles. Similarly, the Render engine has zero knowledge of particles or the GUI system.

In this way, I could theoretically swap out the Render Engine for "something else" and neither GUI nor Particles will be the wiser.

I should also mention that after a couple of years of using the engine I've decided for a slight tweak of the engine hierarchy in that I want to put "Core" at the top, and have other systems use it instead of the other way around.

In other words, Core" knows about every system: Render, Particles, Physics, etc. I'm thinking about making it so that Core knows about nothing, but all other systems knows about it, and registers themselves to the Core. I think that will require a little more thought before I go through with it, as it has the potential of severely borking the entire setup :)

First, I thought the article was fantastic. A lot of what you said mirrors my experience with hobbyist game development. I don't tend to go quite as far in the reuse direction as you because I'm not really inclined to make a large number of games, but those are still good points to consider. Just had one bit of experience that I thought I'd share relating to this:

Quote:

Original post by Grafalgar I say that because it's very easy to fall into the trap of "this works, so lets keep it as is" - and pretty soon you'll find yourself with hundreds of different text files all doing slightly different things with slightly different formats.

I realized that I was starting to do this too, where I had a bunch of different files describing different things, and they all had their own different, hard-coded formats that were a royal pain to add to or change. Some of these were even output by my tools (a disaster in their own right, but that's another story), but I realized pretty quickly that things were going to get out of hand once I started defining weapons and units in external files for easier tweaking.

My solution was a single class that could read in a flexible file format and provide the data to almost all of the different systems of my game. I didn't go with XML because I had used that for the GUI and frankly regretted it. It was way more overhead than I needed for the relatively simple things I was trying to do. Now, pretty much everything in my game uses this class to read in external data and I count it among the best decisions I've made so far. It's not the most efficient thing in the world, but it works well enough that I'm even using it to load model files (for the moment, there will probably come a time when I need something faster but I haven't reached that point yet).

Anyway, I see this as something that could actually complement your tools-based system since tools have to output data in some format that the engine can read, and having it all in a somewhat unified format makes life so much easier. Since it's ASCII-based, it also has been helpful debugging my tools because I can easily see when they're outputting incorrect data.

Hi!

Excellent article! To avoid re-writting/dumping all of ones code I highly recommend reading the book "Refactoring" from Martin Fowler published by Adisson Wesly.

If one applies the principles of refactoring, one can save alot of time. Basically, refactoring is re-writting-on-the-fly. You can think of it this way.... if you view code as a loan and not fixing things as you go, your debt builds up to the point where you just can't pay down the debt anymore and you have to go bankrupt and start over. sorry for the run-on sentence.

Excellent article!

Thanks

Thanks for the very well written article! I like how you provide anecdotes from your own experience to demonstrate your points.

The only bit of advice that I mildly disagree with is "don't be afraid to rewrite." Sometimes you *should* be afraid to rewrite. Old code usually has been well debugged, and it's easy to reintroduce those bugs in the new code if you aren't careful. Also your return on time invested must be considered as a factor in your decision to rewrite. I'm guilty here; I've rewritten many lines of code that were working just because I didn't feel like they were of high enough quality, didn't fit in "grand scheme," or for whatever other reason that struck my fancy that day. In the end though, there was no real improvement to the application from the users' standpoints-- I had neglected to work on features that would add value.

On the other hand, if you determine that the code needs some of that TLC AND if there aren't any squeekier wheels, go ahead and give it a greasing.

smr, I'd argue that such refactoring is solely for the benefit of the developer and not the end user, although neglecting to work on value-adding features is another sticky problem in itself ;)

Nice article, good to know I'm not the only one that struggles through some of this, particularly the "Too much forethought will kill you". Every time I lay down code I get stuck thinking "is this going to be flexible 6 months from now, and what "might" it need to do". I finally pushed it out of my mind over the weekend and have just moved ahead with what I have so others can pick it up and start working with it. If its garbage, we re-write (man I hope this isn't the case) since we're all aware it's a moving target, but when this type of design is etched into your brain (slight perfectionist :)) it's tough to swallow it, push it aside and keep moving forward.

Oh and congratulations on the engine, I'm anxious for the day I see mine up and rendering via client calls and doing what it's "told to do".

Quote:

Original post by smr Old code usually has been well debugged, and it's easy to reintroduce those bugs in the new code if you aren't careful. Also your return on time invested must be considered as a factor in your decision to rewrite.

Be very careful of that. Assuming that "old code" is "good code" is a very dangerous trap to fall into.

While it may be true that old code tends to be well-debugged and 'proven', it does not mean that it's well-thought-out, or that it actually fits in the bigger-plan, or more specifically: that it's keeping up with new developments and changing assumptions in your engine. Do not also forget code-rot: tweaks, fixes and features over time that bloat and destabilize the original system.

I have seen way too many projects where old code keeps tagging along because it's perfect and proven, and no-one dare touch it. While the rest of the engine grows, that part stays stagnant, with all of its inherent issues.

You are, of course, correct on the the return-on-time-invested. If it's going to take a year to do a rewrite and the benefits are minor then that's a choice you have to make.

Rewrites should not be taken lightly, but resisting a rewrite because of the "old code = good code" assumption is very (very) dangerous. At the end of the day, it is up to you to decide whether or not its worth it.

congrats for ur work... sorry if somebody else asked, but are you planning to sell your engine? or are you planning to share it in a way developers could help you improve it or something like that?

Nice article. All of your lessons ring true with me, especially about the importance of separation of game and engine. That's probably the most important lesson I've learned since I started hobbyist game development.

Also, one other comment. As with nemebean I use a have migrated to a simple, common format for my game's ASCII files. I recommend it even if you're going to go on and write fancier editors later, because it will simplify development of your editors. The big win, though, is the code reuse it allows. If you spend some time making the common format easy to use in your code, it'll pay off in the long run. Code reuse is a big deal for hobbyist programmers.

Great article, mate! I really enjoyed reading it :)

Oh, and congratulations on finishing your engine ^^

Good article for new and seasoned programmers alike. I have umpteen years programming experience in the business arena, and have been coding for games for the last 5 years in my spare time. I am pleased to see that I have applied some good rules; I agree with the majority of the article, and employ most of the techniques. My Game engine has a "hole" in the middle - or at least it does in my head. Each time I add a new element, I ask myself whether I can still drop any kind of new game into the hole, and it will "just run".

My additional tip would be to document how your engine works as you build it. Sometimes you can spend a long time afterwards trying to figure out what needs adding and in which order to make it start ticking. I have installed my own Wiki, and I document how each function works, and how to compose a more complete system from the parts.

Nice article, that 'first game' you mentioned sounds just like mine XD (only I never got to monsters or items)

Jumbled together; most of the code was in the Render loop lol

I really enjoyed this article :)

I am a relativly inexperience programmer, and have been wanting to start working on my first *real* engine (having done the mistake of mixing engine and game code enough to have learnt from it :P). This article really helped motivate me to get started on my own project and I really love the idea of using the engine to make multiple games to test it's strength during development.

Thanks :)