New games every week!
Framework Explanation Blog
10th February 2010
Late last night, as I was half-asleep and reading through Twitter, @Komiga asked me if I was going to be using any version tracking software for my lovely framework.
My twittered response was limited (by lack of sleep, and also 140 chrs!!), so I figured I should explain it a little better.

Last year, around about Alien Deathmatch/Centipong time, I built up my 2D-in-3D framework to work in Blitz3D.
It worked wonders, and let me achieve a whole new ability. I could finally rotate sprites! Yeay!

I kept the 2d-in-3d framework as a seperate include, as well as a "defs.bb" which did all the default stuff, like the fps keeper, the loading and saving and all the rest of the framework type things.

After a while though, since I'm making so many games, a huge number of issues started to crop up.
One game needed to be in pure 2D, so I had to create a second defs2D.bb, which wouldn't start doing any 3D commands. Another game needed sprites to be layed out in a different order, meaning I had to reconstruct the 3D stuff. Another game wanted some tiles infront of the player, so that needed extra tweaking, and then Blockman Gets More.. Good lord, that was some crazy stuff to get that all working!!

The main issue wasn't getting the things done, it was instead trying to achieve them without breaking anything that could affect every other game I'd already done.

And it even affected pre-compiled games, too. The whole Badges/Scoring system could easily be broken in one game, and make other games unplayable. Things like that.
Chaos.

Every game relied on each other, and it became overly complex.


This time around, I've chosen not to even bother with all that crap.
I'm keeping things simpler.
I've created a "skel/" folder, and placed the framework, and game code inside that. (game.bmx and functions.bmx, as well as wordlist.bmx and music.bmx, which haven't been used yet.. Mostly 'cos I haven't finished off the music stuff!)

If I start a new game, I make a brand new copy of the folder, and begin.
This means that although every game will have the ever-building framework, (which can be reverse engineered back into the skeleton whenever I do something useful) it'll be it's own copy, and it won't get borked by something I decide to add halfway through another project 6 months later!

It also means, though, that the framework can be rejigged each time, to suit the target game better. Sprites can be reorganised, menus can be added in, control schemes reconfigured and more.
I've built the framework with these sorts of thing in mind. So, although the "Graph()" function will be more or less the same each time, they can be tweaked to show extra stats, depending on the game, without breaking other graphs.
The default fonts can all be changed in a small section of the code, and not end up changing the fonts in all the other games.

I've done it this way, because I'm building lots of games using this. If I were making a game a year, I'll probably have done things differently. But I need things tweakable because I just can't trust myself to leave things be.
Views 93, Upvotes 12  
2010 Framework
New games every week!
Site credits : Jayenkai
(c) Jayenkai 2023 and onwards, RSS feed 5

Blog - Framework Explanation - AGameAWeek