"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"
I've written many 48 hour games. I've also written games that drag on for months or longer without apparent progress.
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.
Thank you for this. Could you go into more detail on your time slicing strategy? I'd love to learn how to effectively do knowledge work in short chunks with frequent interruptions.
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/)
This is one of the reasons Unity has become so popular in the industry - from a project management point of view, it makes sure that programmers don't start yak-shaving and building tech that's already been built a thousand times by other people.
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.
It's an easy trap to fall into. Refactoring something that works into a more elegant abstraction is intellectually satisfying work. One need not worry about ill-defined external requirements and is limited only by one's own creativity and capability. Adding value beneficial and perceptible to a user often requires frustrating interaction with people or organizations who don't even know what they want, much less how to communicate it in a form a programmer can work with. Often there are ugly and non-obvious special cases to be dealt with. Left to their preferences, many programmers will retreat into abstraction building instead of doing the hard work of working with users to add value or dealing with the ugly special cases, rationalizing it as the best use of their time.
I find myself constitutionally unable to build anything that isn't an engine at this point.
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.
I recently released my first real attempt at a small game beyond the asteroids clone scopd. And what I feel like I could do in 2 weeks. Took a full about a year. Several month breaks and many things just being tremendously more time consuming than projected. Fully appreciate and understand this. Part time game making is difficult especially for new game devs.
It took me about a year to teach myself how to clone Space Invaders.
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.
Your experience sounds similar to mine. I used to write games from scratch in C/C++ and I would quit the projects after I wrote most of the engine code (which would take a few months), and had something presentable.
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.
It can take a long time just to get the opengl type programming understood. I've been studying this: http://lazyfoo.net/tutorials/SDL/index.php which I think does a terrific job explaining many of the important concepts while at the same time giving you useful outline code that you can use to quickly prototype your game. Best of all you supposedly can port this to many devices (it's an SDL tutorial).
"By the time I'd downloaded the new version and fixed various issues it identified with the project format I'd run out of time and energy to continue."
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.
> Always have the next task ready and divide the work up into little chunks. The next time you find yourself with a bit of spare time you're all set and ready to roll.
This is a great technique, but takes some discipline. Reminds me of GTD.
I made my 'stupid' game - "Penguin Walk"[1] an year back over a period of three months. Like the author, there were periods of "I don't feel like working on it" but in the end, I pushed myself to finish it. Huge chunk of my time was wasted in resolving timing errors as I built it from scratch which could have been a better had I used a Game Engine.
I think to a good degree experience in the subject matter also comes into play with this. If your bread and butter expertise lies in a certain area and you were asked to write a small self-contained application in that area from scratch, you probably end up with something much closer to the goal than the white triangle on a black screen.
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.)
I got a similar story for a mod I am working on in factorio. Unfortunately, I have yet to see anybody using it in any real capacity(including myself, ironically).
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've been developing my game for more than a year now and I still only have a placeholder sprite sheet walking around in a test room. I'm currently developing a modular ui system and will continue working on gameplay after that(except probably not).
Why is framework development so bloody fun?
I just made a little iOS game too! Actually this time I managed to stay on track and get everything done in about 1 month. I honestly don't know how I did it, but it's really fun to finish a project. http://boopsboopsswoops.com/
[+] [-] Someone|9 years ago|reply
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"
[+] [-] Tempest1981|9 years ago|reply
[+] [-] pif|9 years ago|reply
[+] [-] chipsy|9 years ago|reply
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.
[+] [-] joeyspacerocks|9 years ago|reply
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" ...
[+] [-] mapmap|9 years ago|reply
[+] [-] Jyaif|9 years ago|reply
[+] [-] veddox|9 years ago|reply
> 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/)
[+] [-] tfinniga|9 years ago|reply
https://twitter.com/sandbaydev/status/403219167236857856
[+] [-] ewjordan|9 years ago|reply
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.
[+] [-] mcculley|9 years ago|reply
[+] [-] SomeCallMeTim|9 years ago|reply
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.
[+] [-] TazeTSchnitzel|9 years ago|reply
So I decide to write my own.
…and then the game never gets written.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] Namrog84|9 years ago|reply
[+] [-] krapp|9 years ago|reply
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.
[+] [-] engine_jim|9 years ago|reply
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.
[+] [-] lubesGordi|9 years ago|reply
[+] [-] asciimo|9 years ago|reply
[+] [-] Tempest1981|9 years ago|reply
[+] [-] kpwagner|9 years ago|reply
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.
[+] [-] Tempest1981|9 years ago|reply
This is a great technique, but takes some discipline. Reminds me of GTD.
[+] [-] shubhamjain|9 years ago|reply
[1]: http://shubhamjain.github.io/penguin-walk/
[+] [-] loup-vaillant|9 years ago|reply
Couldn't resist a couple minutes of playing. Good job.
[+] [-] kleiba|9 years ago|reply
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.)
[+] [-] kiba|9 years ago|reply
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.
[+] [-] Kiro|9 years ago|reply
I did and it was my first game. The sentiment definitely holds true for most though.
[+] [-] MrPlow442|9 years ago|reply
[+] [-] nathan_f77|9 years ago|reply
[+] [-] cocktailpeanuts|9 years ago|reply
[+] [-] ww520|9 years ago|reply
[+] [-] mungoid|9 years ago|reply
[+] [-] augbot|9 years ago|reply