Post mortem of my one game a month
usebox.net
usebox.net
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.
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.
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 will not regret joining 1GAM.
:)
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!
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.
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!
Let me know if you're interested in the Oric scene .. I'd be happy to show you around!
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 :)
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.
It's pretty ancient, but here's Larry Ewing's notes on how he created the original Tux image in Gimp: http://isc.tamu.edu/~lewing/linux/notes.html
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.
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.
Post-mortem is widely used to refer to analysis of a completed project, failed or otherwise.
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.
Now that I think of it, I didn't try it with headphones.
I think I personally could do with doing something like this in my free time.
Again, well done!
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.
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.
All in all it's very interesting.
"The birth of a Paradroid" - Paradroid development journal for the C64 by Andrew Braybrook: http://www.zzap64.co.uk/zzap3/para_birth01.html
"Mental Procreation" - Morpheus development journal for the C64 by Andrew Braybrook: http://www.zzap64.co.uk/zzap23/mental1.html
"It's behind you" - R-Type Arcade conversion for the ZX Spectrum, free e-book by Bob Pape: http://bizzley.com/
Free sample pages of the development journals for Prince of Persia and Karateka by Jordan Mechner: http://www.jordanmechner.com/backstage/journals/
Prince of Persia code analysis after it got open-sourced in 2012; by Fabien Sanglard: http://fabiensanglard.net/prince_of_persia/
Analysis of Pacman; long after the fact: http://home.comcast.net/~jpittman2/pacman/pacmandossier.html
Any other? I'm sure there must be many nowadays...
Edit: Here it is (in 10 parts): http://popc64.blogspot.fr/2011/10/part-one-why-hell-would-an...
You would probably enjoy the book Racing the Beam http://mitpress.mit.edu/books/racing-beam
For a collection of (mostly consumer-oriented) behind-the-scenes material, check out http://www.reddit.com/r/TheMakingOfGames/
Or, if you want to get really technical http://handmadehero.org/
http://ludumdare.com/compo runs quarterly challenges as well as periodic mini-jams.
http://itch.io/jams Shows all currently running game jams in a nice UI.
I am impressed with the willingness to go back to one's roots.
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 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).
I've been working on just one game for four years.
If you're into Conway's Game of Life, Warp Life for iOS will have its second beta test soon: http://www.warplife.com/life/
I've got a very basic prototype for Android; I'll set into Android in earnest after Warp Life is in the App Store.
I'll be releasing the source code under the Affero GPLv3.