I always have a design, even if it’s just in my head, of how I want things to work. My design is usually coherent with itself and, when coded, should make a reasonably decent, clean, efficient application.

Libraries don’t always agree with my design.

This is why I usually end up reinventing the wheel and trying to write everything from scratch.

My current pet peeve is libraries for file loading, such as image and model loaders and in particular, currently, the FBX SDK. My resource management design is that I have a resource manager that loads the files and copies the data into file classes, created from factories, which then know what to do with the data. The reason behind this is that at a later date it will be easy enough to replace/extend the resource manager to load the files from an archive, decompressing the data into the buffer in the file classes. This means it’s only the resource manager that would need to change, nothing else cares where it comes from, and the resource manager only has to change one code path. I could even stream data over the internet or by sampling electromagnetic waves around the computer, it wouldn’t matter.

I’ve talked to other programmers, and they agree, this is a reasonable design. So I set up my file loading framework and made it load, and parse my config files. No problem. All my code. Nice and simple. Next, I wanted to load an image to display on screen. libjpeg is open source. So is libpng. I took a quick look at these and found there was no simple way to load from a data buffer, they just took filenames and FILE*. Sure I could hack this and either inject the data into a FILE struct, or use a temp file, or even fix the libjpeg source code myself if I so wanted… but this seems like far too much work for something which seems such an obvious thing. In the end I went for FreeImage which did allow for loading from a data buffer. My model loading so far is stuck with hacking in FBX.

Here’s the thing, FBX does animation, texturing, lighting, model loading, everything. It’s awesome and amazing in the amount it does. It’s free. It would be perfect for my engine to use. But it breaks my design. This has got me so worked up that on several occasions I’ve thought of just ditching FBX and writing my own model loader for something simple and starting from there but I’ve stuck with it.

Another thing that pains me about libraries which offer “solutions” such as FBX, or actually SDL for that matter, is that they can very often do a lot of different things. SDL is actually a better example here as it does window management, input, 2D graphics etc. However you have to use them in precisely in the way they expect, and if you use one component, you almost always have to use everything. What I’m referring to here is SDL, again breaking my design in a way I’ve ranted about before. I begun using SDL to create my windows, as it was nice and portable. However, since I wanted all of my modules to be as uncoupled as possible, I didn’t approve of SDL requiring me to use it for the input handling. Sure I could have written my input handler module to use SDL, but then I couldn’t replace it later on for something that had better support for joypads or something. I don’t know, it might seem pedantic, but I would really _really_ like it if you could just turn off features in some of these things. If I had the choice whether or not to use SDL for input, I’d probably be using it.

No matter how amazing your design, if you build your palace out of other people’s work, it will look patchy, uneven and will make you wonder why you made a nice design in the beginning.

On the other hand. If you designed a great pyramid and tried to build it single handedly, you’d drive yourself insane… so I guess when needs must… enlist slaves.

Has anyone else had any interesting arguments with libraries? Some design ideas that make you wonder what the original writer was thinking? I’d love to hear them, especially if they don’t affect me

What else? I still have my side project going which I hinted to so long ago. It’s been slow starting up properly, but I think it’s really getting somewhere, I am planning on having my “engine” to alpha stages by around September time. At which point I will probably be a bit more open about it. I have a team of people I know working with me on preproduction right now and hopefully it will be a fun project. Also, as a bit of a teaser, I have a little corner of some of the concept art I have commissioned from my good friend Rose Loughran of the amazing webcomic Red Moon Rising

I have one or two more things in the pipes, but they will be kept quiet for now until they are more definite. I intend to start writing a bit more about my experiences with engine development soon. Knowing me that will be in a few months though. We shall see.

Incase anyone comes across this blog and finds my writing in any way entertaining, do they think I should write about my experiences with indie engine development? Or maybe I can throw some random game design ideas out there and explain small concepts I have?

So, where’s the framework at? Well, I’ve added quite a few new things, and set up a few git repositories for it. All in all, it’s moving forward.

