Building FAST vs. Just Building

Just some thoughts...


There seems to be a real trend in indie game development for speed challenges, and a general attitude that if you can build something (regardless of quality) REALLY quickly, then you must be pretty awesome. I'm referring mostly to the "Built this in a day!" type posts, and 24 hour/48 hour challenges and jams.


While I can see SOME benefit in Ludum Dare type competitions, I think that benefit comes entirely from the random themes that force a developer out of their comfort zone. The "Time" element - i.e. having to get it done really quickly, has always just struck me as a negative. Something that encourages bad habits and corner cutting. I've never considered entering any of those competitions as I'm always working on something of my own and I just don't see any reason at all to participate. It just feels like an "unhealthy" distraction.


I don't think that a developer should ever really strive to JUST get something done quickly. I really don't understand that approach at all, and I'm interested in other people's thoughts on the topic.


By the way, I'm not saying that I'm "RIGHT" in any way. Clearly these sorts of challenges are very popular and a lot of people must get some sort of benefit out of them. I'd genuinely like to know where people stand on the topic.

 

"24 hour/48 hour challenges "

Well, that's all they are really. Just challenges. Not to be taken too seriously.

 

There are lessons that can be learnt no matter how long the timeframe or what the project.

 

It's to get devs to build a habit out of finishing games and committing to them. A lot of game jam games end up being polished and released.

 

I think it really has the opposite effect though. You FINISH a game by committing to it and working at it over time, not by rushing to try and get it done against a stop-watch.

The stuff that gets "polished and released" happens AFTER the allotted time period, which just adds weight to my point - that WITHIN the time limit, only low quality results are generally being produced.

I guess one of my main points is that it takes MANY things to build and complete a quality game, and one of those things - arguably the most important - is TIME.

 

They are meant as challenge and for fun. Some have themes like Molyjam which are great for creative skill building.

Jams have been around forever, they are a nice break from routine, and a great way to stretch your skills. And working quickly and efficiently is a component of developing games, certainly if you do it professionally, but also for small and individual developers who ship games. Bug fixes post-ship usually need to be done quickly.

It's simply a skill building exercise. (and fun). It's like any exercise or learning endeavor. Often the games do appear low quality, but part of that is simply cutting away parts to get down to the core gameplay and being able to complete it in the time allotted. If someone is a hobbyist, then sure the whole concept is a little redundant. If one is building games for a living (indie or pro), its great way to hone critical skills like time management, setting priorities, working efficiently, staying focused, and being creative under pressure. And a fun social event.

If you take it for anything more than a fun exercise, your missing the whole point of them. (and the fun). If it's not your bag or interest, then don't worry about them. They aren't mandatory.

 

Yes and no.

A lot of things aren't finished because they don't have a finish date and therefore it's easy to scope creep forever. Short challenges force people to design minimally, which often results in them creating something cool that, while not polished, can be finished in a few weeks to a decent release quality.

Nobody expects that the things made in a short jam will be of commercial release quality within the jam period. The idea is to get people into the habit of finishable projects rather than epic forever projects. Also, it encourages people to try out ideas that they might not otherwise actually work on, encourages a sense of community, and is often a great learning experience.

The point isn't to make something releasable in a day or two. It's to give something a go in a day or two which might never have been more than an idea otherwise. The fact that people bother to finish them off and release them afterwards lends weight to our point - which is that cool things often come out of such jams.

Also, it forces people to focus on the core of their game's design rather than heading towards feature decadence. There's no optimum place to sit on that spectrum, but it's easy to slide towards the latter if you're just creating things for fun and aren't focussing on finishing something.

Exactly. And a lot of that time is wasted if people don't learn to manage it properly, which is something else that a short projects are great for learning about. In a short project you learn the impact of decisions on your finish date very quickly because the impact is obvious and dramatic. Spend 2 days of a one month project on something that turns out to be a waste and that's 2 days less to polish, or another feature you now simply don't have time to do, and you'll feel that when the deadline comes around.

