Space Fortress wise, I have been getting some boring-to-discuss sloggage into a sprite system done. I now have:

1. An entity system (to be discussed later) for loading definitions of in-game entities from XML files, entities being the things in the game world that aren’t dirt.
2. A sprite system, which manages those animated little bitmaps drawn onto the screen. The Artist class responsible for drawing entities creates a sprite for each entity. The ‘front end’ of an entity, also xmelly
3. Used an ordered list on Terraflubb

These things are very crude at the moment but will eventually be one of the most feature-rich aspects of the game engine. Hopefully, once it’s in place, I will be able to convince myself that it is not a ridiculous introduction of complexity but something useful. My goal is to have a worker-drone and a building entity defined and set up in the game soon. Fun stuff comes after that.

I am not getting distracted, but I know that the old Horror Mansion will be able to use most of the things I’m building now. If I keep on plowing ahead this way, I think I can revisit most of my ideas in the future and at least get to the prototype phase. If they’re not fun at that point, I can be satisfied knowing that I tried.

Meanwhile! I’m so close to finally doing the whole Model - View dichotomy neatly arranged in my brain. I think it is all set at the moment, but until I get it animated, I won’t be pleased.

Why Worry? Because you might be a poseur.

As I have expressed before, I love to say I am a game-development hobbyist, but I do not have any artifacts that show as much. I know how to code and how to create passable programmer-art, but for all my years of experience, I have nothing! This resulted in me telling myself “Make your stuff recyclable! How many times will you fail at collision detection?”. So I adopted a strict Model-View-Controller approach to game development. I figured that I would eventually collect enough Model and View bits to be able to throw games together quickly. I did this with a few failed projects, and I’m pleased to say it’s working well!

How Rob does MVC in games

Since I never really learned MVC in an academic or professional setting, only from reading little things about it. I probably have it wrong. I also read the Gang of Four’s book, but I should really have chatted about it with an expert. But this is how I’m doing it. I appreciate corrections and comments, I respect the software engineering skills of at least 2 of my known audience.

Model

The ‘game world’ lives in the model classes, which are the ones that represent the game world. In Space Fortress, that means the 2D-array of dirt which makes up the planet (a tile-based level) and a set of entities (I’m defining that now) which are all the ‘things in the game which aren’t the level’. So, buildings, robots, monsters, and pomegranates. My model classes are laced with accessors so that all the important (observable) parts can be reviewed by public methods.

View

Then I have my view classes, which are made up of persistent, Artist classes. I have a WorldArtist which knows how to read the level data out of the model classes (read only!) and an EntityArtist which knows how to draw the entities (I should say ‘knew’ how). The EntityArtist will have to keep track of the animations and all that. It also does the GUI (with what I would have named GUIArtist, but instead I used Thingle so I won’t complain). It collects input and burps output. It does not touch the model directly, that’s done through the controller classes.

Controller

I currently have no controller classes anymore. But since I’m doing an RTS, they will be probably presented in some kind of UserDesire Interface, so the view sees my clicks, boils them down to a desire, then tells the model what I wanted. So “Click on a robot”, “right-click on spaceship”, “select dismantle”, gets turned into “new UserDesire(”robot_1″, “spaceship_12″, “dismantle”)” and gets interpreted by the model.

Why that hurts

Sticking to that makes me seem anal (believe me, I am not!) and it feels quick awkard at fist. Maybe this won’t work with an action game, it might only work with an RTS, since they are effectively spreadsheets with the data scooting all over the place. Oh, it probably would, I just don’t want to think about it right now.

It’s nice to be able to do this:

guy.jump(); // model
guy.draw(); // view

But now I do:

guy.jump(); // model
entityArtist.draw( guy ); // view

This makes animation a pain! But as you figure it out, you feel better for it. At least I did! We should all thank electrical engineers for making processors so fast we can software engineer the hell out of our games. I suddenly really have to consider what is game-affecting and what is cosmetic. Animation is purely cosmetic, until the animation is of a guy rolling, and when he is in the somersault position, the bounding box becomes half-height!

This is where my brain dislodged itself a bit, because something obvious became apparent to me tonight, and I have some coding to do as a result:

Pixels mean nothing at all to the model. They become “world units” or something that has nothing to do with lovely little squares of light. In 2D games, particularily pixellated ones, apparently my favourite kind to attempt, they map perfectly onto one another. But I must break that bond! I want to be able to do a full 3D rendered version of my game by only changing the view classes. A ‘world unit’ of OpenGL has nothing to do with a pixel! It’s up to the view to map them that way.

Model-view mapping

So now, I have my fancy recycled Entity management system for the model. It contains bounding boxes for collisions with the environment and fellow entities. However, I also need a Sprite management system, for the view. Entities map to Sprites. I think I’ll cheat and create both out of the same XML definition for now. But as it stands, I have a bit of code that does both right now (since the mapping is perfectly 1:1) and it’s time to diverge.

Moral of the story, Rob now believes the following:

• Model is to View as
• World Unit is to Pixel as
• Entity is to Sprite