As this will be part of an upcoming game project, I won’t be releasing the source for it. Not initially anyway. I think I want to list the expected features of the framework/engine.

• Cross platform support. As a linux user, I’m constantly frustrated by the lack of native games. But obviously most gamers are still using Windows. If I’ve got one *nix system, I will also try and get MacOSX supported, if I can find a computer to do testing on.
• OpenGL and Direct3D support, where available. As the system’s modular, I’m going to be focussing on OpenGL, but I intend to add a Direct3D graphics module at a later date which should just be able to replace the previous.
• 2D UI layout system.
• UI creation tool. This will be a necessity as I hate manual UI layout.
• Possibility of encrypted, archived game data. Will explain this later.
• 3D audio. Well… hopefully.
• Studio Design tool. This is a long shot. But I really want it to come together. It should have the UI tool built in.
• Scripting. Not sure if it’s necessary yet for the current game, but it’s always useful, probably be Lua.
• Input. Can’t have a game without human interaction, can we? Might just be keyboard/mouse. Might include joypad.

Can’t think of much more at the moment. There’s a load more that I’d love to add in eventually. AI for example, also proper 3D collision, which I think we’re possibly going to avoid for this current game, we’ll see how things go.  Probably go with ODE for an initial implementation when I do, as it’s nice and cross platform.

With regards to the encrypted data, and the releasing source for the framework, I’m not intending anyone to work on my project for free, but I’d be happier to release the game for free. As such, I’ve suggested to the contributors that we do so, and stick a donation button on the site, when it’s up. Then we’ll set a milestone for donations which will cover everyone’s pay for the game. This total amount will be made public. I’m also going to set up one of those progress bars so people can see how close it is to the milestone. When the milestone has been reached, the game will have it’s source code released, and the data unlocked. Hopefully we’ll have something people want to play around with. Of course when the game becomes open source, the engine API will have to be released, along with documentation (currently busy doxygen-ifying what I’ve done so far). This will allow other developers to develop their own subsystems if they want, as well as, of course, other games. The engine source code itself will be released after a second public milestone is reached.

The timescale I’m currently looking at is that we have something vaguely playable by shortly after Christmas. This will be a rough UI setup, input, models with animations and at very least one location. Easter time I’m hoping to be able to release a demo which will be continually updated until release, however will only contain an hour or two of gameplay (plot limited) as we don’t want to spoil the story for anyone who’d actually be interested. I’m hoping to finish the game towards the end of 2011. Of course this depends on a lot of things, but that’s what I’d like to see happen.

Now, I’d best get back to coding. I have a lot to do

If anyone’s interested in helping with the project, give a shout please!

Edit: I’ve just re-read this post, now half way through 2011 and it seems like my prediction has moved almost a full year back! My current schedule is to have a prototype for demo purposes by December 2011. Wish me luck!

I have been doing work though. As well as my new job down at Ideaworks 3D I have been experimenting with my application framework a little.

I had a brief stint, trying to get it working on Android using NDK. This was unsuccessful for a number of reasons. The main being that, much as you can compile C++ with NDK, many many libraries aren’t supplied as standard. For example STL. The Standard Template Library. Standard. Yep. That’s missing. Before anyone thinks I’m stupid. I know you can get things like uSTL or other standin/replacements… but my struggle with various libraries that I expected to exist made me realise that, much as my code is quite neat, the structure of my classes and such leaves a lot to be desired.

With this in mind, I set off on an epic journey to rewrite my entire framework.

Well. Kind of.

The way Brassmoonlight was organised was that there was a “common” directory which had various modules, all of which got compiled down into a static library and then linked with a game library into one big happy executable. One of the main problems with this was that module A could quite happily see module B and I guess I cheated a bit by knowing the internal workings of the modules. So I could rely on a particular thing happening.

