flixel great, pity about the game idea

David Shaw, 8:16 am 20th August 2009
Posted under: Blog Babble

flixel appears to be really neat for whipping up sprite based Flash games. I spent a while just getting to grips with the source code, but after a while things made sense. It’s pretty similar to the flow in the structure I use for 2D games in C++, so it makes sense. Even though I’ve got a copy of the Flash IDE, the free Flex SDK works better to compile; it feels just like other compiled languages. It was pretty quick to mock up a simple Flash demo.

The problem is I’m not sure where to take it. The original idea was for a sliding maze puzzle: you need to navigate to point A to point B in a maze made out of blocks, with the catch being that once you start moving in a direction you can’t stop moving until you hit a wall. It’s pretty trivial to make that from this point, but if I just do that it’s essentially a simpler version of Duck Tiles over at the Code Zone.

The original extension and “fun part” to develop was to think of a way to generate the levels. Brainstorming this on my board, it’s pretty easy to write a puzzle solver, but thinking of a way to generate puzzles that are both solvable and interesting is a bit trickier. I shelved that for a bit because I wanted to play aound more with flixel.

Instead I put in some sliding ice blocks which you can knock around with the player. I was hoping to spark off some interesting ideas for what you could do with them. Instead it now feels like I’m going back to the original Pengo video game that sparked off the whole “Penguins on ice” inspiration.

I’m just not sure there’s enough of a spark here to keep me interested in the game. Oh, there’s plenty of interesting stuff I could lose myself into: I’d love to play around with drawing ice effects, animating sliding characters, making ice themed music and so on. But a big truism I learnt from Freeplay is that all that sort of stuff should be spent on a good idea. If a game idea doesn’t grab you when it’s just blocks and shapes, then no amount of polish will save it.

I think it’s probably best if I shelve the Project Penguin idea for now, and go move on to prototyping something else. It’s already proved to me that flixel is a good prototyping platform for pixel or sprite based games in Flash, which was sort of the point of the exercise. If I hit upon a good idea that could work with sprites, I’ll definitely use it again.

While I liked flixel, the next idea I want to prototype would work better with geometric shapes and lines and involves a fair amount of algorithms which I think is best for me to prototype in C++. I’ll be sure to use it again though, especially because I’ve got a few retro platformers I’d like to make someday.

Crack Open the Idea Vault

David Shaw, 7:10 am 18th August 2009
Posted under: Blog Babble

I’ve set myself the task this week of prototyping a core gameplay idea in Flash. This serves as a dual test of both the idea as well as using Flash as a prototyping tool. I’ve only done some basic mini-games in Flash before so there’s a learning process involves, but I feel it should be doable if I don’t get bogged down on irrelevant fiddly implementation details. I’ll be blogging this as I go, typing up my thinking as I do it as a way of recording the process.

Since I’ve chosen Flash, I’d also like to use the opportunity to trial out flixel. It does seem geared specifically towards pixel games which suits some ideas more than others, but I haven’t had a close enough look at it to properly judge. And since some of my ideas are pretty retro, it should be a great help.

But before I dive into tinkering with that, I’ll need an idea. Time to crack open my idea vault:

Pretty collection of lines and boxes entitled 'Game Plan Chart'

“Crack open” might be a bit dramatic, considering this is a chart that is pinned to the corkboard by my desk. You can click the image for a larger version where you can read the boxes; it’s somewhat meaningless if you’re not me but all the pretty lines and boxes at least it helps give the illusion that I know what I’m doing.

This is a chart of all the game ideas I’ve had over the last few years that I felt were worthy enough to remember. I tend to make a lot of charts, mostly as a creative form of procrastination, but I like this one. It’s a good reminder that I need to get cracking if I want to see even a fraction of these ideas implemented.

