Developing Games

I seem to have a serious problem when it comes to developing games. I can't really see a way around it.

Whenever i start a game, i generally plan out everything the game needs, and then bang on and start coding. Half way though coding the engine for it, i suddenly stop and an idea pops into my head about how to make the engine better, and it would require a substantial rewrite.

Now, normally, one would continue on and get it finished, but i seem to develop a fear of my engine not being fit for the task of the game, and sit for ages thinking about the things that could go wrong etc etc It's probably some mutated version of feature creep mixed in with the need to have something near perfect, but ending up with nothing.

I guess i'm pretty weird. Does anyone else have weird issues developing games?

Try making a note of the engine enhancement in a "future engine enhancements" doc, and still carry on with the game. That way your game will get finished (maybe) even if the engine is not "perfect".

Not sure what *you* mean by "coding the engine" but this is the most often linked response on Gamedev.net on people struggling to create a Game Engine...
Write Games not Engines
In addition, if your design is good to begin with, plough on, get the game finished. If you have written it well you'll have bits of reuseable code which is the beginning of your 'engine'. You can then improve/refactor this as necessary. Again, if you have designed your 'engine' and game well it'll slip straight in and can be used in V2 of your game.
My main issue was (is) making the reuseable code unrelated to my program code. The best way to ensure this is use the engine in separate tests.
Hope it makes sense.

Good article. I said the same here: http://greyaliengames.com/blog/a-simple-exercise-to-get-better-at-press-ups/ and in here: http://greyaliengames.com/blog/how-can-i-overcome-game-development-obstacles/ (scroll down to "My Engine is taking too long")

Make the idea, flesh out the idea. Code the basics, flesh out the basics. Work on the segments of the basics in turn making it modular in the process for easy updating.

As everyone has said future updates should be kept till v1.0 is out there then do upgrades/updates.

I had the same problem with Hunted the thing that miffed me in Hunted was all the models/levels that were required to do what I wanted now im going for a segmented level with prefab approach so I can make levels VERY fast in a editor then whack in some prefabs to make the whole thing fit what I want to do. Yeah I have to design the levels/models but its easier than using something like Quill3d to do it, I am making an exporter so I can export them as b3d's then import into Quill3d and lightmap em :)

At some point you need to lock down new features and put them aside for a future project. Otherwise you probably won't ever finish anything.

Stop writing game engines.

Just write a game, and add only the features you need. Its completely pointless to waste your time adding in things you're never going to use. I've just written a GUI system, and it only has four gadget types, because that's all I need.

DO try to keep the code tidy and modular, though. That'll at least make it easier to add/change/remove things later.

Do I have issues with game-making? Just lack of motivation, but boredom usually outweighs that.

What GfK said. software Engineers have been struggling with this problem for ages, and have developed two principles to remember, which will help you deal with the issue.

The first issue is the "Good enough is best" principle which states that when you get an idea for an improvement, you should balance that idea against whether the existing implementation is good enough. If it is, there is no need to rewrite it.

The second one, which is related to the first one, but more specific to generalization and new features is known as the "You're never gonna need it" principle. The gist of it is that unless you absolutely must have said feature or generalization, because it would solve a real, current problem odds are good you're never going to need it, so doing it is pointless.

That's the problem i realise that's the problem, just a mental problem i must have.

I will try and put that into practice. I have no problem making games like space invaders, tetris, pacman, but the more compicated the game, i start to struggle.

Thanks for the advice though. Appreciated.

If you're new to writing games, the best advice is this: "Finish your game." Seriously, regardless how crap or bling it is, finish the damn thing. The worst thing you can do is "train" your brain to stop halfway through and move on to more interesting (new) ideas.

Nah, i'm not new, and i can write finished games. It is just when the scale of the game increase, i lose perspective i guess...

Well the bigger the game in b3d the harder it is because of no oop features.

..hey Ross, is that Turrets game you talking about? ;)

Heh, yeah it is actually. I'm getting really bogged down with the cannon upgrading stuff. I think i'll keep it simple, see how it plays, then rework it after it's done. Least i'll get something done :o)

There were several points during the (later) development of TU where I realised I'd made some basic assumptions that either needed a rewrite to iron them out - or resort to cludges.