I started a new project. This one was named after my new bonsai… I named it “Bonsai” I know, I’m creative, right? I should point out now, much as I have huge plans for all my projects (this one I would like to be a 3D 3rd person semi-action game thing…) I have one specific goal at the beginning that I aim to complete. This is so that I can learn a new technique or something before the project inevitably falls on it’s face. I am still hoping for the day when my project will become something. It would be nice if this would be the one. We’ll see. The target for this project is then to make a totally dynamic and more flexible framework. This would mean totally restructuring how Brassmoonlight did it. I didn’t throw code away, however. I’m still busy grafting code from Brassmoonlight into Bonsai. The new system would be much cleaner though.

The plan is this. The application/game builds however it wants, parts can by dynamically loaded if the developer so chooses. The main executable must be built against libbonsai. This is tiny. It consists of one compiled source file. This constitutes the “bonsai system”. It took me a while to decide on this as I didn’t want it to become a “god class” but the design ended up being that the system was a singleton which had the sole responsibility of loading and dealing with libraries. These libraries would then be called from within the game where the system would decide which library to pull in to fulfil the job.

The way these were organised in directories was that each module (graphics, input, window management etc) would have a directory withing the bonsai system root. Inside this directory would be an interface for that particular module with no specific code. Then the implementatio would be within separate folders inside. In this way I can limit the knowledge any module has of any other module. I am not allowed to go more than one directory deep into the module, meaning any specific implementation should be hidden. If you look at the directory tree at the bottom representing a chunk of the framework, so for example, the graphics subsystem, in this case gfxGL, cannot see how the window is created. There are two possible methods, using SDL or using XLib. It can only see bonsai/window/window.h.

This also helps with the libraries that need to be linked in to compile the final executable. If there’s a chance of SDL being needed in any form (audio, video, input etc) then you need to link against the SDL libraries. In this method, however, only the subsystems are linked against the libraries, the executable doesn’t care in the slightest.

One problem that occured was that with these generic interfaces, some subsystems overlapped. Again, using the gfxGL and the windowXlib. In this case, the window subsystem has to prepare the surface for OpenGL to draw on, but Xlib shouldn’t know about OpenGL at all… so an extension system was implemented. What other uses this will have I don’t know. We shall see. Now gfxGL can request a new surface, windowXlib can then request the extension needed from the system.

The goal for all these subsystems and extensions is to make them self regulating. They are currently loaded on demand by the application explicitely and only cleared at the end of execution. Eventually this will not be necessary. For example, the graphics subsystem should only be loaded when the application calls a graphics subsystem method. Each subsystem must then be able to manage itself and be “aware” of when it is no longer needed so it can ask the system to close it. In practice this may be difficult for certain subsystems.

I have also started a small containers collection in the framework. Currently it just has an array which consists of a templated doubly linked list. As there are no algoriths it cannot currently be a replacement for any STL containers but I think I prefer having something which works the same wherever. Plus I can tinker with it and add more features when they’re necessary.

What else is there. Oh yes. SDL sucks. It doesn’t really, it’s an amazing library. There’s so much you can do with it. You can play audio, make a window, display 2D graphics, networking, even multithreading. And it works cross platform. It works on my GP2X. It’s awesome. However. For this setup. It sucks. With SDL you can choose not to use SDL_Thread, and use pthread or boost or whatever. You can use Winsock instead of SDL networking. This I believe is because SDL is little more than a wrapper for these things in general. I expected the same to be true of input. I haven’t tried this on Windows but on Linux, you can choose not to use SDL input, but you cannot register any other key listeners or mouse listeners as SDL is firmly holding on to it. I enquired on #sdl on irc.freenode.net and I got the response “That’s not how SDL works”. Well great. I didn’t want to rely on my window being created by SDL for an SDL based input system. That breaks the whole reason I spent ages reworking my framework. And the shared event queue makes sense, but again, breaks my encapsulation. Hence the entrance of Xlib. I did play with still using SDL for a while, and attempting to poll raw devices, but decided to give up on that notion. Instead I am using a less cross platform solution but one that won’t break my pretty system.

