next »

[LemonScented]

Hi guys,

So, I'm identifying a problem with my indie development. I'm not sure if it's to do with my process, or my workflow, or what, but I thought it was worth throwing out there to see if I can get some advice. Basically, it takes me too damn long to make the games I want to make. I've been worried about this during development of my "main" game, but it's something that's been thrown into sharp relief by my attempt to get an Assemblee entry together as well.

Here's where I'm at. Both my "main" game and the Assemblee entry are running on my own C++ engine, which I've pieced together in the last year or two. I know that using stuff like Flash, Game Maker, XNA etc would be quicker in some respects, but I'm a bit of a control freak and I know C/C++, so that's my tool of choice. I've been working hard on the engine to do everything I can to reduce iteration times. The level data format is XML, and I can tweak those files and reload them at runtime. Currently it's not hooked up into any kind of visual level editor, so I'm hacking files by hand, but it's reasonably quick that way and I'm worried that developing a full editor GUI might take more time than it would save me. Creating new types of game entity takes some time because I have to code a new class for each entity, but it's a pretty streamlined process.

In terms of the time I spend on the project, I generally get 2-4 hours per day. I try to spend as much of that time as possible "at the coal face", coding new features and whatnot, but I find myself occasionally getting distracted by the need to improve the flexibility and stability of underlying system stuff. If I find a bug, even if it's not in something I'm working on at the time, I want to fix it immediately, because bugs just seem to get more painful the longer they get left.

Um, that's the best way I can describe how I currently do stuff, but I just can't seem to come close to the kind of turnaround speed of a lot of the people I see here. Working solo on the main game, looking to hire in artists and musicians when I find them (and can find a way to afford to pay them), I'm estimating another 18 months in development. Working on the Assemblee entry, I'm hard pressed to work out how I'm going to come close to the level of polish I'd want for an entry (or even just a workable number of decent levels to play). Any advice on how I could be doing things differently? Any questions about how I do stuff now, so you can point at some of it and go "well that's your problem"?

[Aquin]

I can tell you, in the last compo entry, I was spending at least 4 hours a day just working on the game.  I took the full six weeks and spent another week after the compo to clean it up.  So that's quite a bit of time!

It's the price you pay for using such a meticulous tool.  If you want a better turn-around time, you'll need to move to Game Maker or something that prototypes much quicker.

If you still want code, I suggest Pygame or Flixel as a good base for their respective languages.  I don't think anything like that exists for C++ (I somehow doubt SFML counts, but it's helped me a lot this past year.)

[biino]

Hey,

I don't really have too much to offer. I'm not the best project manager around. But I can relate to this issue.

I'm not sure what kind of control freak you mean. A physical memory control freak (MyAwesomeEnt* e = new MyAwesomeEnt()? You can have still have complete control of your game using XNA. Not sure about the others and I suspect definitely not with Game Maker.

I primarily use C++ and C#(XNA) and I find that I'm most productive when I set out tasks for the day with respect to the amount of time I have. I'm like "Hey Bino, I'm going to smash these tasks today and be happy with that". That seems to work for me and avoids feature creep and dicking around.

Minimize your compile times Forward declare classes helps a lot. Do stuff while compiling.

I use XML files as well. I find these can be a big time sink in your development journey when tweaking values. Run->see result->oh noes->change value->repeat. That adds up. If it's a value I'm tweaking a lot, I'll add a hot key to change it in realtime until I'm happy. Although this isn't possible with all values.

But really, quality game development takes time. Other people might have more time than you. They may be spending less time than you and producing something of lesser quality? They may have more people resources.

But with 2-4 hours a day I think you're being a bit hard on yourself

Sorry I don't really have much to help out here.

Bino

[Aik]

I get results very slowly, so might not be one to give advice - but I think losing the C++ would be a good first step. I do honestly like C++, but it's just not a language for getting things done quickly in. It's fiddly, and there's a lot of dicking around needed. If you end up with mysterious segfaults it can take forever to find out where the problem is. I'm a lot more productive in Python and AS3 than C++, even if I still feel horribly slow looking at the people zipping by using Game Maker or whatever.

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

