Of ripped assets and other painful metaphors

Posted by | Posted in Game Development | Posted on 07-08-2012

Time to speak of work and I haven’t been slacking off or wasting my time!

Last night I finally integrated the Gwen UI system with “the project” so it’s now even getting a bit of polish and usable UI rather than bizarrely assigned keypresses. There are some notes that I’d make about Gwen before you pick it as your UI of choice.

  1. Firstly I’m using it with SFML 2.0 pulled direct from the SFML git repository. That means I’ve had to make some changes just to get it to compile with it. These are documented on a number of different sites so I’ll probably upload a patch somewhere and try to document them on here in a separate post later.
  2. The Gwen solution for VS2010 is a classic example of an uber-solution. All of the projects are inside it for all possible libraries that it can build so if you don’t have Allegro or DirectX 2D available or in your global paths then you’re going to get lots of compile errors. A better approach might have been to have a number of different projects for each implementation but nevermind.
  3. This is very much an ingame psuedo-serious UI. It’s not for a HUD – though I’m sure I could twist it to do so, it’s providing MFC alike buttons, text windows, scroll bars and things like that. In this regard it’s exactly what I’m looking for and my impression of it’s abilities will probably change as I learn to use it.

So far it all looks very simple but powerful and I wish I’d actually gone through those minor hassles before now. I can think of a few older projects I’ll be integrating it with post-haste because they’ll look a lot more professional once I have!

Speaking of “the project” this is the one I’ve been reluctant to show screenshots of because I’m currently using ripped isometric graphics from a rather popular isometric Bullfrog game. It’s silly of me because eventually I think only the presentation will be isometric the graphics themselves will be 3D assets but I’m having to learn a lot of things that people back in the Amiga days just seemed to be aware of. I may be trivialising the work of those pioneers with that sentence but I don’t half feel stupid trying to work some of it out.

Ideally there’d be some set of these 3D assets lying around, I could integrate them now and modify the renderer to get everything displaying again. It’s a lot of work to look like you’re standing still but it’s a necessary part of the handover process from pseudo 2.5D to true 3D assets. Nothing is ideal though and my art skills have never been anything more than complete cack therefore I’m stuck with 2.5D and ripped assets for the time being. I can still get on with the system, audio and gameplay though oh and the ingame editor UI which is what the Gwen integration is for.

Broomy was talking seriously about quitting and going indie but needing a year long plan, so we spent most of an evening working out whether we can take “the project” further than my whimsical hacking. He’s actually more clued up about the whole thing than I am and would prefer to start smaller or use middleware like Unity or UDK which is very sensible but does have a learning curve we’d both have to get over. There’s also the issue of what else to make, we’re both talented enough to make some pretty cool little games, it’s more a question of: “What cool little game can two guys make in less than 3 months to start earning a tiny bit of money?” – this is actually quite trivial to answer if you consider the available markets, i.e: PC, Android or iOS. That answer is, none. Or less pessimistically: If 10,000 two man teams made a game in less than 3 months only one of those teams would break even or better.

Currently I find myself in the position of trying this by default since I don’t have a job, go me.

I’ve worked on and off on “the project” since January so it’s not exactly new but finding time and sustaining motivation is really tricky. it began as nothing more than a Syndicate level viewer. I just wanted to scroll around the maps a bit for nostalgia. Then I started exporting them in a more flexible and editable format, then came the different palettes, then dissecting the level construction, then the level collision etc. Now it’s becoming… well “the project”. The Syndicate-level-viewer origins became a bit of a hindrance a little while ago but only in a few minor ways, that’ll all fade away soon. Mostly though what I’m doing is just fun now, something I enjoy going back to work on each day.

Working on this has another benefit, it’s reminded me that I need to focus more, to work on just one thing at a time: Do one thing at a time and do it well.

Comments posted (1))

  1. Hmmmmm… well, I would like to offer some advice on the indie project but it’s tough. For pretty much any team these days, making almost any kind of game, I would probably just tell them to use Unity. You get Windows and MacOS platform independence for free (although iOS and Android require a non-trivial payment), and you can deploy to the web plugin. (There is probably more money in web games and OSX games than on Android…) The art pipeline is virtually eliminated – export from Max, put it in the Unity project directory, done. You have a scene editor that would take a lot of time to replicate with a custom tool. You can script the editing environment. You can easily enable designers to tweak values directly in the engine C# is quick to compile and a pleasant language to use – no more linker errors! To be honest I find it baffling when people struggle on with C++ to make games these days when they don’t have to, because the return on investment there is so much lower.

    But, I think of you as a tech guy and a tinkerer, who likes to solve problems and make interesting bits and pieces. You can see this from how you started with a map viewer. The problem you have is that Unity pretty much is the antithesis of that; it’s a collection of other people’s interesting bits and pieces, where almost all you write in the end is the gameplay code. Sure, there is scope for interesting stuff – eg. procedural generation – but I can see you getting frustrated at not being able to tweak all the details as much as you would like.

    If you had time to spare I’d suggest making a game in C++ and a game in Unity, setting aside 3 months for each, and seeing which was more productive for you. But obviously that’s unlikely to be an option unless you meet a mysterious benefactor!