I participated in One Game a Month (1GAM) in 2013. It was an amazing experience, even though I managed to make "only" 5 games. It's astonishing to read that the author had the very same problems I had.
Even when I had a clear vision of what I wanted to make, it was pretty hard to avoid feature creeping. When you hit the 90% completion mark, the TODO list starts to grow so scarily fast that the only way out is to develop/improve focus and the ability to ship things. That's when you level up as a developer :)
1GAM is a great opportunity to learn how to ship things, managing time and scope.
This seems like such a fun challenge. I just completed my first Ludum Dare Jam with a friend (72 hour gamejam), and we both learned a lot. Right from the start we had to manage a "72-hour TODO" list and a "Maybe we'll enjoy this game enough to take it past the weekend TODO" list. And things kept being moved from one list to the other.
I think the most important take-away for me was how important careful planning is right at the start. As we got closer and closer to the deadline, the code got nastier and nastier. But I made sure we spent several hours just planning our design before even touching any code, and that the foundation was solid. It wasn't until the final 6 hours or so that we had other entities animating on the screen. But by then everything just came together, and filling the game with more content and additional levels was a breeze. Need to add a complex feature? Great! We've already planned for it, and it takes 2 lines of code.
There's a short little blog entry I read years and years ago that I still remember, called "Black Triangles" which is similar. About developing a game for the original Playstation, and spending over a month to just get a black triangle rendering on screen. http://rampantgames.com/blog/?p=7745
We actually have decided to take our little game past the weekend, so maybe this will become our first One-Game-A-Month Game.
Yes, it is a lot of fun. I used two TODO lists just like you did, but my "v2 past the deadline" list had way more items in it.
I like to plan my actions methodically too, but sometimes I had to use 1GAM to develop my improvisation skills. When I was short in time and the month was about to end, I had to quickly come up with something before the deadline. That's when I had to prioritize the "get things done" instead of "plan the whole thing". I've learned a lot from it.
I wish you and your friend all the best regarding you game :)
You're welcome! One of the best aspects of 1GAM is the community behind it. You can get feedback, motivation and experience from everybody. When you join the action, there are thousands of developers doing the very same thing: trying to ship games. I've learned a lot from the community and I've met several great folks.
I very much enjoyed this report, and especially the fact of a significant target of your attention being the ZX Spectrum - this is a true and honest approach to the programming art!
:)
Its definitely true that even learning older architectures can sharpen your focus and skill, general platform dexterity. You may not use a lot of the Z80 assembly skills elsewhere (but then again; you might), but for sure the bounds of your depth and understanding of how computers work today are definitely reset. Sure, stay 'focused on Ruby'/et al. - but if you have to pace yourself at your day-job, having a fun project/waste of time in the same department albeit with significantly fewer bits is also, as in such an attentive case, a professional perk. Old computers never die; their users do!
In regards to the Speccy: there is still a nice community around it, developing even new hardware for it: e.g. you can easily attach SD cards or newer hard disks to it, and boot speccy games in a second, there is networking etc.... go to worldofspectrum!
Actually .. I'm an Oric-1/Atmos fan, and have also recently been able to give my old 8-bit collection a revival courtesy of disk-emulators being released for the old hardware .. it has re-opened the old world to me again and again, and I have the privilege of watching my kids get into it now, too .. nothing quite like the sanctity and peace of mind of having the kids use a computer that has very little chance of running a web browser, though. That's something the speccy users have got up on us Oric people, heh heh .. ;)
I found Z80 assembler quite interesting (I had previous experience with Intel 16 and 32 bit), and Z88DK supports inline asm so it wasn't too bad if you can restrict the assembler code to small routines and still do the main bits in C.
I've had the Oric-1 OSDK (http://osdk.defence-force.org/), which offers the same universe, in my hack/inbox for a while now .. its an amazing thing to return to these old architectures and realize just how much we take things for granted today, and yet - in spite of the limitations - the things are still just as useful and interesting as they ever were. 'tis a delight to witness a 7-year old and a 5-year old pillaging through an ancient (30+ years) collection of floppies and tapes, and .. gradually over a few months .. accruing their list of favorites on the 'bookmark disk' from the collection, such that it is (* -). An 8-bit machine with 8 gigabytes of storage available is a truly profound and superlative new realm for exploration. I'm glad I'm doing it vicariously!
"and realize just how much we take things for granted today"
Well, Z88DK has some... bugs. It is definitely a new experience when the compiler segfaults because a syntax error ;) To be fair, I'm glad it exists, but it got me busy for few hours because of a couple of bugs less evident than a compiler crash.
My experience when I was 13 was with the Spectrum, but after getting back in contact with "the old 8-bit world" I think the Commodore 64, the Amstrad CPC, or even the Oric could be quite interesting to revisit and explore; and I'm sure there are still some users out there that would love new software!
I'm surprised the author criticised their artistic ability so much. I found the art style quite endearing and seeing the different graphic styles to emulate different systems was impressive.
I'm a little bit better now, but I guess it looks different when you see the end result. Believe me when I tell you the process was quite painful and it involved starting over several times :)
Out of curiosity, what tools do you use to make the artwork for your games? Anything outside of the standard linux image applications (gimp, inkscape) ? I've always been curious about making my own game, but when I sit down to work on the art assets, I end up getting very frustrated and tend to put those projects aside.
I use Gimp mostly, once I learnt how to tweak it for pixel art it is quite good.
For me all starts with the right palette. It really helps to get what you're looking for. I usually work with 64 colors (unless there's any special restriction, of course).
For me it really helped to configure Gimp for pixel art: set the pen to 1 pixel, save some palettes, set the grid to 8x8 when doing Spectrum graphics, a keyboard shortcut to show/hide the grid, etc. Gimp defaults are not good for pixel art.
Other than that, jut zoom as needed. I usually scale the games x3 when trying a retro style, but in Gimp I draw mostly at x8.
I mean, it literally means "after death" and stems from the name for the study of dead bodies, so it seems odd to name any post-facto report a post-mortem and the Wiki article may apply to gaming industry but it's not really common industry usage.
Normally in tech, a post-mortem is a particular kind of analysis, backtracking from an incident to figure out what caused it, with the aim of preventing it happening again and improving quality overall (aka "incident report").
There have also been a number of "startup postmortems" recently, which means just as it sounds.
Not if you consider it a post-mortem of the development. When the project is done, development is dead (cue: pedantic comment on product life cycle). So it's not technically a post-mortem of the game, but a post mortem of the development process of the game. The post-mortem's at Games Developer/Gamasutra are typically for commercial games, and often offer a retrospective of launch and relative popularity as well.
Someone can die, but not have been a failure in life. I've always taken post-mortem blogs to mean "We're not working on this anymore. Here's what we learned during the time we did." The reason for a project ending is often failure, but it doesn't have to be. I've seen several post-mortems about successful projects, they're just not nearly as common as the failures.
>> "Someone can die, but not have been a failure in life."
I think it's referencing the fact their body has 'failed' i.e. died. Not that they were a failure in life. A post mortem is usually carried out to figure out why the person died i.e. what part(s) of their body failed.
I like how anna anthropy suggested using the phrase "post-partum" instead of post-mortem, as a game only really becomes a living thing once it's been released to the public.
I can't really tell, but I had to be very effective using my free time. Sometimes is 30-45 minutes before going to bed, sometimes is waking up early on weekends.
I don't watch TV, I read only a couple of books this year, etc; always keeping in mind that there's some free time that must be dedicated to your family no matter what.
EDIT: I could check the repositories to get an idea, although that doesn't represent the exact amount of time, could be a good estimate.
It reminds me of how I write and continue to edit my first full-length novel: two hours a day of drafting, for three months, and an hour a day of editing since. It's a small amount, but it's really added up.
Thanks for this. I am currently in the middle of month 1 for 1GAM and appreciate the inspiration. It is awesome to read about a person experiencing the same issues as me, then overcoming them.
Thanks for this. It's very interesting and is inspiring me to consider taking it on in 2015. Though I'm not sure if that's a good thing or a bad thing. :)
This is great. Something that I'm sure I and many other developers suffer from when it comes to projects at home is "it's not done yet" syndrome, usually to the point where it's never done and gets abandoned.
I think I personally could do with doing something like this in my free time.
Crosswalk has the downside that it produces huge applications, at least relatively speaking (30+ MB). Is plain old Cordova viable if you want to ship an application that runs on Android 2.3 onwards? Reading their blog I think they have fixed the issue with hardware acceleration on KitKat.
Unfortunately no. There is a HUGE gap in the WebViews that ship between 4.0 and 5.0. Also, WebGL is not supported by any native Android WebView until 4.4. CrossWalk effectively lets you ship the latest Chrome WebView for all devices running 4.0+
Grats! This is a great accomplishment. Releasing teaches you 1000% more than just making a demo and not releasing. There's lots of little things you need to do extra. Then you learn from the crits, feedback and reviews of others.
Huge props for diving in to a mostly-extinct platform!
I've always wondered what the process was for game programmers on the early PCs and consoles.
Are there any books or documentaries that go into depth about the development process of, for instance, Super Mario Bros? I've only seen stuff targeting "mainstream" audiences that glosses over anything technical.
I can't seem to find it right now but there is a development journal somewhere of the reverse-engineering and porting of Prince of Persia to the C64 that was done before the game was open-sourced.
NES development is alive and well in the Romhacking community, and although I don't know of any detailed commercial project documentation of the sort you asked about, there are tons of guides out there for NES development in general.
It's pretty intense. You don't even have proper sprites. they had to work with 8x8 pixel tiles and piece them together to create images. There were also pretty severe pallet limitations.
I have participated in Pyweek a few times and found the community to be a huge motivator. Just knowing that other people are doing the same thing as me increases my probability of finishing from something like 1% to 90%.
When a part of the community you can also look around at what other people are doing. I made my decision to use Pyglet after seeing it online and seeing someone mention it in the IRC channel. I may have dismissed it if not for knowing that someone else was using it.
So yeah, if making some games is something you want to do, definitely become involved in the community. It helps.
I've been making computer games, either as a hobby or for pay, for a span of about 30 years. There have been periods where I only made one new one every year or two, and periods where I made one or more small prototypes per month. It is a great technical and creative exercise, the more you try to take to a playable state in any span of time. It forces you to focus on what's most important, the key elements of the play experience. And make the core architecture simple, with a minimim of boilerplate and accidental complexity.
Maybe 25 in my case, I started when I was about 12 on a Mac Plus, I'm 37 now. Contributed to some small indie games and half-finished a few dozen, but decided to give it up because there is just no money in it (as a whole I mean, I realize a few rare winners make it above the fold though).
I would say it's at least 10 times harder to make games than normal applications, but, programming networked apps is at least 10 times harder than making games. This probably includes startup apps that that use the newest languages and databases.
I've generally found some of the "harder" concepts like 3D to actually be pretty easy, because so much effort has been thrown at them over years. It turns out to be a lot harder to interact with the OS since it's a moving target. For example, pretty much the entirety of what I wrote before about 2010 is unusable for Mac or iOS programming today.
To really make money, it’s critical to write as little code as possible (preferably no code at all), or be willing to let your games slip into obsolescence. Nobody ever talks about the amount of work it would take to bring a game from iOS 4 to iOS 8, or that most games make $1 a day or less. It’s pretty grim. So, best not to think about that stuff, and just concentrate on making something somebody might appreciate that has the potential to go viral. Or, do it as a hobby, don’t waste a decade or two trying to make it a career (unless you work for an established company, because sequels take the least amount of creativity and make the most amount of money - like Birdman for gaming).
Even when I had a clear vision of what I wanted to make, it was pretty hard to avoid feature creeping. When you hit the 90% completion mark, the TODO list starts to grow so scarily fast that the only way out is to develop/improve focus and the ability to ship things. That's when you level up as a developer :)
1GAM is a great opportunity to learn how to ship things, managing time and scope.