And with that, the last shackles of pre-MVC is shed, and I delve into awesome. Until the next shackle is revealed. It’s late now, but I think the ol’ noggin will sleep now. Apologies for the typos and adorable grammatical issues.

OMG Another one

The following morning I realize there is another in the series:

• Tick is to Millisecond

Today was my last day of school for the year, so I expect that I’ll start updating again shortly. The whole point of this blog was to post to it frequently, so that’s what I’ll do!

My next step is to move the old Tinyroidvania sprite-animation system (with XML loader!) into the game so the sprites will no longer be integers for an array of Textures. Once they know how to be animated, then we’ll have more interesting videos.

There was also a great big overhaul of the scene drawing code. Right now there are two drawing sweeps. First the tiles are drawn (the environment) then the entities (the things). Both of these sweeps are very crude at the moment, but their logic is pretty sound. It was a bit harder than I thought to get the entities to wrap around the x-axis. There are a few neat little special cases that had to be resolved.

In fact, I’m so proud of this, I’m going to stick up my first video!

Geek stuff after the break!

Nerds can see in the “sprites” section of the debug window, there are three little letters that explain how the entity drawing/culling/wrapping works. A is the primary drawing box. It’s usually the only one used in sufficiently big worlds. Then there is W which is the wrapping box, with an optional P box for awkward cases right at the axis… oh geez. I need a diagram to describe this. Nevermind, just know that it’s kind of clever!

It’s always a bit embarrassing to blog this late.

This will become a bigger problem when other UI elements will start popping up on the screen. Clicks, sliders, stuff will all go bad. So I had better lick this early. I have always used a non event-driven input technique (I like to poll before my update phase), so I need to reconsider a few things.

Luckily, the Slick forumites are great and all deserve hats.

Feature Bucket

If you are ever lucky enough to find a feature in square brackets like this: [SVG], it means I narrowly avoided spinning off into a rant when I say “I want to do it like this, but I reserve the right to go off and do this cool thing I’m sure I will forget if I don’t mention right now and ruin whatever flow of discussion I almost had for a feature which will never materialize anyway!”.

In this little blog I will discuss the core components of the game, and explain what I think has to get done in order for me to ever be happy again.

Here are the core components of the game, and how I feel about them. When I talk about the game, I mean the game simulation system. The model of the MVC paradigm. I worry about V and C too much, so lets return to basics. Maybe with my fancy new Thingle, I can have a terrible UI to influnce the world for now.

• The Environment Tilemap
• The Observer/Subscription Infrastructure
• The Elements of the Game

Environment Tilemap

The environment tilemap is the planetoid! It is a very large grid, and each grid cell is a discrete square of world. Since a planetoid is round for us, it wraps horizontally. For sanity, I chose not do be able to go Australia and make there be vertical wrapping [VWRAP]. Another attribute of planetoids is that there is lots of atmosphere on the top of the scene, but lots of dirt at the bottom. So, I built it using an interface in order to minize memory use (it will only check a dirt array if it’s below the horizon). Seems obvious, but whenever I’ve made smaller games, I just used a big half-empty 2d array.

The Observer/Subscription Infrastructure

One comes with Java, I’m not sure why I didn’t use it. I rolled my own which is probably not quite as good. It deserves investigation [PROFILE]. Anyway, an example of two broadcasters would be the Environment Tilemap. Any change in map solidity would be of interest to all paths generated by moving objects. So there is a SolidityListener. Also, any physical changes (holes in the dirt, new buildings, etc…) would get some kind of an SceneUpdateListener (bad name), so that the classes which are caching the art can update.

The Elements

Now there is a single class for all in-game Elements. An element is either a builder, or a worker, or a piece of equipement. Or anything that isn’t dirt or sky. The problem is that these thing move tile-by-tile. Which is not good. Because I like (sub)pixel-smooth movement. Instead of ditching this work, I think I can still use this class exclusively for static things (buildings) and then spin a subclass or something that moves pixelly.

While I think it was a good thing for me to try thinking before coding (as I’ve grown to appreciate software engineering), I don’t think I properly thought through the design before commiting to that which I’ve coded. Here is what I will do next.

I started this project out of love for Dwarf Fortress. Which is still the greatest game in the world. My original ideas were not particularly inspired, make it 2D, make it graphical, make it sci-fi. I think I was more excited by the code within DF that made emergant gameplay so diverse and exciting.

Before DF, I liked Sim City, Miner VGA, Caesar, Sim Tower, and any number of those tycoon games. I also had a dream about making a candy factory game. I can’t find those screenshots anymore, so it didn’t make the projects archive. I liked games where people built a system and watched it go. Since DF’s system is my golden standard, I somehow became infatuated. I wanted to be like the cool kid.

I think Space Fortress (working title, by the way!) needs to stay inspired by those things, but it’s silly and uncreative to attempt a clone. It’s one thing to clone Tetris or Pong when you’re learning to code, because they can be described on a napkin.

So, I’m reconsidering the design decisions I made. There is still plenty of good recyclable code (it’s mostly UI and pathfinding), I still want cities to be built, underground complexes to be hacked together, but I don’t want it to be DF-on-the-moon anymore.