"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 last mission (paid day job) involved writing a scripting engine (for a testing framework for programmable logic controllers). I'm no expert in language implementation, and it took much, much more time than expected (oops).
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.
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.
I generally try and have tasks of different types available for different moods (eg bug fixes, graphics work, marketing, etc). It's important for me to keep the momentum going though and even finishing a small thing is better than nothing.
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.
The next game is called Spooky Pooky and is a 2D metroidvania platformer. No, seriously.
"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.
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.
Yep; most likely you don't have Romero and Carmack on your team, who can make a great engine and a fun-to-play game, and even they switched to making engines to power multiple games (id Tech engines). Unity and things like it are great if you're serious about actually making a game and bringing it to market. Engines might be fun, but that's not what sells games and gets them into the hands of people who would enjoy them.
Even the tools and engines built by them took years to make. In fact, for a good chunk of the development of Quake, everyone was waiting for Carmack and Abrash to finish the engine.
> This is one of the reasons Unity has become so popular in the industry...
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.
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.
Some "engine" vs "gameplay" abstraction is needed though.
It's not about re-use, it's about a strategic separation of concerns allowing you to iterate more quickly over your gameplay.
You don't want to deal with linear algebra or image format loaders when you're modifying the way your enemy monsters behave.
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.
... and by "I've deleted more code than I've written" I meant the amount of code I've deleted and rewritten so far exceeds the amount of code I currently have.
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/
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"