I made the chart a while back to help organise my ideas into some kind of logical progression. Left to right is organised by theme. Top to bottom is organised by project length and separated into four tiers:

  • Tier I are very small demo projects, mainly for warm-ups or prototypes, duration one week or less.
  • Tier II are slightly more involved, duration one week to a couple of months. They could make good freeware, or with a bit more polish suitable for iPhones or small sellable games.
  • Tier III are full game projects, duration several months to a year or two. These have content level suitable for indie games.
  • Tier IV are advanced, involving a lot of content and/or experimental technology. These would take me several years to do, and are extremely ambitious..

Some explanation of my idea process: If I have an idea for a game that sticks in my mind as a good one, I give it a name. The name is just thought up quickly as a label for the project, not the final game, and is always one word “Whatever” with a full title of “Project Whatever” – the “Project” is because I only use the one filing system for everything and I like to find all my ideas under P (along with my PhD work, publications and papers. P takes up an entire drawer). I’ve got a couple of paragraphs explaining each idea, but I tend to prefer to have scribbled doodles as a reminder. Even those aren’t that necessary; most of these ideas are more about a raw concept or are based on emotion, so really I just need the name to remember them. It’s not as if the details are important at the idea stage.

The project I’d most like to make one day is the one at the bottom, Project Ivan, a highly involved interactive storytelling RPG system. One of the prime reasons I want to be a full-time indie developer is I think it’s the only way I can see a game like that made. I’d be totally mad to start with it, obviously. I’ll start near the top and work my way down the list. Let’s look at Tier I….

Project Zexus is a straight up clone for trial purposes; I’ve had a few botched trials at it and it’s fairly boring. Project Nova is a shmup that has some potential, but it has some AI quirks that make it challenging and might be hard to do in Flash. Project Penguin is a sliding puzzle game I never finished but could actually be a nice trial for flixel. Project Muzzy is standard casual fare and doesn’t interest me at this moment. And I’ve already completed Projects Poisson and Brixtar (that’s Pierre and the Fish and Brixtar, put on the list for completeness).

A strong alternative would be a prototype trial of Project Crystal, the first game in Tier II. It’s the most interesting of the early ideas, a sort of shmup/RTS hybrid, and it should work with wireframe graphics. I think it might even be easier to do than Project Nova listed above it – I probably put it below because it’s more interesting. If I don’t prototype this now, I’m certain to try it out eventually.

Hmm, I’m a bit torn between two options:

  • Project Penguin is tile based and fairly simple, and as such would make a good trial of flixel. The gameplay idea however is pretty simple and is unlikely to have legs – basically it’s a remake of a sliding puzzle idea better implemented in Duck Tiles and as mini-games in Zelda and RPGs like Tales of Symphonia. It’s point was more a test of graphical polish than game design. There’s a bit of interesting AI in the level generation, but otherwise it’s more down to style.
  • Project Crystal is a much stronger idea and one I’d like to try out. The game will work with just geometric shapes so it’s got low graphical requirements. It’s far more the classic sort of prototype I think I should be doing. But it’s not based around tiles and might not be a good first test of flixel – I could probably code this one up myself.

I’d really like to demo Crystal, and technically speaking it is exactly the sort of thing I should be prototyping. But my gut feeling is that spending a few days on a warm-up project like Penguin and trialling flixel may make my life easier in the long run. Given I’m going cold into Flash development I’d like to start looking at ActionScript 3 with existing source code to guide me, and Penguin is a better project to have in my mind for this task. I’ll set myself the task of working on Penguin this week (and only this week to give me a deadline), then I’d do a prototype for Crystal the week after so I can do the idea justice.

Prototype Plan for (remainder of) 2009

David Shaw, 8:27 am 17th August 2009
Posted under: Blog Babble

I’ve reviewed my current direction using my experiences at Freeplay 2009 to guide and inspire me. I’ve got a bit off-track in the last month or two and I needed some realignment.

If I were to be brutally honest and go all psycho-analytical on myself, my guess is that my stalling comes from a subconscious insecurity about my abilities as a game developer; a classic fear of failure. My programming skill isn’t nearly as good as it could be, and that’s miles better than my skills in art, design, business, marketing and so on. I think that’s why I felt the need to “revise” my skills, trying to get to an “appropriate” level. That’s a trap. I’m not going to know what level I truly need until I actually try to make something that needs those skills. I’d be better off making prototypes of the ideas in my scrapbook, sticking them up on the web for comment, and learn through doing. I’ll probably end up trying to push myself anyway, so if I rely a bit more on my instincts I’m sure I’ll naturally gravitate towards improvement regardless. And it’s not as if I’m hopeless; I know I’ve got enough skill to make something worthwhile – I’ve done it before.