On the other hand, if your deadline was over the horizon in the first place, pushing it back a few days here and there doesn't feel like much... and suddenly your 12 month project has actually taken two years and there's still a lot on your to-do list. If your answer to everything is simply "we'll take more time to do it" then you'll never finish your project. Everything could always take longer, and if you're not disciplined about managing that...

The other way to learn about this quickly is to look at budgets in a business sense, but that doesn't apply to most indies since there are typically no actual budgets.

 

Its called a CHALLENGE for a reason

If you take your sweet time to build a "quality game" its not really a challenge is it? Anyone can take a LIFE TIME to build and polish a game.

Also, it is actually detrimental to build your game slowly. Any game taking too long to make will always end up being pretty average or down right HORRIBLE. Cases in point :

Battlecruiser 3000AD - used to be the longest game in development - 7 years - until Duke Nukem Forever came along.
Duke Nukem Forever - 15 years in development
Daikatana - 4 years
URU - 6 years
Heart of Darkness - 6 years
Too Human - 9 years
....just to name a few.

 

So by that reasoning, you think that ANYONE - given enough time - can create a good, polished game?

Of course this is true in some cases, but it's false in an equal number of cases. And who defines "too long"?

It's just as easy to name games that took an extremely long time to develop which turned out to be masterpieces

To me, a "CHALLENGE" is sticking with a game throughout a long development process and producing a high-quality end result. Whipping up a basic game in a couple of days is child's play.


Mind you, there are always examples of truly brilliant game ideas that come about quickly, but I don't think that the fact that they were developed quickly should be their major selling point. Remember, I wasn't talking only about the game jam type stuff, but about developers in general who proudly make posts about the fact that they've made some crappy mini-game and it "only took them 3 hours!" (etc). This shouldn't be a claim-to-fame, but a sign of development immaturity.

 

Personally, the reason why I do the jams such as Ludum Dare is not necessarily to make a game, but to finish one. They may not be good practice for producing quality work, but they are fantastic at letting one practice both setting and reaching deadlines. The forty eight hours forces somebody to finish a game. Often I find that if I do not set a deadline I will find a task just dragging out indefinitely. I do not do the contests to practice making games. I do to practice time management and making and completing deadlines.

 

Maybe that's why I've never seen the value in them - and this is going to make me sound smug, but believe me I don't mean it that way - I've never had issues getting my games finished. Once I start something, I can't get it off my mind until it's finished. Maybe I'm just lucky that I've got some obsessive gene or something. And again, not saying that I'm producing amazing stuff or anything - just that I'm able to get things finished no matter how long they eventually take.

 

Well... he didn't say finished or good. Just that they can spend their whole life polishing and building.

---

Game jams are just fun and great for getting stretching the creative muscles. And really, few people have the ability to actually complete a jam with anything really functional, but everyone can still have fun. I can also be great opportunity to try out new method/lang/engine that you wouldn't normally use or to build a game outside of usual games you build. In the end, it is the "game" industry. The clue is right there in the title. If you aren't challenging yourself and having fun, what is the point?

Since I was little, I loved puzzles. Puzzles of all kinds. It was always a natural progression for me to go from playing puzzle games to trying to figure out how to make puzzles. That is how I see making games, just as a big complicated puzzle. My professional role is essentially doing just that, solving the weird/complicated/unique challenges that arise when building games. To me, all the joy in building games is about solving the challenges and problems. Jams are meta. Its a game to build games. I just don't see how anyone who has chosen a path of building games can't at least appreciate Jams for what they are, even if they can't do them or don't have the interest in doing them.

 

I'm guessing you've never actually entered one of these game jams, right?

You should. Just once. I know you think they're useless, and that the time limit is a massive negative... But you're wrong.

What I find is that the time limit lets you focus on what's important. All the usual dithering and worrying *has* to be thrown away because you simply don't have time for it. Instead, you make decisions fast and you just get things done.

I spend the 4 months between each Ludum Dare flitting between projects and generally getting nothing done. But during LD, I sit there, focused, and just knock out a game.

In theory, I *should* be able to do this every weekend, or even spread it out over a month. But that just doesn't happen.

