next »

[Alex Vostrov]

My approach is to make very rough prototypes of features that I want.  For example, let's say that I want to put a minefield into a strategy game to see how it changes things.  One approach is to spend a bunch of time on code that lays out the mines individually.  Another is to create one single giant entity that deals damage to stuff around it.

Basically, by using quick and dirty hacks that approximate the ideal solution, I save a ton of time.  If the idea is good, it will be visible with the 90% solution and I can polish it later.  I also don't worry about optimization or graphics until the very end.  All of my games are made with rectangles, circles and a good dose of imagination.

Paul is right, by the way.  Give yourself permission to write the fugliest code you've ever made.  You can always tighen it up later if you hit upon something awesome.  Think of it as painting.  Capture the large shapes first and then work on the details.

The other reason that you want to loosen up your coding standards, besides efficiency, is that nobody gives a damn about how good your code is.  Indies have only one advantage over the AAA dinosaurs - imaginative design.  Do you think that you can make anything nearly as impressive as EA alone, production-wise?  They'll have one guy whose entire job will be to code particle systems in their game.  You just can't beat that sort of thing head-on.

What we CAN kick ass in is amazing game design.  Our turnaround times are a hundred times faster than theirs, so we can experiment.  The point is that you should take advantage of that strength.  Put your game first and how you implement it second.  If the best way to do that is in Flash or GM, then go for it!  What matters is the game that you made, not how you did it.

You could revolutionize the entire industry with Game Maker, if you were a brilliant designer - you don't need anything else.  If you want a good kick in the butt, make a bunch of games like Petri, each in one week.  I did it for a while and it's great at focusing the mind.  Knocks the perfectionist coder right out of ya.

[hatu]

The middle road is the best here too.
Hacking everything is just as if not more dangerous than over-engineering everything.

[ஒழுக்கின்மை (Paul Eres)]

yes, but if the OP's problem was overengineering rather than hacking, taking a break from that and making a game a week for a few weeks probably won't turn him into a horrible programmer, it'd just be correcting an imbalance.

also, as an aside, it's perfectly possible to be a perfectionist about code in gml too. there are just as many people who obsess over coding and engines and who never actually finish games in the game maker community as elsewhere else. and i tell them the same things i tell anyone else, stop making engines and start making games. that's what's really fun about game development, after all.

[LemonScented]

Wow, this thread got lively quickly

There have been too many points made for me to adequately address them all, but here are my thoughts on a few things:

LANGUAGE CHOICE:
I'm not a language snob by any means. It's quite likely I'll want to try PyGame or GM at some point in the future - in fact it might have been a smarter choice for Assemblee than using my own engine, although experience has taught me that someone else's engine coupled with a tight deadline is usually a recipe for disaster, so perhaps I'll save my first experiments with those for a time when the only deadlines are self-imposed. All that said, the engine I've got now is C/C++ and it's what I'm sticking with, at least for now. C/C++ is what pays my rent, I've been using it for almost a decade now, and I'd like to think I write pretty decent code with it. The "control freak" part was about me wanting control over memory and processing cycles - I've done a fair bit of handheld and console development, and every byte and clock cycle counts. My Assemblee entry is nothing special from a technical standpoint, but my main game pulls out pretty much every trick in the book to get the performance up to speed on an average PC, so C++ is pretty much my only choice.

CODE QUALITY:
Lots has been said about this, although the bit that I think most mirrors my viewpoint was this:

Rule 1: Big projects require obsessiveness and constant refactorisation (or you will eventually be overtaken and left in the wake and/or go bankrupt)
Rule 2: Small projects will grow into big projects.

A "big" project doesn't have to mean huge teams and budgets, but codebases grow over time, and a lot of code sticks around for a surprisingly long time, because an engine is an investment which you hope to be able to reuse over several games. I've seen parts of codebases in big-budget AAA titles that were 20 years old. I've worked with proprietary game engines which over their lifetimes had been twisted into racing games, FPS games, casual kid's party games, and platformers. One of the engines I worked with was well-built, well maintained and followed rigid coding guidelines, and it was capable of turning out industrial-strength prototypes in a matter of weeks. Another engine was rather sloppier, and has probably cost the company tens of millions of dollars in man-hours tracking down bugs that should never have made it in in the first place.