In short, it’s time to get started.

For the next couple of months, maybe to the end of the year, I’ll aim on completing a bunch of small prototype projects, slowing testing ideas (and naturally working on my skills in the process). At the end of this, I should be in a much better position to gauge where I stand, which idea is worth developing, and in choosing a decent approach to doing so.

Some areas I think I should look at:

Ideas and Prototypes

The importance of prototyping was stressed at Freeplay 2009. The standard yardstick used by a few there was to give yourself a week or less to complete an objective, then to “just do it” using whatever method is easiest. That’s actually something I had planned to do earlier in the year based on the success of The Experimental Game Project, but I got a little side-tracked. I’ll take a few of the ideas I’ve got written down and trial them with some quick and dirty mock-ups. I won’t bother fully polishing them up into little games (unless that’s the point of the exercise I set myself); I’ll treat them as proper prototypes, testing one specific property at a time.

For the technology to use, there’s four choices that make sense for me, personally:

  1. C, C++, or (more likely) C++ that’s more like C (i.e. C with STL and namespaces)
  2. Flash (Flex, Adobe AIR, ActionScript 3)
  3. An engine like Unity 3D, Torque or Game Maker
  4. Some other language like Python or C# that I’m not fully comfortable with

I might end up cycling between all of them to try different things out. Some reasoning for each choice:

  1. I’m definitely most comfortable with C or C++, and I know if I scrap being all “software engineer” I can churn out a 2D demo in a few days.
  2. Flash makes a lot of sense as a prototyping platform; it’s got a graphical IDE, it’s got vector support (I love vector graphics), and the ability to make the prototype playable on the web is really useful. I already have Flash CS3, so the price is moot.
  3. Freeplay had a lot of champions of using the engines out there; the indie licenses are pretty cheap given what they can do. If I were into 3D I’d be mad not to use something like Unity or Torque, but for 2D I’m not sure if it’s as critical.
  4. I’d probably only choose another language if I feel a really pressing need to learn one, or if I really want to learn C# to develop for the Xbox. Or maybe I might just like the change of pace.

This week, I’ll start by picking one of the core ingredients in a game idea and mock it up in Flash to see if it’s any fun; no polish needed, just a test of gameplay. I’ll see where that goes.

Code Library

I still think it’s a good idea to build a code library, except mine will be much more like a scrapbook of useful code snippets than the traditional sense. I’ll just make a repository for old code so I can reuse the bits that are useful. Maybe in a while I’ll separate bits out into something slightly more formal, but nothing that would take more than a day’s work. I won’t know what I need until I need it again.

Marketing Plan

I really need to start work on implementing my marketing plan. “Plan” might be a bit grandiose for what it actually is: technically I’ve got a plan in the sense of several pages of rambling documents in a wiki, but it basically boils down to “make lots of content and stick it on a webpage”. I need to put up a few good tutorials, articles, comics, freebie games and the like; really flesh out the website. I’m hoping the prototyping will help spark this.

iPhone development?

I have to admit: I was pretty smitten by the cool iPhone apps I was seeing at Freeplay. I’m now thinking it might be cool to work on iPhone games too. It doesn’t seem that hard to get started, especially given I already develop on a Mac with Xcode. The biggest expense is getting an iPhone to test with; I don’t really need or want one to use as a phone, just as a software platform. But it might be worth considering getting an iPod touch and a dev membership and see how easy it is to get started. I don’t think I’d like to go completely to iPhone development, but it could make a nice complement to desktop games.

Lessons from Freeplay 2009

David Shaw, 11:03 am 16th August 2009
Posted under: Blog Babble