Other people learn different things. They learn how to finish a game, or how to trim a game down to its essence, or how to budget time better. Novices in LD learn more about what they don't know. They find out what parts of their tools that they're woefully unfamiliar with, and what they need to focus on before the next LD if they want to succeed.

There are a ton of reasons why LD is great practice for gamedevs, and that's why so many enter each time. They aren't fools.

 

Have you ever heard of "Infinite monkey theorem"?
(Where they posit given enough time, a hypothetical monkey typing at random would, as part of its output, almost surely produce all of Shakespeare's plays)

Good point, and it is indeed a matter of perception - as people can get burn out by the project, which is largely a matter of perception.

Daikatana was consider the longest FPS game in development which was originally planned to be done in seven months. It took 4 years went through hundreds of developers (many of them burnt out and quit in the midst of development). Nowadays 4 years is consider relatively short for FPS development.

Of course, I won't argue with that. But the longer it takes to develop, the more resources you have to throw in with more uncertain return of investment, which translate into anxiety and can demoralize individuals or the whole team. This in turn decreases the productivity, which slows down the development and creates a perpetual vicious cycles which doomed a lot of game developments and turn them into vaporwares.

I thought those "challenges" are not merely about producing workable games in shortest amout of time possible, but CREATIVE and QUALITY game at that. Time constraint is merely part of the challenge, but not the whole challenge.

Sure, but I also believe "creativity is born out of combinations of necessity, stress and desperation" !



PS. UT take note! The monkey above is well on his way to write his Unity 6.0 game engine!
AND HE PROMISED GUI !!!

 

What's the goal? I aim to be a master of my craft, and that means learning, trying, and failing, in the fastest loop possible. So far, my skills have improved dramatically. Programming, art, design, story telling, business, monetization, marketing, and more. Fast projects take me further, faster, than working on a 'multi-year project' which is never finished, and never published.

Angry has it right. And for anyone considering a Ludum Dare, et al, there's really just 2 questions: 1) Does my life allow participation? And 2) What else would I be doing that would take my skills further, faster than a massively intense, forced opportunity to build a game without consequences for failure?

Gigi

 

Have you looked up the definition of smug? The Coldfire thread began on Jan 12, 2012 - which means at least 19 months in progress. Hardly seems the right pedestal to proclaim Challenges and Dares a waste of time. Since you began Coldfire, I've released 6 products, in my spare time. I've succeeded and failed, in ways I can hardly remember, and that has pushed my to go further, until I was able to touch the lives of 90,000 users.

When I looked up 'smug' in the dictionary, all the definitions I found included the word 'complacent'. A poor recipe for both growth and success.

Gigi.

 

24 hour developed games sound like a great exercise to me!

Being able to encompass long tasks into "quick rough shapes" is a great skill. Perhaps you could say it's a must to be able to apply this expertise before getting in really lengthy enterprises.

 

^ This.

That's why I settled for a 6-month timeframe on my current project [/stealth-plug!] I can devote at most two hours of dev time a night, but I still have a hard deadline to meet, and thus something to measure myself against. At any given time I know where I am on the timeline, and roughly what I have to do to get to the destination I want to get to.

Deadlines are not evil, they're a goal that must be reached, above and beyond merely shipping the product (which, is a compelling one.) While I don't have the code base to participate in a 24/48-hour project (yet, I'm working on it...), The fact remains that it's great because it forces you to cut out ideas you really don't need and create that focused experience.

Whether you choose 6 days or 6 months, for me the takeaway is that deadlines can be a good thing, and help your project by being a way to fight scope creep.

The caveat, though? Self-imposed deadlines can be altered if necessary, which is a tool that lends the practice flexibility. Something to think about.

 

^ This
Gigi

 

I've got a question for you mate.

How many full featured projects did you complete before actually working on a day job for a couple of years?

Working teaches you routine and basically "sitting on your ass and doing stuff".

The challenges make you set a definite goal and sets you a deadline. Finishing anything - no matter how polished is a hard task - many developers fail to get there. Deadlines and goals help you do that. The feature creep is far more deadly than corner cutting. Overdoing your work and adding a ton of features in the last moment, then polishing those then doing that again usually leads to abandonment. Corner cutting on the other hand makes you do whatever you have to do to finish.

Another thing is the creative barrier - boundaries make the difference between indie and AAA games - indies have the limited resources, those make them think outside the box for solutions and put their creativity on steroids. This boost is a great start for a project and after the 24/48 hour challenge you have an excellent first prototype of your idea.

Released games could be improved. Let's call the process... patching. But unreleased ones couldn't. You can add all the features you want but they won't be played by anyone so the actual improvement would be none.

 

Let me start by saying I've got no problem with doing a few fast projects to gain experience, I've done the same thing myself and I would certainly promote it as a good start for a beginner or anyone struggling with finishing a project ... but hasn't this cult of mediocrity gone too far?

Gigi proclaims that "The most important metric is: the number of previously released titles", even if there was some data to back this claim up (I've yet to see it), its quite likely that correlation doesn't imply causation. Maybe people who release a lot of titles also have a lot of experience (kind of follows doesn't it), or are just the kinds of people who are so committed to their dream that they will succeed no matter what. Maybe its just the medias preferred narrative, but most stories I've heard involving indy success involve long projects, constant reworking, and a dogged commitment to an artistic vision.

In the end your version of success probably involves some mixture of critical acclaim and financial reward. Its pretty certain you are going to need to release something to get either of these (no argument there), but you know what, your game is probably going to have to be a good one too.

Keeping that in mind here's a rule of thumb you might want to consider:

If you get to the end of your 12 weeks or 48 hours (or 6 months or whatever) and every time you show your project to someone you have to tell them how long it took you to build then you probably need to do some more work.

 

First of all, there is data to back this up. I'll try to find it when I get home if I remember.

Secondly, you're correct that correlation isn't causation, but that doesn't mean there's no value in the connection. There's a very good reason for the correlation, which is that successful apps are much more likely to be made by people who have made many apps than by people who just make the one. It doesn't matter if the app you're putting out is your first or your tenth, assuming equal quality (where in reality quality is likely to increase over multiple titles) your tenth app is as likely to be a success as your first. The difference is that if you've made 10 apps, you get the opportunity for that success 10 times, where if you only make the one app...

This is basic statistics. Try something 10 times and, all other things being equal, you're 10 times more likely to succeed at least once than someone who only tries once. And since longer projects aren't necessarily better for learning than short ones (they're usually worse) the guy doing more projects is likely to improve much more along the way, and thereby increase his chance of individual successes as he goes, too.

Gigi didn't get his 90,000 downloads by spending 2 years on a single title.

But your rule of thumb does nail it. If you have to make excuses about the thing you're showing off, then it isn't finished as far as releasability is concerned.

 

This is worth a post of its own.

"Building fast vs. just building" entirely misses the point.

It's not about building fast. It's about finishing fast.

You shouldn't build at any different speed to normal. It's not about coding faster or making things more quickly or anything else you think you might be able to do to produce more in less time - aside from practise, I've never found anything that increases my productivity past normal levels that actually works.

The purpose of finishing fast isn't to do more in less time. It's to optimise what you do, not how you do it.

When tasked with making a game in 48 hours I don't think "gee, how can I do this more quickly", I think "ok, so what can I realistically achieve in 48 hours" (lesson 1: know your capability and lesson 2: set realistic but challenging goals)? I then design accordingly, and I get something that's finished as far as the purpose of the jam is concerned, which is typically just something playable by other developers (lesson 3: know your target audience).



On a last note, I strongly believe in the idea of "fail fast". (It's a bit of a buzz word these days, so give it a Googling.) That is to say, if you want to succeed at something, accept that you're likely to fail a few times along the way, and seek to get those failures behind you as quickly as possible should they happen. However, note that the important bit isn't the failing, it's making sure that you learn from the failure to apply its lessons to your next attempt. To bring that into context here, if each attempt is years apart, you don't have a lot of learning opportunity. But if your projects are short you get that learning opportunity every few weeks or months.

There are examples and counter examples for both sides of the coin, but ask yourself in general: Who's learning faster, and who's more likely to reach success first?

 

I don't dispute that more apps give more chance for success, but I do dispute that more mediocre apps gives more chance for success that one good app. The thing is that its becoming a dogma around here, as if its the only way to succeed.

"Gigi didn't get his 90,000 downloads by spending 2 years on a single title." .... "Team Meat didn't get their 1,000,000 sales by releasing a game every 12 weeks"

Obviously that that kind of argument is not very useful.

In my opinion Gig's apps succeed despite their lack of polish due to a unique message, something that not many people are going to have. Lets not overlook the fact that they also aren't games, most people are here to make games. And if I want to be a little snarky ... 90,000 downloads is not exactly a great success (although the large amount of 5 star ratings is)*.

The 12 week challenge is a great idea, the rinse and repeat part should at least be taken with a grain of salt. There are many paths to success, and what works for one person may not work for another.

* Had to add an additional edit here, as leaving the comment as is sounds terrible. 90k downloads is cool, thats a lot of users, and more impressive is the high rating, however its a long way from I can fund my game development studio for the next few years kind of success.

 

Oh, really?

In 2008 Ed McMillen released 5 titles. We of course don't know the development time for each of those, but that's very much in the ballpark of 12 months a piece.

Super Meat Boy itself took significantly longer, but could he have done SMB and reached its level of success without the experience of the 14 known titles he finished before that?

It's 90,000 more downloads than an app that will eternally be finished "later" will ever get.

It's also around 89,900 downloads more than most apps ever get.

 

You can just easily argue than when he gave up on producing those stupid little twelve week games his big success came.

My point is not don't release lots of little games for experience (I have said that its a good idea several times, and its exactly what I did when I started messing with Unity), my point is that its more likely your success will come from your big projects.

Thats what worries me about the cult ... the message seems to be keep producing small games, the message does not seem to be produce some small games for experience and once you have it find the game that you are passionate about or the game that resonates with the market and build that even if it takes quite some time.

 

I don't know about that. I for one have always said to start with small projects and work towards bigger ones over time.

I encourage people not to start by making GTA or an MMO, not that they shouldn't work towards eventually getting to those.

Sure, but it's a pretty weak argument when you look at all the people who jump straight to their magnum opus (which is usually much bigger than SMB - lets be clear here, that's not a huge game itself) and never finish or release anything, or release things that took 24+ months but still have first timer mistakes at their core (many of which are the cause of such a long development time - many 2 year projects could be done in less than half the time if the developers were more experienced before they began).

 

We'll I think I have been pretty clear that I have no problem with doing small projects (seeing as I have explicitly said that numerous time ). But I consider them to be a means to an end in most cases (i.e. you primarily do them for experience or to test the market). You seem to be saying the same thing.

I also consider hard deadlines to generally be a bad thing. Something that should only be introduced if you do have a problem getting things finished. Not every one has this problem Just to be clear this doesn't mean you don't have target dates, and it doesn't mean you don't try hard to hit them, it just means that if it comes down to a question between a date and a significant improvement, you have the option of choosing the significant improvement.

However the 12 week post seems to me to have morphed in to a general philosophy of only ever build small games or at the very least always have hard deadlines, maybe I am just misinterpreting it.

I think after a few small games it becomes much less useful and although I'm sure you still learn *something*, you miss out on learning about the additional complexities that come with larger projects.

EDIT - In the end I'm just not a fan of some certain viewpoint becoming dogma; I see the same thing with development paradigms all the time. Agile is the only way! SOA to the rescue! TDD is the best!

 

My son might ask, 'Do you even google?' I will simply point to some data.

Let's go back in time? Super Meat Boy (2010) was not Edmund McMillen's first release. His official list of released titles goes back to 2003, and includes some 20 titles. Which of course, is not counting the many other smaller projects, which are known only to him.

And consider the other 'Overnight success', Rovio. Which of course, neglects the 52 products others might call, a failure.

When I researched these 'many paths', I found they all led back to one truth - mastery requires practice. And practice implies learning (via growth mindset), which requires feedback. And I've found most of the feedback I get, while sitting in my closet, perfecting my latest shading technique, is not as helpful as it could be.

Gigi's Challenge is not the only path, it's just an effective one to achieve failing fast. And as my wife like's to say, "Until you have a better plan, this one's as good as any."

Gigi

PS - I build Unity apps in my night-job, so I won't conflict with what I build by day. Now back to game-design principle's and publications.

 

I've had plenty of dreams, where I discovered the perfect solution! Only when I awoke, I was rarely able to piece things back together. See, in dreams, my ideas connect directly to each other within System 1 (Think Fast), and upon waking, System 2 (Think Slow) gets involved and I realize there were lots of gaps between A Z. Which is kind of what happens by setting out too early on a multi-year development saga.

It's the Bullets-Then-Cannonballs approach, as described by Jim Collins, in Great By Choice - the strategy of doing lots of LITTLE projects. By learning, growing, and experimenting, this increases the odds they'll hit something! At which point, they load up their big guns! The bad companies think their one idea is the Shiznit, and so load-up prematurely.

This is why I encourage the 12-week challenge, hoping young developers will get on with the doing, instead of fantasizing the coulda-shoulda-woulda when they took on more than they could chew. My hope is that a few of them will become, as Steve Martin is famous for saying, "Too Good To Ignore."

Gigi

 

Maybe my google foo isn't up to speed but yes I did google and no I didn't find that one survey. I would still say its pretty far from definitive. Did you consider for example that maybe the people who produce 10+ games are the people who are having success earlier and thus keep producing games?

Anyways I think you have somewhat clarified your position, I must admit that your posts did not come off as "fail fast" to me. There seemed to be a missing step of finding the good bits and sticking with them, improving them, etc, but I guess that was just my poor interpretation skills.

 

I'm still learning the art of motivation - in my apps, my presentations, and in my writing. And one of the things I've learned is that the reader is not a dumping ground for knowledge. By following Will Wright's advice - "Your garden is not complete, until there's nothing else you can remove", I am more likely to make a lasting impact, and sometimes, that means important details may get less attention than they could.

I can only hope that somewhere along the way, they stumble across my signature line - "The Secret of Success? Fail; Improve; Repeat" -- aka Fail fast.

Gigi

 

Defining a realistic scope based on even a rough timeline is hard enough for developers with tons of experience. If you have little to no experience, how are you going to gauge with any reasonable degree of accuracy how long a game project is even supposed to take under ideal conditions? A beginner may think that their "significant" game will take 18 months to develop, but in reality it may be something that would take many years to complete. It does make sense to develop smaller games first, if only to get a handle on what can be produced in X amount of time. Then when it's time to pull the trigger on a more significant game, there's a better chance of that 18 month game actually taking 18 months to finish.

 

That doesn't seem to be relevant to the quoted text, if anything its an argument in favour of it. If you aren't able to accurately define scope then how can you possibly have a hard deadline.

And yet again I will say I have no problem starting with small projects, I have advocated them on many occasions, done a few myself, and said this very thing multiple times in this thread. My concern was that the small projects were being pushed so hard that the message of improving (and expanding) was being lost.

Anyways I'm signing out from this thread... I think I've made my point, maybe its going to help with the clarification of the message maybe it wont, but its enough from me; back to building games and providing support to my customers.

 

Yeah, but take a step backwards and consider how you learn a) how much you can achieve in a given amount of time and b) how to manage scope around that. Do you want to make your rookie scoping mistakes on a weeks long project or a years long one? And when you're starting out do you want opportunities to analyse outcomes and decisions every few weeks, or every year or two?

Considering that the reflection and application of new knowledge to subsequent attempts is where the majority of the learning comes from people doing short projects have a massive advantage here.

You don't learn to deal with deadlines without working to deadlines. And without something against which to measure time costs again you're very likely to solve more problems and make more decisions based on throwing more time at them.