my advice would be to stop thinking like a programmer and stop being a control freak. do you want to make good games or good programs?

[BorisTheBrave]

my advice would be to stop thinking like a programmer and stop being a control freak. do you want to make good games or good programs?

Ouch. Probably good advice, but not what I'd like to hear.

[Mikademus]

It's the price you pay for using such a meticulous tool.  If you want a better turn-around time, you'll need to move to Game Maker or something that prototypes much quicker.

I absolutely disagree! That's the price you pay for being a meticulous and quality-conscious programmer! If you'd be willing to sacrifice code quality, stability and maintainability then you'd be able to crank out shit much faster, which may be ok if you're only doing some minor irrelevant thing or proof-of-concept, but I like to keep my code, work on it for years on end, and then you'll be incredibly much more productive in the long run of you've invested the time to create a solid, clean base. As a professional developer and consultant, you sound like a real programmer. As such, I'd probably much prefer working on your code than on that of any of those that "advice" you to drop quality-awareness for short-term "productivity". (Unless you're only making some minor little throw-away crap, of course).

Thus, perhaps you should build on your quality orientation and look in other direction to increase your productivity without giving up on your strengths. Even taking it to the next level? Have you looked into coding by the XP-model and red-green unit testing? (That is, test-driven development, where you only code enough to make each test pass to force you to focus on structure and the minimal set of essential features).

As for Game Maker, yeah, such tools may let you test some types of prototypes much faster, but there comes a time in a game beyond a certain scope when tools as GM start to restrict rather than empower you.