I’ve put together a summary of some of the main points I learned at Freeplay 2009. Most of these aren’t lessons from any one person, but are a collection of the impressions I got from the panels and workshops I heard, the discussions I had with attendees, with possibly a fair chunk of my own opinions subconsciously working their way in (so if any of this turns out to be a faulty recollection of Freeplay 2009, blame my brain).

Prototype, prototype, prototype!

By far, the most common thread in talks was the need to build prototypes. Half of Petri Purho’s keynote was on how moving to the game-in-a-week model best shown by The Experimental Gameplay project. Conor O’Kane’s How to make games on your own, for free talk included the importance of making prototypes and how this can easily be done (incidentally, you can grab his slides from his website). And throughout the other presentations there were themes of how prototypes are important for both fostering creativity and as a way to see if your ideas have legs before you invest too much time in them. The common wisdom is pretty much unanimous that if you don’t first start investigating your idea with a prototype (or two or three), you’re doing it wrong.

Can’t code? Can’t draw? You can still make a game.

Another common theme I got from the talk is that there’s loads of material out there to help making your game very easy. If you really are passionate about making games there isn’t really any excuse for you not to. For only a couple of hundred dollars a developer can get an indie license for Unity or Torque. You can get XNA for free. Flash is a bit more expensive, but you can get the Flex SDK command-line compiler for free if you’re prepared to work in ActionScript with an engine like Flixel. With just a bit of scripting and some simple graphics, you can easily built a prototype with these tools all by yourself regardless of your skill level. If you’re savvy about your graphics style, you can make a full game that still has a quality feel. And with the not-really-that-expensive outlay of a Mac Mini, an iPod Touch and an iPhone Developer License, you could sell a game for the iPhone.

With access to the internet, you’ve got access to a top training resources. If you get stuck, there’s heaps of forums out there to help you. There’s tutorials up on the web, and entire university lectures available onlines (MIT apparently has every one of their classes up on YouTube; that’s pretty amazing). In short, if you can read this, then you’ve got access to all the material you need to gain the skills you require for game development.

So if you think you have the next great game idea, there isn’t anything stopping you from building that prototype. If you can’t, well maybe that game idea isn’t so great after all. Try another.

iPhone is really popular with indies…

Out of the available indie game platforms I felt the biggest buzz was for the iPhone. About half the people I spoke seemed to be either working on the platform or were planning to. I can see why. It’s pretty cheap to launch a title on the iPhone, there’s only one main sales channel that everyone can access, and the platform is very well suited to small games that can be made in a couple of months. It’s perfect indie fodder. Of course, that also means the platform is now flooded with developers and is now garnering attention from mainstream publishers, but I don’t think that’s necessarily a bad thing. You can’t make a mint with a novelty flatulence app these days, and with the big developers now muscling into the space it’s becoming a lot tougher to crack the top of sales lists. But that’s true of all the other platforms. I think it’s still viable a platform as any other with the right sort of innovative game. And let’s face it; being able to play your game on a sleek handheld device is just cool.

…desktop games, not so popular.

There were still a fair number of developers aiming for desktops (Windows, Mac and Linux), but the vibe was a lot cooler on this. Most of the panelists thought that the traditional pay-for-copy-of-game market for the desktop was too tough these days due to over saturation. Most of those still developing for it were into making free games, either just for fun or for other purposes (self marketing, running paid servers, etc). It seems there’s more excitement about getting your game on the iPhone or Xbox Live than the PC.

I’m not sure how valid the strength of that opinion was. Most of the attention for paid portals seemed to be focused on Steam, which is from what I’ve heard quite difficut to get your game onto. There’s also the casual portals, although my feeling is they’re starting to become less attractive as they play cut-throat price wars. And there’s always the option to sell it through store fronts like BMT Micro; the big downside being you need to market yourself, but the way I see it there’s no avoiding that.

Other, miscellaneous stuff

