next »

[TheSpaceMan]

This might just be me, and maybe people have talked about this alot...

I have spent 4 years in school focused on game development, mainly the code side, and I have also spent 1½ year as a actuall programmer for a game company but quit since I want to work on my visions not being a ignored cog in the machine.

The thing we are going to talk about today is the balance between implementation in a game, research for systems, and system updates/improvements.

My main weeknes is that I dive straight into the code. I have a vague idea of the things I need and then I implement them, find simularities and reimplement that it to somekind of baseclass. A bit in I also figure out things that would be great to have, if I had the time to implement it. Some of this things I might figure out earlier if I did more planing, at the same time I have seen people plan projects, a friend of mine started planing his in 2002, and he is still planing on it. On the side of it all we do have this working systems, for me right now it's the texture loading, it requires a set of code for the xbox and another for windows (xbox requires the content to be added to the project/windows can load from disc when needed). But I have had this vision where I on windows, during development just can press a button, clear all texture data and the engine will reload it, allowing for ingame runtime changes to the textures. But I don't "need" it, it would be nice to have but I don't need it. Same thing with animations and tilesets for environemnts, great things could be done here if I took time and made a standard, animations could be parsed, and tilesets, by default without me sitting with tools specifing width/height of tiles, modifying xml to create new animations.

How do you evaulate if a code change will be worth the time you invest into it. When should you just work with what you got because it "works"? How much time should be put into evaluating this stuff, and how much time should it be allowed to take from the project?

Right now, most of this is pushed of untill the first project is done. Then all these cool things will be implemented. But it's a strugle.

[Sonti]

Evaluation shouldn't take long. You just have to ask the right questions and the answers should help conclude your evaluation.

For example, few questions like;

Will the implementation save time and headache in the long run?

How long would it take to implement it and do we have the time for it in our schedule?

Could it simplify things for me and others in my dev team? (Eg. Could a level designer who is not good at coding make use of this implementation during level creation).


Working with something that works but has room for improvement highly depends on schedule/money. Loads of stuff get cut from games due to scheduling issues. If you or your team is loose on deadlines or maybe don't have a milestone set up for things, then I guess you could go ahead and make the change if it will make your development time easier.   

[LemonScented]

Depending on the scale of the thing I'm taking on, I'll do a bit of prep work before coding (a few pages of design notes and ideas before kicking off a game, 10-30 minutes of sketching circles or triangles or tables or whatever seems useful for systems I'm trying to wrap my head around, a couple of minutes of staring into space and arranging things in my head for something I'm more comfortable with). But generally I'm a fan of getting stuck into the code early. It never ceases to surprise me how many unexpected things happen once something's actually up onscreen - nobody has the ability to completely imagine all aspects of how something will work until they can actually see the thing (or an approximation of it).

When to ditch the "get something onscreen quick" system and replace it with the "thought out and extensible and future-proof" system is largely a question of intuition. Generally it's good to write the minimum to get what you need right now working, but to go back and clean things up when things start to get ugly or hamper progress.

I find that having a disciplined and consistent coding style helps, even during the quick & dirty work. In fact, ESPECIALLY during the quick and dirty work. Most of the time when I'm faced with something quick and simple that I can get working quickly, when I can imagine that a more refined and elegant system might be better going forward, I'll generally write the simple system and add a comment. So my code is full of comments like "TODO - hardcoding the texture filenames like this is probably going to become a pain at some point. Look at some way of defining it all in a configuration file", or "TODO - I should probably use a fixed-size array as a buffer here for speed, but I can't work out how big it should be right now, so in the meantime an stl::vector will do". Helps me keep an eye on the future whilst doing all I need to do for right now. After all, maybe the simple systems will turn out fine - and if they don't, I'll have left suggestions for improvements if I ever have reason to go back and look at that bit of code again.

[Konidias]

In order to achieve a balance, you first have to set some goals. If you have no planned release date or estimate on how long the game will take to finish, you can't really balance anything. Once you've established a time frame for your game's development, then you can start making decisions about when to stop planning or what to cut and what to include.

Like you mentioned about your friend... you could plan a game for your entire life and never actually end up making it. You could also code and recode a game engine over and over again and never actually complete a game. By setting down some deadlines, you're forcing yourself to make decisions.

But this all really depends on whether you want to do this as a profession or as a hobby. If it's a hobby, you can spend as much time messing around as you want. There's no pressure. But if you're trying to make a living with this, you're going to have to set down some limits.

I've known too many coders who are never satisfied with their code and always end up revising or rebuilding it to the point where they've wasted months of development time and they are no farther along than when they started.

[Triplefox]

My data points are 48-hour games, low-mid-size commercial teams, and large solo efforts. The thing common to success at all of them is focus. You have to pick a prize at the end and stick to it: Hit the deadline and please publishers? Craft an intriguing story or world? Ground-breaking technology? Ultra-addictive mechanics?

As long as you know what your focus is, you can develop a strategy. The code and content only has to be detailed enough to fit the focus, and if you plan one or more iterations of focus(which could mean "finished product" or "prototypes") in advance, development becomes less of a "grind" and more of a "cycle," because you're perpetually - eagerly - starting over somewhere, and yet the results eventually add up to something bigger.

e.g. - Iteration 1 develops a core game similar to others in its genre. Iteration 2 adds major new elements to make it unique. By knowing what you want in Iteration 2 you can stick with an extremely tight plan for the first one - building and learning just enough to make it possible to dig in and explore on the second. And when you finish the first one, plan a third so that the second is focused too. And so on, until you've reached some natural endpoint.

The best part about thinking cyclically is that you rarely actually hit an end. You might hit an end for a particular technology, content base, or design strategy, but if one changes while the others are held constant, you're still moving forward.