Tuesday 15th December, 2009
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.
Monday 14th December, 2009
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.
Sunday 13th December, 2009
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.
Saturday 12th December, 2009
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.
Friday 11th December, 2009
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.
Wednesday 9th December, 2009
Matthew made a good suggestion that I should pick a short contest to give me a deadline and just something done, no matter how crappy. There’s actually a Ludum Dare contest this weekend, and I’m debating with myself if it’s fortuitous or folly to dive into it right now. On one hand it’s great timing, on the other I don’t think I’m ready enough to build my game in the time I have free in that 48-hr period. Instead, I think I’ll give myself a week starting from now to get a game done. That gives me a bit less pressure to constantly develop-develop-develop so I don’t ignore important things such as sleep, but is still a fairly tight schedule. The downsides are there isn’t a community working at the same time on a contest, there’s a bit less pressure to actually commit to that week deadline, and I won’t get as much peer review. I can mitigate that somewhat by posting about development both here and at my GameDev.net account, where shame of failure will keep me honest.
So let’s say: Midnight UTC Thursday, 17 December (11 am, my own local time) – I post my game. Sounds good.
As for topic, I’ve got a inclination to focus on something with a strategic bent. Let’s say: I’ve got to include a card-based gameplay element. I’ve wanted to experiment with one of those.
I’d also like to go back and use SDL and C. This is definitely
the best choice for a quick game building prototype language. But there’s this coder part of me that likes dealing with low-level stuff, designing architectures and spending hours tracking down obscure pointer bugs. There’s another part of me that argues that this is really stupid and then my brain goes into civil war, but if I’ve got a week I can spend some time of that working on mucking about in code to make me happy, tech-wise. Since this exercise is about fully kicking me out a rut, it might be good to give the old coder synapses a run. The other options are to use Flash or Python, both of which should work fine for the sort of games I have in mind, but I think I’ll give these a go in later weekly challenges.
Right and good. Let’s get started then, and see what this game-in-a-week challenge will lead.
Tuesday 8th December, 2009
I generally try not to post any (non-game related) research stuff here, but this is too brilliant not to mention:
The Fundamental Matrix Song
May contain scenes of mathematics. Man, this stuff seems a lot easier to follow in song form.
Monday 7th December, 2009
Missing making a blog post is more trouble than it’s worth. I’ve got several unfinished drafts of posts I meant to post ages ago, but the longer I leave it the more information I feel I need to cram into them. This in turn causes me to delay to think more about what I want to say, which completes the terrible cycle of non-posting. The point of this post is to break that cycle. If I can’t fit everything nicely into one post, I can always post it later.
November game development in review: If I had to describe the state of November in a word, it would probably be “floundering”. I started the month at the initial crossroads of development looking to make the first few strides towards my destination, and at the end of the month I’m still standing there feeling bewildered. Having thought about why I’m still there, I think the problem is not so much choosing from the insanely large number of paths available for development, but that I’m uncertain about exactly where it is I want to go. Without a clear direction to head in, I’ve been evaluating my options with the vague metric of “Well, does this path look interesting to me?”. The answer is always: yes, it does look interesting, but so do all those other paths over there; maybe they would be better? I’ve stuck myself in limbo, exploring what options are available to me rather than making a hard decision and sticking with it. It feels nice and productive while I’m doing it, and above all it feels safe and comfortable. But I’m never going to get anywhere without making a choice.
Compounding on this, I’ve hit a creative dry patch right when I need game ideas. Deep down, I was sort of hoping that while I was working on exploring the tech and libraries I’d be hit by a few bolts from the blue with great, feasible ideas that would excite me into planning them up. But I’m getting nothing. It’s rather frustrating. Given the time that has passed, I’m going to have to force the issue by writing up treatments on whatever stale ideas fizzle into my mind, no matter how painful it feels, and keep doing so until I find something serviceable. I don’t have to keep digging through ideas until I strike gold, but it would be nice to at least strike zinc.
For this month, my aim is simply to have a sensible, workable game goal to develop that I will achieve. Sounds simple, but to properly find a goal with confidence I need to: make some fairly solid decisions about the direction I want to go in, platforms to develop for, genres etc.; come up with some workable ideas; choose my tech and art direction; have a workable prototype; and then have a development plan for how to get from prototype to release. Above all, I need to switch mentality from the “game development as a hobby” mode that I still think I’m stuck in. It’s more than a fair amount to do in three weeks, but it’s what is required for 2010.
Oh, and I need to figure out some better material to post in my blogs too. I envy those bloggers who can churn out interesting articles full of quality content at an alarming frequency. I have enough trouble just trying not to trip over my own grammar.
Wednesday 25th November, 2009
If you’re interested in vector graphics tools, the latest version of Inkscape (0.47) is now officially released. You can grab it from the Inkscape website.
New to 0.47 is the ability to edit SVG fonts. I’ll need to play around with this feature more to see how useful it is, but I suspect that Inkscape along with the free font editor FontForge will be a great free software combo for font creation.
Saturday 21st November, 2009
Hey, everyone! The blog’s not dead; I’ve just been really bad at deciding what is worth putting in it. This weekend I’m revising my plan for the whole Trazoi website-and-game-development thing, and I should be back to making semi-regular blog posts and site updates once that is sorted.