A few more thoughts from the festival talks that I’ll summarise. Some of these had some expressing the counter argument, but the notes here was the general feel I got from the indie developers in the panels:

  • Ideas are cheap. While people will politely listen to ideas expressed in words, you really need a prototype for them to “get” it. As mentioned above, prototypes are easy to make, so make them.

  • Share your ideas. While the lawyer presentation stressed the importance of using NDAs in formal discussions (say with a game producer), with other indie developers you’ll just be wasting their time. Sharing your ideas, even in prototype form, can get vital feedback as to what works and what doesn’t.
  • Don’t be afraid to abandon an idea if it isn’t working. That’s what the prototypes are for.
  • Move fast. This seemed most important for the iPhone developers, where a few made it big just by being the first mover. A small developer can sense changing industry directions and put out a game before the larger publishers take notice.
  • Don’t skimp time on the polishing and testing. This is counter to “move fast”, but you need to make sure your game doesn’t have any obviously detracting rough edges. The rule-of-thumb I heard was to spend a third of your dev time on this.
  • If you’re aiming to be a full-time indie, be prepared for a hard slog to gain sustainability. You generally need multiple games before you break even. The sensible indies seem to have either an alternative source of income while setting up (another job or someone to mooch off ;) ) or a big wad of cash saved up, and a timeline where you can call it quits without facing complete ruin. Note though that even in this worst case scenario, if you really put your heart and mind into it you still won’t be a failure, as you’ll have developed some important skills that other employers should appreciate.

I’m expecting videos of the talks to be up at tsumea sometime in the next week or two; when I find out they’re up I’ll post a link.

Freeplay 2009 – Saturday

David Shaw, 11:43 am 15th August 2009
Posted under: Blog Babble

I’m pretty exhausted after today’s session of Freeplay, but I’ll try to sum up my thoughts about the sessions I saw today. Again, I’m pretty sure vids will be up on tsumea sometime in the next week or so, so I recommend getting detailed summaries from there when they’re out..

Making the Leap: A session about making the jump to making a living out of indie game development. Out of the panel, Jarrad Woods has just made the leap to full-time, so he’s not fully sure his plan will work out. And Damian Scott has a day job, albeit as a games lecturer (in business-speak he’s diversified his game activity portfolio). Michael Shamgar has made it to self-sufficiency with his company’s games, though. Interesting discussion. Pretty much the entire panel were agreed that it was extremely hard to make a living as an indie just via desktop games, at least throught the traditional path of just releasing games.

Education and Development: I’ve probably outdone the education thing, but I attended this talk to get a feel for the state of game education and academics, plus I wanted to talk to the panel afterwards for how I can keep tabs with the latest on academic thought (hey, I’ve been in the uni scene for a while now, that’s what we do). Also interesting to see how far education has gone back from my day as an undergradaute.

Intellectual Property Issues for Game Developers: This workshop was run at the same time as the Education panel, but it ran substantually longer so I caught the tail end. I already knew the basics of IP issues, but there were some interesting points here, such as the secondary protection that DRM provides which might explain why it’s popular to large companies (copyright infingement is a civil case, but breaking DRM is now criminal; I’m still undecided of it’s worth to indies). There was some good tips at the end on some good yet cheap contract lawyers to help do all the legal paperwork, although that might be Melbourne specific.

How to Make Your Own Games for Free?: I was undecided between this and the “Where to From Here?” panel, but the “Free” bit drew me in – as with a whole bunch of other people; this was one of the better attended workshops. Really useful advice on how to make games cheaply. The main tip was prototyping with some of the cheaper game making tools out there, like Game Maker, Torque Builder, XNA or Flash. While most of those aren’t free, they’re cheap enough to be just as good, and you can often end up making the whole game out of them

Making a Lot of Noise Out of Nothing: This was an audio workshop; the presenter Stephan Schutze was the sound & music guy when I was working at Blue Tongue in 2000 but unfortunately I didn’t get to say hi after the talk. Pretty good all round talk on making and editing audio. Important info to note: Stephan is planning to release his collection of audio files as a free archive sometime later this year. This will be an tremendous resource for any indie, so keep tabs on it.