[To other readers: I'm sorry if I sound aggressive, I'm not targeting anyone in particular and not calling anyone here a bad programmer etc. But I will never accept as advice to lower code quality. As programmers we live by our code. As game developers we live by the quality of our games. And we can't improve our games further than the underlying code allows us!]

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

"And we can't improve our games further than the underlying code allows us"

you see, that's the part that makes no sense to me. i think it's fully possible to improve a game while making the code worse, or without altering any of its code (for instance, using a level editor to improve the levels). it's equating games to code that seems ridiculous to me, the two aren't related.

coding is arguably the easiest and least significant part of making games, and getting too caught up in it to the extent of not finishing games is obviously a bad thing, unless you're just writing tech demo games in the hopes of getting hired based on the quality of your code rather than the quality of the game.

it's also somewhat significant that most of the most popular and famous indie games are those made in easy programming tools. knytt is mmf, as is barkley: shut up and jam and merry gear solid. cactus uses game maker, spelunky is game maker, as is iji, barkley shut up and jam, and so on. the trilby series is made in ags, as are dave gilbert's games. i think the idea that those games were limited rather than empowered by their engines doesn't hold up under scrutiny; those games probably wouldn't exist at all if not for those tools.

[gnat]

One simply recieves so much for free when using GM, Flash or Pygame. A large part of the engine is already implemented and debugged without any time cost.

It's simple math; if I don't have to spend hours coding an engine feature (or courting to the verbosity and complexity of the language), I can instead put that time into actual game development and get it done.

[Mikademus]

"And we can't improve our games further than the underlying code allows us"

you see, that's the part that makes no sense to me.

Then you haven't thought enough about it, or are simply looking for an argument If you can improve your game outside your code it is because your code ("game base", "engine(s)", or whatever term you use) allows you to.

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

sure, but that seems to be stretching it to me. i mean, you can improve a game by improving its music too, but i would credit that to the musician for improving the music, not to the guy whose code made it possible for the game to play music.

also, i'm decidedly not just "looking for an argument". i have better things to do. but it just bothers me that he might take your advice and stay exactly where he is now for another 10 years. i see an enormous amount of potential wasted on people making "their very own engine!" instead of games.

[Triplefox]

I put a lot of upfront effort into a "solid base." And I can tell you right now that it has certain rewards, but is very expensive to do.

Take a look at the dev log link in my sig. I gained tremendous velocity on this project once I hit a certain inflection point in development, so now I post huge logs of changes on a semi-weekly basis. But it was preceded by months and months of pre-production work, trying to wrap my head around exactly what the game needed deep in its bones before implementing "cool features." I let it go down that path as long as possible before the schedule required production to start. At the outset, I already had a design/creative vision from previous works, but I wasn't settled on a technical vision yet. I would do a tiny bit of production-type work, find flaws, then go back and change the process, trying to optimize for future productivity. And there was a lot of waste and misguided effort in the middle of that, but it was a form of technical prototyping - it let me settle on the basic ideas and build a foundation, code that reflects various visions I had for the game I was making, without jumping to the implementation immediately. I used restraint so that ideas could all jump out at once, and that's exactly how it's happened. In the meantime, my thoughts about the creative aspects changed to reflect the actual nature of the code and the gameplay I was seeing, and I think that will be reflected in the feel of the final product.

But even now, I'm saying to myself, "oh, this system is bad, this is ugly, this bit is terrible." Once the game is done, I'm going to tear up a lot and create a new, refined engine out of the rubble, because I've pushed the architecture far enough to uncover new aspects for improvement. But the difference between the coding I do now and the coding I did a month and a half ago is tremendous - the new code is code to ship a single game, and thus it doesn't have to meet an arbitrarily high standard of rigor - it's dull code that does the job. The code I did previously was made to facilitate the new code, and thus explored increasingly more esoteric/fantastical means of improvement.

If you want to finish games, you have to flip that switch eventually and say "OK, this will ship it, let's move on." More time can buy you more intricate features, more reliability, more polish, but those aren't usually make-or-break factors. For me the process of building the base lets me settle into the game concept, make the "minimum acceptable gameplay," and then gradually come up with ways to explore it.

I should also add that my "solid base" mentality extends to basic language/tool choices. I use haXe because I consider haXe the most powerful language for Flash. SWF manipulation for haXe-based build systems wasn't as good at one time, but that era is essentially over now - I can embed assets and preloaders about as well as a Flex-based solution.

Similarly, I use Python for tools. I'd love to have something with better raw performance and static checking abilities, but I can't find a language that does those things and also occupies the same sweet spot in libraries and overall refinements.

But the overriding goal is never the abstract concepts of "clean code" or "solid architecture" or "theoretical soundness." It's "apply technology to make better games faster." Resourcefulness. Sometimes that means skipping to a preexisting engine, other times it means making your own thing. I've opted for my own thing, at least in this instance. I can foresee a time in the future where I may drop it, but at least for the moment, while I'm doing Flash stuff, I'm dissatisfied enough with the current options to not go down that route.

[Aquin]

No Mikademus, I do actually agree with you.  That's why I still use C++ and only go as far as extensible frameworks (such as Flixel.)

I intensely disagree with Paul's assessment.  But I also know that he writes a lot of code in GML to get his stuff working, so even his actions disagree with his claimed position.  It's a bit confusing.

Coding slows you down.  This is a good thing.  It forces you to consider (or at least gloss over) minor details and the smartest of us will find ways to make things a little cooler at every step.  The result of millions of little things adds up to a pretty nice game.

That's why nobody wants to play an RPGMaker game.  They all "feel the same."  Do they have different stories?  Sure.  And if that's all you want, go make a game in that engine.  But if you want your game to really stand out, you gotta do most of the heavy lifting.

I assure you, Spelunky is not a simple drag-n-drop game (despite the conveniences and stereotype of the underlying engine), nor are many of the games you hold dear to this day.  Think about it.

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

i think you may have misunderstood; i wasn't saying don't code. i wasn't even saying to use engines like game maker. and certainly not to use drag and drop in gm, nobody uses that. i was saying don't obsess over it to the point where you sacrifice the rest of the game and don't finish games. if i said 'don't obsess over the writing in a game' that doesn't equate to 'don't write anything in your game'.

[increpare]

I'm totally not getting drawn into this.  However, I wish you the best in getting things done : )

[Aquin]

Ah, very good point Eres.  Mesh's Boolean RPG comes to mind.  I think he's getting a bit obsessed with the details, to the point where I'm not sure he can see it through. 

Yeaaah...I agree, don't get too crazy with the code, but I'm not sure the OP was having a problem in that area. 

[Desert Dog]

What Paul is saying isn't all that hard to understand. Essentially, how I interpret what he is saying, is that a great game is really unrelated to the code. The code merely provides the platform for the game to stand on, but no one really looks at the platform, they look at the game itself.

That's why, yes, there are good games made with RPGmaker, Game Maker, AGS, Klik 'n Play, etc. Because it isn't how the game was made, but the game itself that counts.

Of course, good coding is great and all, but nobody cares if the platform is shiny&smooth, if the game standing on it is ugly.

So once the platform is built, you can either spend more time 'obsessing', and scrubbing it down, and making it look shiny&nice, or you can work on the game itself.

Perfection is great and all, but I suspect it's actually the bane of more than a few game dev's.

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

Yeaaah...I agree, don't get too crazy with the code, but I'm not sure the OP was having a problem in that area. 

I thought that was the entire point of the OP actually; things like "I find myself occasionally getting distracted by the need to improve the flexibility and stability of underlying system stuff."

In general think it's better to make the game first, then work on the engine, rather than vice versa. Because an engine has no ending, you can improve it forever, but a game has a finite amount of content to create: x number of levels, y number of characters, z number of monsters.

[Mikademus]

Thank you, Aquin, you made some very good points in a very succinct way. I also think Triplefox summarised the necessity of both obsessiveness and pragmaticism. Therefore, Paul, I again must reiterate that I think it is absolutely essential to obsess over the code aspects of the game. You can improve the quality of the game by doing better music, but if the code only allows .SIDs and you'd be better served by OGMs (or whatever) then you're screwed until the code allows it.

By profession I'm called in to fix commercial projects and companies risking going under because of poorly written source (not limited to languages: examples are VB, Java, C++ etc), and I've many time looked into the the hell-hole coming from the "delivery before quality" attitude. Simply put: I would NEVER employ a developer with that mind set because of the incredible risk involved and increasing overhead (money, effort, stress, etc etc ad nauseum) it creates.

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.

Therefore, the solution is NOT to restrain obsession over quality (i.e. lower standards) but to restrain immediate ambition. Take small steps, but always with the bigger goal in sight. Red-green unit testing under an xP methodology is an excellent way to this.

Paul, I'm sorry if I misunderstood you, but I read your advice as this:

"Q: I like eating good food, but I can't eat as much as you. How can I improve my eating speed?"
"A: Lower your food standards and start eating slop out of the bucket!"

To that reinterpretation: sorry, but good, high-quality food simply takes longer too cook. But if you learn to cook in a better way and you can reach a future productivity much higher and with better quality than from a hasty and sloppy quick-fix process.

All this said, I actually think we might be talking about the same thing: that we're foremost making games, not writing code as a goal in itself. However, we're coming from different opposites: you seem to advice to ignore code quality to attain the goal of finishing a game, while I say that your game will be better from having a well-written code.

Desert Dog, yeah, when playing a great game people won't be thinking, "Gee, this game must be wonderfully written!", but hell, after a few calls to the support they'll think a poorly written game bloody bad.

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

well, i wouldn't consider allowing ogm's obsessing over code, that's just normal feature coding. by obsessing i meant perfectionism when it already works, like spending a week for 1% performance increase for instance.

also, i think comparing some of the best indie games (like the ones i mentioned) to slop out of the bucket does a disservice to those games; spelunky isn't slop just cause it's made in gm.