How to write a 48-hour game in just 2 years (2013)
fistfulofsquid.com
fistfulofsquid.com
That reminds me of http://rampantgames.com/blog/?p=7745:
"In the main engineering room, there was a whoop and cry of success.
Our company financial controller and acting HR lady, Jen, came in to see what incredible things the engineers and artists had come up with. Everyone was staring at a television set hooked up to a development box for the Sony Playstation. There, on the screen, against a single-color background, was a black triangle.
“It’s a black triangle,” she said in an amused but sarcastic voice. One of the engine programmers tried to explain, but she shook her head and went back to her office. I could almost hear her thoughts… “We’ve got ten months to deliver two games to Sony, and they are cheering over a black triangle? THAT took them nearly a month to develop"
My first hello world involved handling arbitrary primitives. This one just printed "Hello, world!\n" without any parameter. Took me 2 months I believe.
My second hello world came a couple weeks (days?) after that. I had string literals, and a `print` primitive that could print any string. Yahoo!
I had to tackle choice and iteration at some point. They were completed 4 months into the project. Finally, user defined functions. I completed them 1 week before we shipped…
Cool, I now have 3 days to implement 2 critical features! (filtering with user-defined predicates, and non-blocking wait). Good thing I could do anything, now that I had user-defined functions.
The difference literally comes down to whether you are doing easy things or not. Having an engine or framework does help make a variety of things easy, but it does nothing for the one or two features that aren't. Eventually you hit a wall where it takes forever, and that's your next month. You get over the wall and then a flood of other new features come in almost instantly. Also in the same ballpark are features that you have coded before and are familiar with, vs. ones you aren't. You can get a lot done "from scratch" by spamming preexisting knowledge at the problem, but it still takes time and it isn't exactly easy either.
Last of all, at first clone-and-modify is enough to feel interesting. So you go very quickly, because you care little about the result. But after a few dozen times doing that, you're done, and you want to expand the parts you care about. That creates more barriers to get over, more months where progress is slow because your ambition is big enough to no longer follow the easy path. More months where problems are on the content development side, not the runtime. That part is always difficult. Scope is deceptive.
It's lies, all lies :) actually it's probably solid advice - the hard bit turns out to be following it.
The missing piece of advice turned out to be - "stay disciplined" ...
Some things just require more time/thought though, so sometimes I have to shelve things and tackle them when I have more time.
Sometimes all I get done in 30 minutes is to make a decision about how to do something - this is still progress and feeds into the next spot.
"Horatio Bones is a curious lad.
Working late one night at the Nefarious Science Corporation he strays into a deserted sector and unwittingly triggers ... The Machine.
The Machine strips Horatio of his fluids and organs ~ he finds himself reduced to a living skeleton trapped in a specimen jar!
The horror!
Thus begins the longest night of Horatio's life as he travels through a dangerous and bizarre world in search of Restoration."
Like QB1-0 this is also being written in C + OpenGL, although because I'm now aiming at PC/Mac/Linux and iOS I'm using SFML to give me an OpenGL context and for Audio + controller input.
More info at http://fistfulofsquid.com and there's a devlog at https://forums.tigsource.com/index.php?topic=42130 with loads of techy details.
> Don't build an engine instead of a game
Only too true... That's a trap I always fall into. I guess programmers are so hard-wired to abstracting problems they that need solving they end up doing a lot of abstracting and very little solving. (Compulsory xkcd: https://www.xkcd.com/974/)
It certainly has its warts, esp when going into full production, but at least in early development it's really good at making sure you're only building what's unique to your game.
Yet someone had to decide to write Unity. Obviously, writing a framework/engine that gets this kind of popularity is in the "unicorn" range, so it's probably not something you should bet on. Still... it could be your engine! :)
/tongue in cheek
EDIT: Just to contribute a little bit of actual content: I find the "7DRL" episodes of Roguelike Radio to be very informative as to what you need to focus on when trying to ship a game. Obviously, it's focused on turn-based games, but I think most of the experience applies to basically any software project.
So I decide to write my own.
…and then the game never gets written.
When I was young and inexperienced I could crank out Crap That Works(TM) in seemingly no time at all. At this point I know how to write good code and crap code is just too painful to look at ever.
So I write good code, and I don't attend 48 hour hackathons.
Of course, on the way, I taught myself how to deal with spritesheets in SDL, move semantics in SDL objects, built a rudimentary entity-component framework, and basically had to learn how to do everything that SDL doesn't do for you.
I'm still working on my January Game a Month project, and a lot of that time has been eaten up just getting the camera to work the way I want it to. I've deleted more code than I've written, and the end result is still not a game, but the learning experience alone is worth it. Some things that seem as if they should be simple (like efficiently dealing with text) turn out to be more complicated than expected, at least for me.
Back then there weren't engines like Unity and Unreal that solve most of the technical problems like rendering, and physics/collision detection. Even with these tools though, I still find it difficult to finish a project quickly because I spend so much time writing infrastructure code. For that reason I never do hackathons.
Haha. About a year ago I went through 6 hours of updates to get a python script to create mouse and keyboard inputs (moving the mousing and typing to interact with gui apps). After that I called it a day and have barely touched the project since.
This is a great technique, but takes some discipline. Reminds me of GTD.
Couldn't resist a couple minutes of playing. Good job.
I found it very enlightening to sit through the almost full 48 hours of Notch programming some Ludum Dare entries which he streamed on twitch.tv. The end product is often very hackish, but that's exactly what this article argues could be a strategy to success. In any event, you can tell that he has programmed similar exercises many, many times in his life because certain things that would take me days to get right, he just writes down more or less without thinking.
Not writing your own engine is also a recommendation that can be seen from two sides. Of course, for a lot of us, it is tempting to go and try writing a re-usable, nicely abstracted and modular piece of software. But for a 48h jam, that can often be the wrong direction, because you get side-tracked writing your nice game engine and meanwhile forget to actually write the game.
However, at the same time, referring back to the aforementioned videos by Notch, he likes writing everything from scratch and not use a pre-existing engine because it can give you full control over what you can do and how, which for a 48-hour jam might be what you want.
(Notch and these videos have been the subject of discussion on HN many times before, so there's probably no point to going down that road here again. I personally find it sad that he doesn't seem to stream any more programming vids.)
The reason is simple, I believe? Nobody knows how to use it beyond myself.
Even if that isn't the case, I still need to work out a tutorial anyway.
I did and it was my first game. The sentiment definitely holds true for most though.