Freeplay Greatest Hits: This was basically a general panel with presenters selected from earlier sessions, including Petri Purho. The highlight was the end where Petri tried to build a game in five minutes (in training for a European conference). Hopefully the video of this out will come out, because it was awesome.

Overall I really enjoyed the two days, and it’s given me a lot to think about. I’ll try to make a post tomorrow about some of the general things I picked up from the sessions and some possible tweaking to my own game development game plan because of it.

Freeplay 2009 – Friday

David Shaw, 10:17 am 14th August 2009
Posted under: Blog Babble

Today was the first day of tsumea in a week or two if you’re interested in the content. I’ll mainly be posting my reactions, given the notes I took are barely indecipherable.

Overall I enjoyed the day. I probably didn’t speak to as many people as I should have; my shy nature means I’m not a natural networker, doubly so when I haven’t had much coffee and it’s been a long day. And I probably didn’t learn anything groundbreakingly new. But for methe day did help do what I hope it would, which is to fire my brain up again about game development and remind me what I should be doing. It’s given me a few pointers on how to tweak my work approach that I suspect will be more likely to result in good games.

The sessions I saw:

The New iKid on the Block: A discussion panel on the practicality of developing on the iPhone. I’m starting to lean more towards the iPhone, although alongside other desktop games. Basically, the advice was to develop to the specific iPhone strengths (touch screen, accelerometers, connectivity, camera, maybe the compass?) and try not to directly compete with the big boys now coming into the market.

Agile Development: I think the speaker was a late fill-in, so this workshop was a bit freeform. I’m most likely not going to be working on a large team in my projects (and if so, probably not in the same building), so I’m not sure if any formal processes, even ones as freeform as agile development, are strictly needed. But still, I liked hearing a wave of software engineering speak. It helped reawaken some long dormant neurons.

Case Study – Imperial League: This wasn’t so much a case study of Imperial League as the whole of Primal Clarity, a group that focuses on the business of Unreal mods. They can win contracts for prototyping ideas in Unreal engine, send in game submissions to government initatives and other interesting ideas.

Weapons of Mass Cosntruction: A talk on procedural generation to make artists lives easier, mostly consisting of videos showing what they can do. Pretty interesting. I’m not sure how useful they’ll be to me if I work in 2D, but it’s nice to know they’re there. It’s an area I’d like to play around with myself.

The art of getting things done: A good pep talk on how to, well, get things done. It did tend to veer more towards team management than solo, but it had useful tidbits like The Cult of Done Manifesto. I’ll read through this in more depth on the weekend, as I need to, bluntly, get more stuff done.

International Keynote: Petri Purho (Crayon Physics Deluxe): A really good keynote. If the video goes up at tsumea, I highly recommend watching it, despite how Petri says he’ll play Spelunky throughout the whole talk. Petri explains creativity in games, and how to brainstorm creativty via prototypes (or as he calls it: “making shit in games, and making shit games”).

Accursed OS specific errors

David Shaw, 10:37 am 11th August 2009
Posted under: Blog Babble

I spent most of today’s programming inadvertently proving Andrew Russell’s points against C/C++ (see the comments to Don’t bring C to a string fight).

I’m up to porting across the wrapper code I’ve written for SDL and OpenGLs graphics. The code base consists about half-and-half of initialisation/deinitialisation code and a sprite management system. The sprite management system is possibly over-engineered and so I might leave it for now, but the base wrapper code for all that initialisation stuff should in theory be reusable for any app. It’s just the basics for setting up windows, swapping buffers and telling code when it needs to hurry up and render something if it wants it be up on the screen this frame. It’s mostly a mess of cryptic library calls to SDL and OpenGL, but if it works it works.

At least that what I thought so. However the call to the SDL function that sets the video mode just refused to run on my Mac system. It would just crash – not even returning a null value for my error checking to deal with. My gut instinct was that I had to be doing something boneheaded, like forgetting to initialise something obvious, but it seems like I was doing everything I should be doing. I spent hours tracing it through, running it in different release builds (which caught an unrelated but also nasty string bug in the file initialisation code, C really is evil in that regard). It turns out SDL was also throwing a whole bunch of memory leak errors in the console that were either new or I’d missed, as my own output is to an HTML log file. This was weird, because I’d never noticed errors like this before in previous SDL apps.