The next thing I am planning to do when I get time (I’m going to visit my girlfriend next week so who knows when) is to add a config file parser. This will put me a little further onto the invisibility of the subsystems as the game can request a graphics subsystem and config file can specify that the default graphics subsystem is GL for example… or specify alternatives. Initially I think I’m going to use an existing system for this, I’m not entirely sure what yet, I’m playing with the idea of googles protocol buffers as I like the sound of it automagically binarising, but I may stick with what I know for now and use tinyXML. Something I do want to do is write a parser and/or binary serialiser into my config system. This isn’t just me being obtuse and wanting to code everything from scratch, I really like the idea of writing parsers. It’s strange. I did one module at uni. It didn’t even go particularly well for me (although I got a B) but I’ve wanted to do more file based things. So yeah.

After that’s done I want to make the input system actually work. Technically all that needs is me ripping the command structure from Brassmoonlight. Bonsai currently has a keylistener and a partially implemented mouse listener in OIS, but no way of sending commands (just a hard coded exit) Once I have the command system in place, it should just work (ha!) Looking beyond that, I need to make the system actually render something. As of yet, I have a hard coded square in the gfx render code. I need to sort out how I’m going to sort rendering objects, both in 2D and in 3D. Then I need to rip my resource management system out of Brassmoonlight, along with my threading, as eventually, I want resource loading done on a separate thread. Then I need an internal event queue. Then a UI subsystem. Then. Then. Then.

We shall see how it goes.

It’s always a bit depressing when you spend hours and hours coding and the only thing you have to show for it is a black window that goes away when you press Esc. I could have written that in 10 minutes. I swear the code is REALLY COOL though.

.
├── bonsai
│   ├── bonsai.cpp
│   ├── bonsai.h
│   ├── containers
│   │   ├── array.h
│   │   └── containerBase.h
│   ├── extension.h
│   ├── gfx
│   │   ├── gfx.h
│   │   ├── gl
│   │   │   ├── gfxGL.cpp
│   │   │   ├── gfxGL.h
│   │   │   ├── Makefile
│   │   │   └── Makefile.in
│   │   ├── Makefile
│   │   └── Makefile.in
│   ├── input
│   │   ├── input.h
│   │   ├── Makefile
│   │   ├── Makefile.in
│   │   └── ois
│   │       ├── inputOIS.cpp
│   │       ├── inputOIS.h
│   │       ├── Libraries.in
│   │       ├── listener.cpp
│   │       ├── listener.h
│   │       ├── Makefile
│   │       └── Makefile.in
│   ├── lookup3.c
│   ├── Makefile
│   ├── subsystem.h
│   ├── types
│   │   ├── Makefile.in
│   │   ├── string.cpp
│   │   └── string.h
│   ├── types.h
│   ├── util.cpp
│   ├── util.h
│   └── window
│       ├── Makefile
│       ├── Makefile.in
│       ├── sdl
│       │   ├── Libraries.in
│       │   ├── Makefile
│       │   ├── Makefile.in
│       │   ├── windowSDL.cpp
│       │   └── windowSDL.h
│       ├── window.h
│       └── xlib
│           ├── displayExtension.h
│           ├── ExtXlibGL
│           │   ├── ExtXlibGl.cpp
│           │   ├── ExtXlibGl.h
│           │   ├── Libraries.in
│           │   ├── Makefile
│           │   └── Makefile.in
│           ├── Libraries.in
│           ├── Makefile
│           ├── Makefile.in
│           ├── windowXlib.cpp
│           └── windowXlib.h
├── cscope.files
├── cscope.out
├── extensions
├── main.cpp
├── Makefile
├── Makefile.base
└── Makefile.in

Ok, so, to be honest, with me trying to do my dissertation, and my AI coursework, and several other things got in the way of me continuing working specifically on the framework and my demo game. I also realised that, for a steampunk game, I would need far too much shiny art, and I know no artists with spare time unfortunately. I have opted to change the style to something simpler, and my girlfriend is currently happy doodling flowers for it. So I’ve changed the game to a 2D platformer in a kind of stylised, almost impressionist style (I tried to avoid using stylised and style in the same sentence, honest) My current plan is to add some post processing effects too which might make it shiny, a kind of bloom (for 2D?) or something.

