Archive for the ‘Software Engineering’ tag

Model… revisited…

Hi everyone, it’s Vlad again.

It’s 10:52AM, 30 degrees Celsius if you stand in the shadow and just a couple of hours ago I hit an issue with our current project. Basically static data regarding gameplay was becoming completely unmanageable. Before moving forward I decided to rethink and drew how my classes were organized.

Let me tell you what this is… Data and Gameplay are folders, packages in AS3 terms. Tokentype1, Tokentype2 and Constants are classes that hold data in the form of static functions and constants. LevelController, LevelView, TokenController and TokenView are classes that are either controllers or views of my gameplay objects.

This is how I’ve organized most projects until now, so what’s the problem? For starters, all games until now have only one token type. This game has two but it will have more. I was about to actually copy/paste a method from TokenType1 class to the TokenType2 class… you know how bad this is right?

On top of that a new problem was present for a couple of days. Some variables names, class names and query methods conflicted, not logically but in terms of what I was reading while coding. Building, IsBuilding, buildings, building and so on… variables like type, code and state also weren’t 100% clear.

So I decided that it was time to redesign and refactor before it became too nasty. Here’s the result:

I simply took the MVC pattern seriously and created models for both level and tokens. On top of that I changed all ambiguous variables, states and methods to be named consistently throughout the project.

The LevelModel is nothing more than the old Constants class. There’s no big difference for now except that when gameplay is closed and we move to other stuff, I’ll have to create models for all the other stuff instead of having all constants inside one “global” constants class.

The TokenModel is the big change! It holds all the stuff from TokenType1 and TokenType2 classes, but now I can guarantee that there are no duplication of methods, arrays and so on. Big part of this arrangement was to deal with the inconsistent naming of variables and so on.

I’m very happy with the solution, now, if you excuse me, I’ll get back to coding game functionalities.

Bold Pixel Structure

Here’s a real headache. I’m not really a coder… I don’t have the mindset and I lack a lot of knowledge so I tend to do things my own way. Sometimes, that’s good! Often when a more imaginative solution is necessary. But more than often, I’m trying to reinvent something that already exists.

When I started the current project, I decided that first thing to do was to rebuild the code base. The structure that was born is something like this:

core.algorithms.* is where all algorithms reside. By the time I’m writting this post, the sole habitant of this package is a yet to finish A* algorithm.

core.managers.* is the home of all managers. A manager is a central system of the core. By definition, other systems depend of the existence of one or more managers to function properly. By the time I’m writing this post I have an application manager, a scene manager and a loop manager.

core.services.* A service is an isolated class that serves some purpose. It has no impact or usefulness behond a determined task, for instance, preloading the game.

core.structures.* Data structures go here. In the before-engine version of our core base, this was filled with a re-packaged version of Polygonal Labs Data Structures for Game Developers. I decided to restart the work here to keep code standards equal throughout the engine.

core.systems.* Systems are all the main classes that are relevant and play an important role through a game but that are dependencies of other classes. By the time I’m writing this post I have an audio system, a file system, an input system and a music system.

core.tools.* Tools go here… who would have thought of that?! From collision to math passing through little tools like getting the domain name to site lock the games, almost anything can fit here.

Thoughts?

    Newer Entries »