It turns out my instinct was right, and I had done something stupid. On the Mac, SDL needs to run under an Objective-C wrapper. They helpfully provide you with a sample one, but I’d somehow removed it from the build path. Consequently SDL’s threads were disintegrating spectacularly into a whole raft of error messages. I’d probably missed this kind of problem in my previous little games because I’ve never developed a C based game on one before; I’d written them in Windows first then ported it across.

It’s not a good start to the trial of a C with scripting language game base. Admittedly it’s a very OS specific error. Once I get all the wrapper functions working and tested then I should be dealing mainly with my own code, and at least then I should have a fair idea where the trouble spots may lie. But the thing about unexpected difficulties is they act in unexpected ways. I’m fairly sure there’ll be similar challenges when I’m working in a language like C, and whether the time I lose to solving these problems is worth the fact that I like working and thinking in the language. I’m a bit behind schedule as it is, despite C being my strongest language. My feeling is that I should still slog on with my plan for now, but if I hit an alarming frequency of this kinds of bug stoppers I should start strongly considering a different course involving a higher level language.

Freeplay 2009 next week

David Shaw, 12:42 am 8th August 2009
Posted under: Blog Babble

Just a heads-up: Freeplay 2009 is on next week in Melbourne, on Friday and Saturday (Aug. 14 – 15). I should be there for both days. Tickets still seem to be available until Thursday, so there’s still time to attend.

I’ve never been to Freeplay before, so I’m not sure what to expect. At a bare minimum I’ll just drift around the panels, soaking in game related thoughts to both learn from and be inspired. But if anyone has any recommendations about what to see, please tell me.

Don’t bring C to a string fight

David Shaw, 1:12 am 5th August 2009
Posted under: Blog Babble

A programmer oriented blog post today:

I’m still tinkering around with the guts of my old system, remembering how it all works. Rewriting the code concerns me a bit that I am technically reinventing the wheel, possibly wasting time. But it’s being invaluable in revising my old coding habits and getting back up to speed. I am worried that I am running a few days over where I’d like to be; I was hoping to have a bare bones functional wrapper for the basics done by the start of August.

The biggest change is I’m moving my code from C++ back to C, partly because I want to move to a scripting language for the bulk of the work, partly because I want to see how it looks. Mostly this isn’t much of a change. There used to be a delegate based signal system for passing events through the system that formed the core of the message loop. The code was elegant on the outside but a nightmare on the inside; it heavily used templates and the types the debugger would throw up were horrendous. For now I’ve replaced it with a simpler message passing system somewhat modelled off the interfaces to SDL (which incidentally I’m still using for cross-platform functionality). My simple unit tests seem to suggest it’s working nicely.

But man, does C suck for anything involving strings. I spent all of yesterday just writing the code for reading in a config file (the original used TinyXML, a C++ library). True, that’s partly because I’m a bit rusty and was making boneheaded design errors. But it’s somewhat understandable when you don’t have the usual C++ string library to work with, or a higher language like Python to handle all the ugliness. The stupid thing is I only wanted a fill-in module to handle the early prototypes, as I want to explore using Lua as scripting language; reading config files is (almost literally) what Lua was made to do.

Still, I did get some really good C practice out of it. And it was good practice with Xcode’s debugger, hunting for pointer errors.

It does make me question a bit whether the decision to roll back to C was wise. It does mean I lose a lot of C++ only libraries – admittedly the ones that come precompiled tend to be a pain to use, as you have to have the right compiler, but the ones you can compile yourself are useful. And I lose out on the standard library – which may or may not be an issue, depending on how much I can farm off to Lua. But on the plus side I find C easier to debug, and there’s less of a push to use clever C++ features just because they’re there. I’m also getting a feel it works better for the message passing design paradigm I’m going for; C++ tends to lean towards using objects for everything, even when they’re not really needed. I do miss namespaces; really useful things, namespaces.