Ok, so far all I have is a crappy coder-art stickman which slides left and right, and some paralax backgrounds. Technically I could have written the entire application in a few hours and got the same output. This annoys me slightly. However, the level data is stored in an xml file, the content for the application is stored in an xml file. The code itself is structured in a way which (hopefully) will allow me to do what I want for this game, and allows possibilities for things I only dare dream of (code can make me fly, honest!) so I guess I’m not too upset about the small amount of output for my work. I like my code.

I need to comment more.

A lot of my framework has comments, however, the game stuff itself, has virtually none. I will rectify this soon.

I also managed to get rid of the stupid memory leak that I had. I honestly can’t believe it took me that long to find. Anyway, my vector class should now work perfectly.

Ok, some downloads. These are currently only tested on Visual Studio 2005. I have Linux Makefiles for most of the stuff, however, I haven’t got X running on any machine, so graphics are kind of limited to an “ncurses” display (which, ok, isn’t fully implemented… but compiles) so yeah… basically, Linux support isn’t there yet. When I get time to reformat my PC, I’ll make sure I set up Linux properly again (i.e. with X) so I can fix that.

Download Source: Brassmoonlight-0.2

Download Binaries: Brassmoonlight-bin-02

There’s still a lot to do, obviously. The next thing I intend to do is get some basic physics working, make Mr Stickman slide around on the ground, and jump ideally. Then put some more objects in he needs to jump over… then try and get some animation done. After that, it’s time for more game-esque features, pickups, maybe enemies, then menu, that sort of stuff. I intend to do the physics and ideally get the animation working by the end of the weekend. We’ll see.

Not much of an update, but I just thought I’d share this one photo of the one side of the playstation in progress.

new side grill

Ok, it’s quite obvious it’s not very neat. I know this. The fibreglass is blocking up a lot of the holes. There are some reasons for the shoddyness so far:

1. I didn’t have something to cut curves neatly, I used a cutting disk on my Dremel and… well, disks don’t bend while spinning.

2. There was nothing underneath supporting the metal so I had to begin with the fibreglass from below, PS1 upside down so the metal lay flush.

3. There are gaps in the top where I haven’t yet filled in with fibreglass which I couldn’t do until it was supported from beneath.

What I plan to do tonight is to fill in the fibreglass from above, probably blocking up yet more holes (yay, more to re-drill through!). I will also purposefully block up the holes where the bubble will go. Then when it’s all hardened, sand the whole thing down so it’s all smooth and you can’t see the joins. Drill out the holes again, apart from around the bubble and paint. I have a small problem in that I don’t know where the reset button should be mounted, or even how I’m going to mount it, I’m thinking of trying to drill a hole in the correct place, then wrapping the original button holder thing in fibreglass, making a slight conic mount… but that would require almost exact positioning, which I’m not looking forward to. I might do this after it is sanded down, at least a little, so that I have a flat surface to measure and mark out on.

Anyone any comments?

Amplifier: I have all the amplifier modules built up. I next need to build the case (possibly counting as yet another project) and mount the components inside. I still need a power button, rear connectors (2x phono in, 6x speaker out (3x red, 3x black), 3pin kettle power)volume control + nice black dial, transformers and a crossover. Not entirely sure how I can merge a stereo signal into a single sub output. I’ll work something out.

Speakers: I have begun the finishing on one of the speakers. It’s been primed, and sanded down, now it needs to be filled some more, sanded, primed, sanded etc until it’s as smooth as I can get it, then it will get a couple of coats of black spray paint. I will begin with the other speaker soon too. I have also got some 3mm black acrylic which I will cut into circular covers for the back of the speakers to mount the connectors in. Once both speakers are done, and the amplifier is built, I will begin work on an 8″ sub unit.

