Long time no post – hopefully I can change that this month. For now though, here’s just an interesting deal I stumbled across on the internet. There’s an indie strategy games bundle out for the weekend, containing Gratuitous Space Battles, Solium Infernum and AI War. It’s US$49.95 and available only until March 9th. Windows only it seems, but worth looking into if you’re interested in indie strategy.
You can check out the details at www.indiestrategygames.com.
My immediate plans for January have been mildly derailed due to PhD issues. I’ve finally got my examiner reviews back and they request some additional material and another resubmission. It’s my own fault for leaving some serious holes in there and not submitting the strongest dissertation I could have mustered; the last year I was so sick of the whole thing I just wanted to get the whole thing behind me. The theories are sound, so hopefully if I put in some more results and a better eye to presentation it will be a lot stronger. Unfortunately that means requires a fair amount of time which will temporarily have to eat into game development. I’d wished to get the thing complete in 2009, but there was a six month delay in examination. This means the thesis will most likely be still hanging over my head in some form for most of 2010, with still the off-chance at the end of it I might fail the whole thing. Oh well, better make the most of it.
Because of this I won’t have a Python game ready at the end of the week; it might have to wait until next week. I’m planning on putting in a solid few days on correcting and planning that takes priority so I can gauge what needs to be done and make me feel a bit more in control. Once that’s over, while I’ll be spending a fair chunk of January working on this I should be able to slot it between game development tasks, so I’ll still have things to talk about here. I’m not that sure how long the whole process will take, but I suspect I’ll have the bulk of everything finished by March. I might not post more about the PhD corrections until it’s out of my hair, since I don’t want to derail the blog into writer’s rants. 
2010 – it’s not just a new year, it’s a brand new decade! Gee, this only makes the nineties feel that much further in the past. Hope everyone has had or is having a good holiday!
I had planned on starting the year with a review of last year, but I don’t think I will dwell on it. I can’t in all honesty say my performance in game development over 2009 was stellar; far from it. It’s pretty clear that my main issue has been a lack of focus, which has led me to be all over the shop. As a consequence, I’m roughly where I could have been at the end of last July. No point crying over spilt milk, but it does mean my top new year’s resolution is to develop a better awareness of how I spend my time.
More important is a plan for what to do this year. I’ll need some time this week to fully work a plan out, but again I won’t go overboard. At its heart, the languishing plan for 2009 was sound. The key to focus on is content creation. Last year I got bogged down with fear over whether what I was doing was good enough, sellable, or done in the right way, rather than focusing on just making stuff. Roughly, I think the plan should go something like: make stuff, make unique stuff, and then thinking about making a living off making unique stuff . It’s slightly generalised and I may need to accelerate things over a few months depending on how far I want to take the “making a living” part, but it rings true. That means I may have to spend a month (or two) to find my feet and a further month (or three) to find my groove before seriously thinking about something that leads to income, but instinct say it’s necessary. I’m a bit wary of my instinct though, as I also feel if I don’t dip my toe into the market in 2010 then I probably never will. It’s effectively a do or die year.
Top on the list of things to do is more of those week long projects. I was doing prep work for a Python & pygame one before the holiday period distracted me with mince pies. I’m kicking myself for not making good on my promise to fully explore Python last year, as my refresher reminded me why I chose it. Python appears to suit my style of quick development quite well, and if I put in the time to properly learn it it should be a good language for the majority of my in-house work. Python seems to be extremely well suited for small scripts, tools and probably prototypes. Even if I do have to rewrite everything in C or C++ for whatever reason, it’s probably faster to mock up the architecture in Python first. I’ll need to trial Python first with some of these small projects, but I’ve got a good feeling about it.
Following on a suggestion in the comments, I’ll start with a fairly unoriginal Asteroids-like game in Python using the pygame library. The point of the exercise isn’t to do anything particularly original, but to get a feel for the pros and cons of developing a game in Python.
I’ve noticed that Dragon Age: Origins is coming out for the Mac. I don’t have a very powerful Windows PC so I’d been considering getting this for the Xbox 360, but now I see I have another option.
Some thoughts on the port:
The week is over, and technically I failed. Bummer.
What I did get done was a tile-based prototype, shown above in the screen shot. It’s an experiment for what a tile based puzzle game would be like if the tiles consisted of two colours, split at the diagonals. In the version above, the coloured sections get highlighted if there’s a connection chain of four or more tiles long. Unfortunately, it’s currently just a toy. I didn’t think of a good way to make a game out of it. I was on my way to experimenting with a Tetris-like mechanic – matched tiles disappear, replaced with tiles above – but I ran out of time.
I might continue working on this at some stage, but I’m doubtful. Coloured tile games don’t excite me as a developer, mostly because I suspect every single gameplay combination has been done to death by now. I’m also not sure if it’s worth posting the prototype: it’s not fun, dead simple, Mac OS X only and spits log files into a subdirectory in your Library folder that you need to clean up after. Maybe next time. Part of the point of just having a week is that if I need to walk away, it doesn’t feel like much of a waste.
I’ll need some time to evaluate what went right and wrong from this exercise, but I’ve got some ideas of how things went off the top of my head.
First: I need to organise my time better. I just dove in, and while the time pressures helped me stay focused to begin with I went a bit all over the place with my focus. It would have helped to spend an hour or two at the beginning figuring out exactly what my objectives are, the best way to achieve them in the time available and pitfalls to avoid. With the haphazard approach I can get focused with deadlines, but I’m easily distracted by non-essential things. I also lost a lot of energy at the end which is part of the reason why I only got a prototype done.
Second: prototyping in C is a pain. Having a better set of in-built functionality at my fingertips would give me a lot more flexibility. I wouldn’t have to waste hours of work trying to think of a C friendly way to do the tile connection counting algorithm.
Third: prototyping puzzle game ideas in a short period of time is hard. I suspect if I just did a simple action game I’d have got something finished in the time. It’s easy to kludge together something amusing in the action game genre, but puzzle games live or die on their core mechanic. I don’t know if this is inherent to the genre or just my lack of practice with the area.
Fourth: if I’m not excited by the idea, then it’s really hard to crunch development. I didn’t exactly go “full out” in developing this one, a conscious decision to see whether it could be done with a sensible workload. But I confess it also meant I slacked off the pace in the last couple of days when minor issues reared their head and made completion all that more challenging. Maybe if I really loved the idea I might have sweated through the headaches (metaphorical and literal), the random Xcode crashes (grr) and the heat. But in the end, yesterday I effectively waved a white flag when it was clear I was out of time. I feel bad about that.
So… where to from here? I might have not completed an actual game, but it was a good exercise. My feeling is I should repeat the process until I get good at it. There’s one week between now and Christmas; that’s plenty of time for another small game attempt. This time, I’d like to give Python a whirl as a comparison. I need a theme though. I’m happy for any suggestions, otherwise I’ll take something at random in the next few hours.
I’ve got an idea for a tile-based gameplay mechanic I’d like to prototype, but I’m still working out the kinks. I’ll wait to post a screenshot once it’s a bit more fleshed out. I’m mostly posting this update just so I’ve got one for every day.
I’m working a bit too slowly for a grand finish, but at this rate I think I’ll have a workable prototype of something by the end of the week. The downside is this prototype might not be in a fit state to post to the general public, and if it is, it might run on just Mac OS X which is less than ideal for feedback. Depending on whether this tile game turns out to be any fun (still up in the air), I may grant myself a few extra days beyond day 7 to clean this thing up to a form I can post. At the very least I want to make sure I don’t post something that doesn’t spew log files all over someone else’s computer.
Not much to add here, as I’m still brainstorming ideas. I haven’t yet struck anything that screams out to me. If I don’t think of anything great soon I’ll just throw things together and see how they come out. At this stage I wager there’s a considerable chance I’m going to end up with something distinctly unfun, but them’s the breaks. At least I’ll have something to work from next week.
I feel like I’m assembling a Frankenstein’s monster, sifting through old discarded projects and assembling pieces that don’t fully understand into a crude, mockery of a game. Still, at least I’ve got the basic building blocks in place. All it needs now is a brain.
The sprite system is as simple as it can be, almost shamefully so. Every sprite as to be in a separate file and loaded to its own OpenGL texture. If this turns out to be too wasteful or painful to deal with I could hack together a basic sprite sheet functionality hardcoded to the situation, but it should work on the prototype level.
The audio system has a bit of black magic in it, as it has to use SDL’s RWops system to interface the PhysicsFS file system with SDL_mixer. It seems pretty straightforward in the code, but my tests show that as it stands it can only work with certain file types; for example it doesn’t like MP3 or Ogg Vorbis music files, but it can load MIDI music and tracker formats. Well, whatever. I suspect I’ve got do some uncompression in there somewhere, but I’m not going to spend half a day figuring it out at this stage. It plays music and sound effects, that’s all I need.
And the input/control system seems fine. It’s a paper thin interface between SDL and my message passing structure, which should be sufficient.
Now to the big issue: with nearly half my allocated time gone, I’m still rather lost on what this game should be. It’s now time to step away from the compiler and put some thought into what I can throw together in a day or two’s worth of work given the crude code base I’m working with.
This ugly screenshot is my code base at it stands. I might feel better about getting this far if this isn’t essentially where the code was four months ago. It’s a meshed together version of the C conversion of my generic 2D game code with some earlier C++ stuff, which I’ve converted to ugly C for the purposes of this experiment. Most of the work was figuring out my old code and trying to remember why I keep changing interfaces every rewrite. Probably because I like to make life difficult for myself.
There’s still some big, big gaps in the code base. For one thing, there’s no sprite or proper font code; that text in the screenshot is a hacked together debug font displayed with pure untextured OpenGL quads as the font’s “pixels”. The audio module appears completely empty. And while there seems to be the right hooks for cross-platform code, the only code currently in there is for MacOS X; probably not that useful for most people wanting to run the future demo. Since time is short, I’m going to try to silence the software engineering voices yammering in my head and write hacky code for now, and then maybe make my next project an attempt to up the architectural standards of my code base.
And I’m still completely up in the air about what this game is going to eventually be. That’s the other big thing I’m going to have to work on today. I’m concerned that I’m slightly behind where I need to be right now, so I’ll need to pick up the pace on the weekend so I can finish this thing off in time.
One day into development.
First, I’ve given the project a codename: Project Tarot. I always give each of my game ideas or projects a codename so I can mentally package it up concisely in a word rather than “that weird idea about the poachers and the dancing rabbits”. My codenames are always of the form “Project X” where X is one word, as I can then refer to it as X for short but the full title “Project X” means all my ideas are in the same drawer in my filing cabinet. The choice of codename usually is related to the idea but sometimes that relation is extremely vague. I tend to get held up thinking of good names for things, so I try not to worry too much about any meaning behind the codename; I just throw one down and run with it. In this case “Tarot” is simply because I’m planning for a card-game mechanic; the resulting game probably will have nothing to do with tarot at all.
Secondly, I’ve spent a bit too long thinking about code architecture. I’ve been meaning to move towards programming for multiple processors, as everyone seems to have at least a dual-core processor these days. I’ve never done any proper multithreaded or multicore oriented development before, so it feels like a rather large gap in my knowledge. I tend to favour software architectures where main tasks work very separate from each other, so my thinking is it shouldn’t be that big a stretch to getting these to run in separate threads. However after reading plenty of articles and doing some work on the whiteboard I’m now thinking this is a fair bit more involved that I have time allocated in this project, so I’ll postpone this until next time. For now, my concession towards multicore will be to try to keep all the video rendering parts of the program as separate as I can from the rest.
I’ve now got to work on the two big initial hurdles to getting the game done on time.
The first hurdle is, if I’m going to do this thing in SDL and C, I’ve got to get the basic framework in place and running ASAP as I need to get to the actual “game” part of the game. This is one reason why using an existing game engine or a higher-level language like Python or ActionScript/Flash would be more sensible if my only goal was to just get a game done. I’m stuck with a hankering to play around with C, so I’m budgeting a extra day or two towards the basics. It’s not that bad though, as I’ve got plenty of prior projects littering my hard drive I can cannibalise from.
The second rather serious hurdle is that I don’t really have any idea what this game is going to be yet. It’s going to involve cards or some card-like analogue, but that’s about all I’m certain of. I’ve got a few raw ideas, but they need developing to the point where I’m confident it’s not going to fall apart like a miscooked soufflé. Card based systems tend to have some finicky rulesets and I’m not sure it’s the sort of thing you can just wing in a system you’re throwing together on the fly. There’s a more-than-significant chance that the resulting game is going to be an incomprehensible mess to play, but as long as it can be played I’ll call the project a success. And hey, if everything goes to pieces I can just slap together a basic Memory Tile game and call it done.
RSS Feed