So my code has a number of spots where there's a big 'CLUDGE!' remmed in with lots of hash marks.

After a critical mass has been reached and there's good functionality (despite the hacks), it's all about getting the game out. I figure if the game's sucessful, then there's v2 to go back and sort these initial problems.

Post the code that is annoying you to the programming forum. About 5-10 minutes after you have clicked the button you will know exactly what you did wrong, even though nobody has posted yet. Works for me. :)

modularity(is that a word?) and OOP is really important for me, It mostly makes things easy to add/change and easy to understand, and over all way more managable.

One thing i CAN'T do is brainstorm ideas before I start making the game. It's like my brain is on a need-to-know basis and ideas don't usually pop into my head unless I'm coding. Like it could take me weeks to brainstorm what I could come up with in a few minutes of coding. There's really nothing special that I can't come up with myself, sometimes. And if I can't come up with that one-special-thing, then I'll give up that idea and move on with the game, adding other stuff.

I have started a simple 3d block pushing puzzle game which I'm currently trying to add triggers to, which is taking longer than I expected. But the idea for this game didn't take much "brainstorming" because all it took was a little past experience, functions/acceleration and velocity by TForming/textures/cameras/more functions/includes/etc.

You have what is know as "scope creep" where the scope of the application keeps creeping to a larger size.

The only way round this is to get the design document down and packed and then code without deviating from it. A little change here and there is fine but if it shouldn't mean a complete re-write.

While I'm coding i'm always coming up with new fancy ideas that i could implement, but they all go in to my 'version 2' box. These ideas will then be used in another game after I've finished my current one. I find that if I keep striving for perfection then I'm never going to finish anything and I'll have wasted all that time.

aaaaah.. so that's where my last seven years have gone... I knew it!!

From what I know so far a game engine is useful not for a particular game but for a particular TYPE of game. I suppose that Ross C is talking about special libraries he will need for a specific game.
I didn't read the articles of Grey or Gamedev.net but I believe that the key to a smooth line of production during code writing is the as much as possible detailed analysis of the goal.
For example you must think all possible states of your main character:
Does he gonna to walk, run or jump in the game?
Are there any cases where these states are not acceptable?
What will happen after he will lose?
Having these answers you can forecast the futures needed for your 'game engine'.

What Grey said - make a future enhancements document and complete your currentr version first.

There's a great story in the "Game Architecture and Design" by Morris and Rowlings where a freelance project manager is brought in to get a project back on track. She determines the problem to be, something we all know and love (hate) "feature creep" - as soon as you get a new idea, you try to squeeze it into the game development cycle - to enhance it your great game that little bit more. She also determined that what the company should do is stop developing and now contain what they had, and complete it within a couple of months and release it.

They thanked her, sent her on her way and continued to enthusiastically ignore her warnings. The company went bust 18 months later, having never got to the end of their development cycle for that game.

Great book btw :- http://www.pearsoned.co.uk/Bookshop/detail.asp?item=100000000043766

PS it is a good book but NOT worth £39.00 - the link was ONLY for reference.

Have a look at the forums and also see just how many completed projects there are, which are commercially viable (if thats your aim). There are only a few compared to the ratio of developers and years B3d has been around. What does that tell you?

Developing a game is easy.

Finishing a game is HARD!

...so you are not alone.
IPete2.

Are applications comparable to games when it comes to coding/planning? Whenever I do a creative application I soon enough get the idea that I started wrong. Creative people are a disaster for creative tools, they can see new opportunities around every corner.

Yeah, finishing a game IS hard! I'm in the last stages of mine which has been almost a year in the making. Feature creep has sat on my shoulder for most of that year whispering evil thoughts into my head.

Hopefully I can keep him at bay for another 2 months til I'm finished, I keep replying "Yes I'll do that...if I ever make a sequel!". Seems to work.

I have the same issue. I keep rewriting everything all the time, simply because I run across pieces of code and ideas that can be improved, while I am creating it.

I do not see it as waste of time though. For me, the learning experience of achieving new things is much more important than actually finishing the product.

I agree to a certain extent Jim, but it does become rather irritating after a while, especially when you really want to get a project finished :o)

Thanks again for the advice and words of wisdom/humour :o)