At GDC, I heard a lot of conflicting advice.
Dan Cook suggested a broad portfolio to reduce risk, for instance, while other developers talked about focusing your energies on a single project or genre.
Whatever any one indie said, the one thing everyone seemed to agree upon was the importance of speed.
Dan Cook has written about the importance of quick iterations to “find the fun” as quick as possible.
Andy Schatz talked about the development of Monaco when he was almost about to throw in the towel on being an indie, and he advocated working on something exciting every day.
Use two hour game jams to explore game mechanics or designs.
Play-test early and often.
Create an MMO every day.
With Stop That Hero!, I already knew that things were going much more slowly than I would have liked, but the importance of speed really hit home during the Ludum Dare Jam at the Noisebridge hacker space on the last day of GDC.
My goal: create one simple, quick game every hour during the jam. I knew it was ambitious, but I wanted to try out this focus on speed.
In the end, I spent hours just trying to cobble together some decent code to use as a base for my first project, and I didn’t manage to finish it.
That’s not agile. That’s not speed. And that’s not good.
I struggle with my major project partly because I don’t have a base of code to leverage. Every time I need technology to support game play, I have to figure out how to implement it and fit it into my existing code. I never spent any time working with something like Game Maker or a game engine such as Quake or Torque, and since I do my development on GNU/Linux and want to be able to port to multiple platforms, there aren’t really any 2D engines available for me to work with. If I need some tech, I more often than not have to figure out the best way to architect it myself. My current pathfinding and navigation code is difficult to work with, for example, and I’m sure there is a better way.
Stop That Hero! might just be too much for me right now, and I might be better served by stepping back to work on smaller projects that don’t require AI, UI, or any other technology I don’t currently have. Also, I could probably do well to dedicate time to studying existing source code.
While part of me wants to muscle through and not leave my first major project unfinished, another part of me thinks I would do better building up my tech by creating smaller games around individual pieces. For instance, if I created an entire game around clicking buttons, I would have created my UI code AND have a finished game to show for it. On the other hand, I’d probably run into a lot of the same issues trying to finish a smaller game anyway, so why not continue working on the same project?
I really want to see Stop That Hero! get finished, but the ship date keeps getting pushed back, and the problem isn’t necessarily a matter of features that can be cut. The basic game requires a lot of moving parts which still aren’t created, so it’s not as if I have scope to reduce.
If I want to work and ship faster, I need to change something about what I’m doing. Either I need a improved technology base, which I obviously haven’t been able to create quickly, or I need to temporarily switch to a smaller, simpler set of projects.
How would you approach this problem? Would you try to use smaller projects as stepping stones to the larger project, or would you continue to work on the larger project, figuring that you would end up hitting the same obstacles and solving the same problems anyway?
This post was scheduled to be published at a time when I will not be able to access the computer. I’ll respond to comments when I return at the end of the month.
17 replies on “The Importance of Speed”
I believe there is a way to architect your cake and eat it too. Take the design of the project and dissolve it into the smallest possible prototypes which test out a game mechanic or a necessary framework piece. Turn one or more of these prototypes into small stepping stone projects by fleshing them out iteratively with other simple mechanics/art/content so that they stand alone. This way at least 60% of each smaller project is actually code and framework dev that you would have done anyway (solving the exact problems the larger design needs solved). It’s not always easy but even taking a single sizable chunk out of the larger project tests not only the design/fun/concept but pre-solves the tech. I am doing this exact method with a side-project of mine and if you want I will let you know how it turns out.
You’re limiting yourself with your choice of platform and tools. Even worse, you’re doing it for “someday scenarios” like porting to other platforms. If this is to be a *business*, then you need to make sound business decisions even if they go against your personal ideals. Turn it into a business first, then you can afford to follow your ideals. Things have changed greatly over the past 10 years. Engine technology has been commoditized without sacrificing features or extensibility.
My advise? Download Unity. It’s free but let’s say you go nuts and decide to license Unity Pro for $1500. Even if your monthly overhead/burn is as low as $500. No single human could never create the toolchain and asset pipeline they have in less than 3 months. Plus, you gain experience with a popular technology that could lead itself to some lucrative contract opportunities.
My guess is you could port Stop That Hero to an existing game engine within a week. You wouldn’t lose any of the time you spent designing the game rules and algorithms.
Paul has some good advice there. Don’t start from scratch if you want to ever monetize. At the very least, look for libraries to use instead of doing it all yourself. If you go whole hog with a prebuilt engine or framework, you’ll gain a lot more. You have to fit your code into someone else’s plan, but you can then focus on the game instead of the guts.
By the way, I found Micropather to be a nice, simple pathfinding implementation. And if you plan on using SDL and not a framework like Unity, I’m always open to collaboration.
I think I have talked to you about this before, but I would recommend Flash or Unity. A stand alone C++ game really has no place to be sold except Steam. Flash will get you up and running quickly and get you potential sponsor money from many different portals, the best being Armor Games or Kongregate. Unity gives you the choice of Steam, Kongregate, and mobile devices. SDL is too low level and you will still end up coding a lot of systems that will slow you down.
Sorry to say it, but being on Linux is not your best choice for making a living. I love Linux for many reasons, but you need to make money, and make it quickly. Get an OS that supports whatever engine or framework you choose.
Making your game is not the hard part. Selling it is. Having only one channel of distribution is not a good business choice.
A good post, and a good topic, GB.
I agree with Paul and Jonny… especially about the Linux thing. I’d say get Torque 2D and learn to love scripting.
One thing I’ve noticed both here and talking with you in the past, that directly relates to this “I spent hours just trying to cobble together some decent code” thing…
You seem to be a very GOOD programmer. You like the code, and you like it to be all put together correctly. You discuss things like proper object-oriented frameworks and scalability. Methodologies like Agile, etc..
It seems to me for projects that are smaller in scale like this…
You should take a deep breath… empty your mind of code worries… and then just HACK IT TOGETHER. 🙂
There will not be a ‘code review’. It’s really quite alright if things get a little spaghettified.
Is it easier for you to make a monster attack function if the main character’s health is a global variable? Go ahead and toss that puppy in there.
If your A* algorithm later ends up parsing string variables for heuristics — that’s OK too. Computers are fast these days, and the player won’t even notice.
Implement the elegant, well-thought-out solutions only when they will make you faster in completing the project as a whole (i.e. one-off coding every button click rather than having a generic button behavior would be a horrible idea).
So yeah — Get an engine so that the ‘hard stuff’ is taken care of for you, and hack everything else in there with a focus on the player’s experience and commercial-grade polish.
My 2 cents, YMMV, etc.
Hate to say it but C++ is the new assembly language.
What you can do in one hour using an interpreted language (like as3 or unityscripting) would take 12 hours of hard work in C++. I used to love C++, and have written hundreds of thousands of lines of it. In the eighties and nineties! C++ is so old, so bad for productvity, you might as well be using punch cards. I am not exaggerating here: the same functionality done in c++ takes 10x to 20x the hours of work compared to if you did it in a next gen language. Programming in c++ is like building a house by chopping down trees with an axe and hand-planing the wood to create lumber. Time to embrace modern technology and stop re-inventing the wheel: you can buy lumber at the store and use prefabs whenever possible. C++ is only good for device drivers and ultra-low-level engine loops.
Get away from C++ now or forever be burdened with extremely low levels of productivity.
I’ve heard people complain about Unity for 2D, saying its overkill and a huge learning curve? I’ve heard people complain Flash is almost impossible to sell direct and sponsor revenue can be tiny. I’m using Ogre, cegui, tinyxml, fmod and lua to target downloadables – gives me more help than SDL alone, but not tied to something big like Unity. It is a pain getting it all to work together. I’m tempted to move up to http://www.phelios.com/ptk/index.html, its cheap and zeroed in on 2D so not complex to learn at all (I had a demo working in an hour) and used commercially a lot (win, mac, ios), apparently bigfish use it internally (or did). No forum though. 2dboy released the code they use when prototyping here http://2dboy.com/public/framework.zip, very nicely laid out.
“C++ is the new assembly language”
Maybe – but that doesn’t mean ‘don’t bother with C++’. There’ll still be C++ games that really outshine anything that can be done in higher-level but inherently less efficient languages. Try writing a physics/collision system, audio decoder/mixer, hell, even a decent particle system in something like Python or Lua and I think you’ll run into performance limitations surprisingly quickly…
C++ is often still worth it simply for the huge amount of high-performance middleware/libraries out there. Yes, some are available to other languages, but the choice seems often limited.
But OK, C++ isnt’ exactly a good choice for prototyping, I’ll give you that. Unity is awesome, but without a solid background in ‘real programming’, it could quickly become very limiting.
As for silly-fast game jamming. Well, to be honest, I’m kind of against it. I see it as a a recipe for repeated failure and giving up. IMHO, forget anything shorter than a one-day project. Ludum Dare has hit a sweet spot with 48hr contests – anything less is a frantic sprint with no chance to really think about what you’re doing. Yeah, you can knock up a Space Invaders clone in under an hour… but there’s no real room for creativity, is there?
Just like everybody else, my analysis and solution are your toolchain (and lack thereof). I probably wouldn’t jump into unity for 2d, but there are lots of useful tools/ frameworks/ engines out there.
I’ve really enjoyed developing in python with ogre3d and pyglet and JavaScript with lab2d, phonegap, and unity one day. Take it with a grain of salt because I have yet to release a game commercially, but I’d say drop your c++ and jump on some tools with the problems already solved, rapid development, and a community you can leverage for help and code samples.
Remember, you can reinvent the wheel, but its a waste of time unless you’re already in the money or your new wheel is mind bogglingly better.
Hey – It was great getting to hang out at GDC!!! To give you my know-it-all advice: I’d say you need to get something to market quicker. And the quickest way to market is either via Flash Game License or via submitting something to the App Store. The App Store has higher rewards, but it also has a higher likelihood of failure. FGL on the other hand, seems to be a more stable guarantee of getting some vague amount of money. Flash is also a great way to vet an idea against real players. If the game is a hit in the Flash world, you can take it to the next level on the App Store. If that works, maybe follow up with a desktop version of the same game.
-Phil
As someone who suffers the same problem, I would recommend the flash suggestion. There are two particularly useful libraries/frameworks, Flashpunk and Flixel, that you would wanna try out.
Flash is flexible, easy to use, and scales very well. I know you like to do your development on Linux, and you can keep doing that simply by downloading Virtual Box and making a Windows XP image. FlashDevelop, a nice and free IDE, is not demanding at all and works fine on a Windows XP image on my linux box. The language is very much Java-like, and the IDE has nice debugging options that will make it feel like you’re developing just another C++ game. Except of course that the entire platform was made with games and multimedia in mind, so you won’t have to wrestle it to get it to do what you want. Also, both libraries mentioned above make starting the application a matter of instantiating an object. And they are both open source, so you can still write your own library if you like; only difference is you will be dealing with graphics objects right away, not pointers and frame buffers.
Of course, just like Tim said, YMMV, etc… But this is what I personally intend to do for my next couple of game projects. And from observing the community, everyone who starts off with flash moves on to greater things after a couple of successful games. And, that is the point, isn’t it?
Just to add a little balance, I’m putting my thumbs up to doing things the hard way. Yes, it’s fair to say that it’s not the most rapid way of developing a game, but you can construct the engine such that it does exactly what you want and never have to compromise your vision. Plus, for me, solving such challenges is part of what makes development enjoyable.
Then again, this is coming from a hardheaded C++ programmer working with raw DirectX 10 interfaces, so take from that what you will 😉
Remember, you can reinvent the wheel, but its a waste of time unless you’re already in the money or your new wheel is mind bogglingly better.
Words to live by! Wheels are surprisingly complex machines. 🙂
GB, as one of the comments above noted I think the problem is that you’ve been taking STH as an excellent learning opportunity rather than an excellent business opportunity.
Now, there’s nothing wrong with a learning opportunity. From your posts here and talking to you on the phone I know that you’ve learned a TON that you wouldn’t have learned otherwise. That is great and wonderful and highly beneficial, but you can’t sell a learning opportunity.
C++ may be a worthwhile language for game development, if you’re already a C++ guru. I think one thing you’re finding is that you’re not as much of a C++ guru as you thought. Also, C++ is one of those languages where you live and die by your libraries, because really, the libraries are the language/framework, not C++. C++ is a language for defining those libraries.
Earlier this year, I had a project I was working on for a conference. We had to build a mobile app for the conference, targeting iOS and Android, with at least some integration with the site. Because we didn’t want to write the whole thing twice in both Java (which I’m rather rusty in) and Objective-C (which neither I nor the other programmer on the project knew at all), we used the Titanium framework. That’s a cross-device framework built entirely in Javascript, which we both have experience in as we’re both web developers. We estimated the project at 100 hours, knowing it was optimistic.
Somewhere around 400 hours later, we launched the app with about 80% of our intended functionality. The biggest challenge we had was that we simply bit off more than we could chew. We knew Javascript, but didn’t *know* Javascript, in the biblical sense. We did not know this particular framework, or where its myriad bugs were. We did not know how how difficult debugging Javascript was, especially in this framework. We weren’t used to its model of application flow. We didn’t know the ins and outs of each of the platforms we were targeting. And then as the lead on the project I went ahead and, probably, over-engineered several parts of it.
Now, some of that over-engineering ended up saving our bacon. When we hit some bugs in the framework, the extra layers of abstraction that I’d built in kinda on principle meant we could work around those bugs in a sane fashion. But still, we essentially went into the process clueless about what we were actually trying to do. And I consider myself a very good architect and engineer, and Javascript is a flexible, high-level language, AND we had a framework to work from.
The moral? Everything is 10x more complex than you think it is. 🙂 You’ve probably seen that in STH already; things you thought were simple actually had 15 extra layers of complexity you didn’t expect once you start to unravel it. That makes wrapping your head around the entire problem space more difficult.
My advise? Don’t abandon STH. It’s a good idea, and you’ve put enough work into it that it would be a severe moral blow to abandon it (even if it might make business sense). Instead, take a step back and put STH on hold for a while. Then do something else, targeting “make it %&^* work!” as your criteria for completion. Make it as simple as you possibly can, from concept to game mechanic. Get that up for sale. Mobile apps are actually a good candidate as there are very good app store sales channels built in. Get some sort of income going, even if it’s only a very slight trickle. $5/month income is better than $0/month income.
When I say simple, I mean it. Think of the “casual” games that have been successful in recent years: Bejeweled, Angry Birds, etc. They can be complex, and have a lot of moving parts (especially Angry Birds), but the game mechanic is almost pathetically simple.
Two of my favorite games right now on my Android phone are Battleflood and Galaxy Domination. Both have pathetically simple game mechanics: In Galaxy Domination, you drag your finger from one planet to another, that is, from one colored dot on the screen to another. That is the entirety of your interaction. In Battleflood, you press one of 5 buttons to pick a color to play. That’s it. Sure there’s configuration options, but it is dead simple to play and, more importantly, the required animation is also very very simple. Both have AI, which is a challenge, but the AI in Battleflood at least can be simplified down to just a simple min-max algorithm. Those are dead simple to write. (Let me know if you want demos some time, or ask Gamble as he could easily download them.)
Pick something that you could complete with the absolute minimum of work that someone might want to play, complete it with the least effort that doesn’t lead to crashes, and get it out there. Get that win, even if it’s a tiny one. Right now I think you need to see something ship (both emotionally and financially) before you see something significant ship.
Also? Consider partnering with someone more experienced than you for one or two games. Take a junior position on a project and learn by osmosis. That’s OK. Bite off something you can chew and eat it. Then you can eat something bigger next time. (Is that the Katamari Damarci approach to game development? 🙂 )
This is all good advice and I generally agree with the wise comments here (though I’m still clinging to c++ myself, tho not desktop/downloadables ).
Personally, I would recommend finishing StH in some form before switching gears, even if that means a watered down version. If you think you make a mistake in language or design or whatever, learn from it, live with it, and do it right next time. Don’t start it over or put it off. After you ship you you can step back and reevaluate platform, language, etc.. Even just “ship” what you have as a freebie demo game if you’re fed up with it. But maybe that’s just me. I abandoned and “back burnered” more projects than I can count until I learned this hard lesson.
But mainly, big picture aside, I wanted to throw out a bit of tactical advice for finishing StH: First, pick a date and start hyping a big demo. Next, forget the code and put all your energy into the art for a bit. Make mockups, final tiles, etc. The point is to get it looking like a finished game as fast as possible, regardless of the truth of that. Then once everyone’s drooling over the (possibly fake) screenshots you have until the demo date to jury rig and hack the code until it’s just playable enough to demo.
After the dust clears, you can go back and decide which parts you need to rewrite cleanly and which parts you can ship as is. Sure, this is a cheap trick to create “artificial crunch time”, but it works.
If you want to stick with Linux I suggest using Processing or Openframeworks for prototyping. Processing runs on Windows, Mac, Linux, Android and HTML5 (processingjs). Openframeworks supports Windows, Mac, Linux, iOS and Android. Both allow development on Linux. Processing is Java (or Javascript in the case of processingjs) based and allows you full access to all of the libraries available for Java (or Android) and Openframeworks is C++ based so you can easily port over existing code. Openframeworks is generally much higher level than SDL and has a bunch of freely available libraries. NMcCoy has made 46 prototypes, including Wavespark (the game that Tiny Wings is based on), each in a week, in Processing. I’ve made 40ish prototypes and tests in processing over the years.
So you don’t have to go as far as moving to Windows or Mac OS and work in Unity or Flash, but you can do a lot to make your C++ development far more rapid. Use a creative coding framework and aggressively adopt middleware. C and C++ have tons of libraries and free code available for them you just need to look for them. If you want to do something that seems common place always Google for it before writing it yourself. Sometimes you might not like what is available and have to roll your own, but chances are you can find what you need. You might not be in the same predicament with your custom pathfinding solution if you knew about MicroPather, for example. There are even ports of Flixel for C++. Also definitely embed a lightweight dynamic language (Lua, V8, Squirrel, TinyScheme, etc.) if you continue to work with C++.
I strongly agree with everyone that you should just hack your code, optimize for speed and ease of development, not for some architectural ideal (reusability, “proper” OO, etc.) or for speed of execution (make things as fast as they need to be but no faster). You can refactor the code when it gets out of hand. Making a game in one hour is hard btw. I think 4 hours is about the right amount of time required to make a semi-decent game for most people. This is after participating in a couple of 2 hour game jams.
The last thing is that you should team up with a decent artist (and perhaps a musician\sound designer). This solves two problems. One, good art will instantly make your games more appealing (it also expands the type of games you can make), and two having someone to bounce ideas off of and keep you motivated is very useful.
[…] get back to work right away, I was able to read through all of the advice I received on my post on the importance of speed, and I really appreciate all of the feedback. Thanks, […]