Playstation: Now, a few things have changed with this one. For one thing I decided it’d be crazy to try and spray bubbles with a can. I ended up acquiring an airbrush which I have been harassing the cat with. The paint is yet to arrive. I’ve also decided that the vents on the side of the PS1 are hideous and won’t be neat sprayed anyway. So I’m cutting them off, I’m also going to cut an arc out of the top on both left and right sides (well, would be an arc if the disc cover and buttons weren’t in the way) and then I will fix some sheet metal there with 3mm holes as ventilation. The buttons will be mounted in their original places, and where the bubbles were planned to be on the case, the holes will be blocked up and sanded flush with fibreglass.

Sorry there are no photos at this point. I’ve been busy with other things, and also have been collecting the things I need. I’m currently waiting on some diamond encrusted cutting disks for my Dremel (only £4 for 5!)  and the fibreglass then I can get started on the PS1. The speakers I’m slowly slaving away at, but visually there’s no real change in them at the moment.

Anyone have any comments? Done anything similar?

I have given up with PC speakers. The last set I had was a 4.1 Logitech set that worked well for several years until the connections in the back of the sub got so loose that every step I took across my bedroom, one of the speakers would turn off, and another would turn on. I replaced them with a set of not-too-cheap ones from Argos. They worked for a while, then randomly changes volume, anywhere on the scale. Useless. Now I’ve given up with PC speakers. I know that I can probably get some nicer ones that will work, I just can’t be bothered any more. Plus this sounds like a great little project.

Ok, so, what’s the plan?

Right… so this is to be for my PC, it has to fit on my desk. This unfortunately means that a standard HiFi amp won’t fit. I have quite limited space with my two monitors. I’m wanting to build an amplifier that fits either above or under my PC case. Which means that the easiest thing to do would be buy the same PC case that I already have and take my Dremmel to it, cutting it down so it’s low, but still the same footprint. I’ve started looking into what amplifier components to fit in the amp and will be using 2x Velleman 7W amplifier kits from Maplins for the speakers, and a Velleman 200W amplifier kit to run the subwoofer. These are cheap, I know this, but I’m planning on getting something working, then replacing the guts when I have the money and time.

Now, what about the speakers themselves? Well, I found myself in Maplins on Friday afternoon looking at speaker units. I ended up buying 2x 4″ units and some little tweeters, then I went to my friend’s house and built some speaker boxes up. They’re not great, but they’re (more or less) level, they’re smooth and once I’ve sanded them a lot more, primed and painted them, they should be quite nice.

[Show as slideshow]

[View with PicLens]

Look, it's white

Albino controller

Unfortunately I had already realised I cannot replace the Analogue LEDs in the controllers as they are reverse surface mount ones and even if I trusted myself to solder that fine with the tip I’ve got on my cheap iron here, I have serious doubts I could find replacement LEDs anyway. Not much of a project report today, all I did was give almost all of the playstation a first coat of white gloss and replaced the power LED. I realise this is bad as the paint hadn’t fully dried (it had been more than an hour for most parts) but I assembled everything without screws so I could get a look at how things were turning out and I took some photos for a look-see.

Oooh, blue

As you can see, the paint job isn’t great yet. To be honest, I was never expecting it to be at this stage, cramped working conditions and, as you can see, the cat constantly interested, then not interested, then interested then… ooh a ball.

The next plan is to get some fine grade Wet+Dry paper and rub it down as smooth as possible then carefully give it another coat all over. Have been debating what to to with the analogue sticks but have decided to try and make the base of them look like a bubble and keep the tops white. The action buttons will get the symbols hand painted on, not entirely sure about Start and Select. I think I’m planning on hand painting a PS logo on both the case and the controllers but I’m still debating whether colourful is better, or just blue. Once I’ve got it all white and shiny I can start on the blue. Which will be fun. I will be away until Monday so it will probably be near the end of next week before I’m up to the blue stage. Hopefully by the end of the following week it will have lacquer on and polished up.

At the moment, it still looks quite boring, I mean, without changing the shape of a console, how exciting can it get? Especially painted in one flat colour. In my imagination though, I see where the bubbles are going to go, and what bits will be blue, and it already looks cool Hopefully it can become true. I still need to paint another controller and 2 memory cards when they arrive, I think I may need to buy more paint, I hugely underestimated I think.  Looking good though, right?