I think the truth is that there's a cutoff point when you stop writing nice clean "good" code and start hacking about just to get the game finished, and choosing when that point is is a pretty fine art. For a month-long project you can get away with writing shitty code right from the start and throwing it away when you're done (I've done this plenty of times myself), but for bigger projects if you start hacking too early then you're doomed.

OVER ENGINEERING:
This is a term that I usually take to mean trying to do "clever" stuff to make "elegant" code, and I hate it. Whilst I have been spending more time than I'd like on my engine, and not enough on the game, I try to write code that any dumb, tired or drunk programmer can understand as soon as they look at it. Mostly because I am dumb, and often tired or drunk when I'm coding. The people who buy the games don't see the code or care about its quality, but I know I'll still be looking at it in a year, and if it's crap or convoluted, that's going to get in my way. One thing that I've found useful is that if I'm writing a new bit of code, I write the minimum I need to get it working at the time, but litter it with asserts which will raise hell if I later try to use the code in a way I hadn't originally thought of, at which point I can go back and reassess what needs to be changed or added (or, ideally, removed). It's a blessing and a curse because it means that the engine and the game progress in parallel, so it might slow up a bit of gameplay I might want to add in a couple of months, but it saves me spending time worrying about it now. So long as the code is clean and extensible, I'm happy.

Gah, I'm rambling. Sorry. How about I try to keep it simple with a slightly more focussed question:

QUESTION:
In your experiences, what have been the biggest technical hurdle to fast iteration on a game? I don't mean all the fiddly vertex buffer, entity management, audio channels, all that stuff - but just say you sat down with your current tools and code of choice, and wanted to crank out a new level from scratch, perhaps with a few new different types of entities (bad guys, physics toys, whatever), what takes the most time? Conversely, what have you found that helps with those things?

[ஒழுக்கின்மை (Paul Eres)]

QUESTION:
In your experiences, what have been the biggest technical hurdle to fast iteration on a game? I don't mean all the fiddly vertex buffer, entity management, audio channels, all that stuff - but just say you sat down with your current tools and code of choice, and wanted to crank out a new level from scratch, perhaps with a few new different types of entities (bad guys, physics toys, whatever), what takes the most time? Conversely, what have you found that helps with those things?

none that i can think of. well, there are thing which are harder to code than most game logic, for instance the physics of a string-like hookshot, or analog joystick controls, or collisions systems. but i can't really think of major *technical* hurdles, most of my hurdles are related to game content/resources: making level data, text, graphics, music, etc. as i said, i think that, with some exceptions, coding is the easiest part of making games.

[LemonScented]

none that i can think of. well, there are thing which are harder to code than most game logic, for instance the physics of a string-like hookshot, or analog joystick controls, or collisions systems. but i can't really think of major *technical* hurdles, most of my hurdles are related to game content/resources: making level data, text, graphics, music, etc. as i said, i think that, with some exceptions, coding is the easiest part of making games.

Right, but what's so time consuming about making level data, for instance? And how do you speed that process up? I should probably have worded it better but when I said "technical" I didn't specifically mean the time spend coding a new thing (although that's likely to be part of it), but the features/limitations of the engine or tools which are related to adding and instancing new assets. Assuming you've got a pile of audio, graphics and text, what's the workflow for turning all of that into a playable level?

[ஒழுக்கின்மை (Paul Eres)]

to speed up level creation i make my level editor better. i use game maker but still coded an in-game level editor because gm's one is bad and because i like to edit something as i play it rather than separately. here's a pic:



i then add various shortcuts and features which allow me to speed up level data. i need to make 800 areas for my current game, so there's a lot to do. so i added things like a shortcut key to add invisible walls to all sides of a room because i often use those. i added a shortcut key to 'shuffle' a level around, moving every object in it a little bit; a key to add in random objects of a particular type, a key to delete all objects of a current type. basically by adding shortcuts to the editor whenever possible, and where ever it makes sense, i can cut down level creation time quite a bit. now it takes me on average about 20-30 minutes to create an area, down from a few hours.

[Alex Vostrov]

In your experiences, what have been the biggest technical hurdle to fast iteration on a game? I don't mean all the fiddly vertex buffer, entity management, audio channels, all that stuff - but just say you sat down with your current tools and code of choice, and wanted to crank out a new level from scratch, perhaps with a few new different types of entities (bad guys, physics toys, whatever), what takes the most time? Conversely, what have you found that helps with those things?

AI is the spawn of the devil, as far as I'm concerned.  If you have a game with any significant AI component then the design cycle changes to:

1. Add feature
2. Write AI for it
3. Think about the results

I find that step 2 really drags things down.  I can see 2 solutions to this:

1. Use flexible AI algorithms - I've seen neural nets used pretty succesfully in some CCGs
2. Code in multiplayer and play with a friend


As far as the engineering side of things goes, I have different phases.  When I'm making games, it's hack hack hack time!  When the project is completed, I take the lessons that I've learned and improve my personal engine.  Slowly but surely, I've accumulated reusable classes like spacial data structures and handle managers.

[increpare]

You were saying before that you were hand-coding everything in XML.  For almost any sort of big project, setting up a decent graphical editor is a very very very very good idea.  It doesn't take that much effort to get a basic one working, either.

[Aquin]

Yeah, I agree with that.  The level editor is usually the first thing I make in *any* game.  It only takes a couple of days (for a reasonably large project) and saves you many many many headaches. 

[Average Software]

but no one really looks at the platform, they look at the game itself.

I'm probably in the huge minority then, because I personally care more about the platform then the game.  When I find a game, the first thing I look for is the code, because I like seeing how things are done.  I find game development more interesting than game itself, and I'd take a "great program" over a "great game" most of the time.

This applies to my own development too, I'm usually more concerned with how people will view the code rather than how people view the game.

I'd be much more interested in playing and analyzing a game written in something like Fortran than Game Maker, because Fortran is more interesting.

[Aquin]

I think there might be medication to help you deal with that problem. 

[Average Software]

I think there might be medication to help you deal with that problem. 

It's not that crazy.  I learned to program on my Apple II in the mid-80s by copying games in BASIC out of magazines (they had magazines like that back then).  Most of the games (OK, maybe all of them) were incredibly bad, but it was just really cool to me that you could just sit down in front of a computer and type and come up with this stuff.  I would always end up modifying the games in various ways, making them harder sometimes, entering "cheats" occasionally.

Some of the magazines even had entire games in hex code (they were likely written in assembly) and you had to sit there and punch in 7 or 8 pages of hex to play the game.  I honestly thought that really good programmers wrote all their code in hex, and would spend hours trying to decipher it.

Some of us actually enjoy "programming," and not so much "writing programs."  Sometimes it's the journey, not the destination.

[ஒழுக்கின்மை (Paul Eres)]

yeah, i fully realize that a small niche does enjoy programming games more than making games, and can appreciate that in an abstract sense, but at least i think that that niche should not complain when they don't finish games, since by their own admittance they enjoy the journey rather than the destination

it's kind of like if you enjoy writing as an end in itself, and don't enjoy storytelling as much, and read books more for the quality of the writing rather than the quality of the story, then don't be surprised when you don't finish writing novels

[Aquin]

Yeah, I admit there are a few...times... when I get a little carried away with the coding aspect of a game.  Then I forget all about the game and just play around with some technical concepts. 

[hatu]

to speed up level creation i make my level editor better. i use game maker but still coded an in-game level editor because gm's one is bad and because i like to edit something as i play it rather than separately. here's a pic:



i then add various shortcuts and features which allow me to speed up level data. i need to make 800 areas for my current game, so there's a lot to do. so i added things like a shortcut key to add invisible walls to all sides of a room because i often use those. i added a shortcut key to 'shuffle' a level around, moving every object in it a little bit; a key to add in random objects of a particular type, a key to delete all objects of a current type. basically by adding shortcuts to the editor whenever possible, and where ever it makes sense, i can cut down level creation time quite a bit. now it takes me on average about 20-30 minutes to create an area, down from a few hours.

This was also one of the best decisions I made on my current game. Level editor that works with the same engine so you can play around in it. Instead of some kind of save, refresh project, compile, run, select map cycle.

[Tycho Brahe]

I probably should have done this for my current game. As it is you draw a level as an svg file then my "compiler" turns it into a game readable level file which can then be loaded without  recompiling the game. In this case I think the most intelligent thing I did was make sure levels were loaded while the game was running, even if the level creation process was very long.

[Mikademus]

it's kind of like if you enjoy writing as an end in itself, and don't enjoy storytelling as much, and read books more for the quality of the writing rather than the quality of the story, then don't be surprised when you don't finish writing novels

And when such books do get finished they tend to become literary classics...

But as a suggestion to the OP for increasing productivity without giving up quality, could I suggest you find someone that'd be willing to peer-review your code and give you feedback about when the base code is "good enough", when you're over-featuring, and where you should move on rather than polish and goldplate?

[bateleur]

In your experiences, what have been the biggest technical hurdle to fast iteration on a game?

Typically feature creep. I've seldom had trouble developing the software side of a game's initial design, but as soon as it reaches a playtestable state I start tweaking stuff and adding stuff and very quickly I find I've got to start adding special cases to the engine and not long after that the engine implodes under sheer weight of hacks.

It could be argued I should stop doing this.

[Ivan]

You NEED to have an environment that lets you not worry a single bit about the technical details.

That is all.

Whether it's your own engine or someone else's engine or some obscure language, it doesn't matter. You need to have this. If you need to get an image on the screen you need to be able to do it in one line of code or a drag of a mouse or whatever. The same thing should apply to any other technical part of the game.

If you like writing your own engines, that's fine, but be realistic and understand that until you have a complete and stable engine (something that takes months if not years of work), your actual game making will be hindered by the many technical features that you'll need to implement along the way.