Last Login:
February 28, 2015


User Profile

Hits: 116,236
Joined August 08, 2010
Games (11)

Game Music Player
October 10, 2011
August 01, 2012
In a word
August 10, 2010
October 07, 2010
Flood the mines Demo
November 12, 2010
January 24, 2011
Velocite R
April 12, 2011
Shinsetsu Ninja
February 18, 2013
Walk of Darkness Demo
November 15, 2013
Project Phoenix
April 30, 2014
Frosty RPG WIP
December 23, 2014
Examples (1)
Favorite Users

64DCG 2015?
Posted on February 27, 2015 at 19:37

Yeah, I'm tired, jumped up on energy drinks and coffee...

Here's a thing:

I have no regrets.
Actually, my only regret is recording that in such a crappy resolution.

Engineering Logs - Singletons Revisited
Posted on February 26, 2015 at 04:28

Now that I have free time again for my own programming projects, I decided to start working on games again, and thus on my game engine.
My current goal is to transfer the gameplay from that puzzle/RPG game that I was working on in collaboration (Which is on halt due to the guy I'm working with being bogged down by the German education system).

So yeah, I'm quietly porting it to C++; we don't want to use GM for it, because it's damned messy.

Anyway, the last blog I wrote about Singletons showed me doing it in the naive way: Manually creating classes 'as' a Singleton type by giving it specific properties.
That works, but is a slog. Wouldn't it be far easier to just inherit some sort of global "Singleton" type and not have to do anything further?
Well, we can. And it's easy too.

There are two methods I'm going to address: One for those who like templates, and one for those who don't.

The Template method
Templates are a very powerful part of the C++ language... but in my personal opinion, they can also be messy, unwieldy abominations that make your code look like it fell part-way into a mincer.
It all depends on how you use them, of course.

Originally, I was just going to write the quick and dirty 'macro' technique, as below, but then on the spur of the moment I added this as an elegant alternative.


template<class ATYPE>
class Singleton {
        static ATYPE & getInstance() {
            static ATYPE singleton_instance;
            return singleton_instance;

And that is pretty much it. Define your classes as such:

class Tester : public Singleton<Tester> {
        Tester(){} // Prevent construction
        void doSomething() { 
            printf("Something is being done\n");

And use it like this:

int main(int argc, char** argv) {

Or, as I like to do it:

#define INST(singleton) (singleton::getInstance())

int main(int argc, char** argv) {

Works like a charm, easy to use, and easy enough to understand.

The Black Magic method (Macros)
First things first, Macros aren't by any means "bad". But there are "bad" ways to use them.
The C Pre-processor is a very powerful tool in the right hands; I use it to process my game scripts (Whether LUA or Squirrel), allowing me to use the ever-useful #include directive, as well as macros.

Macros, when used incorrectly, can cause all kinds of headaches for the developer; so use them at your own risk.

This, however, is an interesting little use for the things.


#define DECL_SINGLETON(stype) static stype & getInstance() { static stype singleton; return singleton; }
#define INST(singleton) ((singleton&) singleton::getInstance())

class Test2 {
        void doSomething() {
            printf("Something else is being done!\n");


int main(int argc, char** argv) { 

Arguments for and against either method
Both of these methods work; they are almost equal in performance, identical in use... it's just a case of how you want to create your singletons.
Personally, I'm a fan of simply inheriting from the Singleton type. It's clean, elegant and easy.

On the other hand, you may be working in an embedded environment where templates may not be supported (Unlikely as that may be. Embedded systems are pretty sophisticated these days). Or, you know, you're using wxWidgets and already have a million macros sprinkled throughout your source.

So basically, flip a coin.

I'll probably be posting a few updates on that game, specifically on the 'porting' process, within a week or two.
Though porting is a bit of a grand word to use; it's like creating a whole new game; I'm just reusing the art and game rules. :P

I did a thing again.
Posted on February 16, 2015 at 11:04

I woke up this morning feeling vaguely down about it being Monday and all (I spent my entire weekend setting up computers; hardly caught a break).
So in a fit of madness, I got up earlier than normal and decided to devote half an hour to doing something.

That something turned out to be a little cover of one of my favorite Megaman tracks.
Working in Famitracker felt a little alien. Haven't touched it since September or so. :P

Engineering Logs - VFS
Posted on January 13, 2015 at 06:57

It's a quiet day at work and I feel like doing something with my time.
So here's the second in a potentially long-lived series of blogs about what I'm doing with my engine.

Just a note, before I start:
These may or may not be the 'best' ways of doing things, but I really don't give a damn. I'll do things as I please, since I'm the one who has to work with the end product.
Everybody is welcome to work in whatever way they think is best. This is my way of working.


In Exile I used a static class called AssetManager that handled all the resources used by the game. This included textures, fonts, music, sound and levels.

The AssetManager class loaded an asset list on startup, which was a file that looked something like this:

# Asset File
TEXTURE ./res/tiles/tex_brick.png BRICK_001
TEXTURE ./res/crosshair.png CROSSHAIR

SOUND ./sfx/enm_hit.wav ENM_HIT

MAP ./maps/E1L1.grv E1L1

This uses a simple parser to read in first a type identifier, then a relative path, and finally an internal identifier that was used in-code to reference the assets.
These are stored in separate lists for each type of asset, and come with associated Getters (GetTexture, GetTexturePAK, GetTextureIndex, etc).

The system worked, but became really difficult to deal with every time I needed to add a new type to the manager.

I did a bit of thinking and decided to implement a simple VFS, or "Virtual File System".

What I wanted was a very simple abstraction that worked with a class called File, of which there were subtypes (TextureFile, SoundFile, and so on).
The VFS manager must maintain a list of all paths from its root, and allow for both a lazy-loading system and for a preload system, with hooks for loading screens if necessary.

With that, I started out with what I believed to be the closest 'skeleton' representation of the VFS class and its methods. VFS is a Singleton, but I'm ignoring the specifics below.


class GSVFS {
        void stageFile(std::string path);
        void preloadFiles(std::function<void ()> loaderCallback);
        GFile& getFile(std::string path); // Will load if not loaded, but its
                                         // best to preload if possible.
        std::string root_path = ".";
        const std::string exclusions = "exe;dll;pak";
        std::map<std::string, GFile> files;
        std::vector<std::string> preload_list;

        void enumuratePaths(); // Recursively scan folders for files.    

This is just a simple representation of what I have. The ability to stage
files for preloading is very useful when you're loading a lot of resources, even small ones.
My actual implementation has quite a few extra management methods (For clearing staged files, unloading loaded files, mostly).

It's quite a simple system, really. The only 'complicated' bit is the enumuratePaths() method. And that isn't really complicated at all. It uses the C library header dirent.h to operate on the directory.
Certain filetypes are excluded (Via the exclusions string).

In addition to handling files on the actual HDD, the VFS class can also manage PAK files. It treats PAK files in a slightly different manner, in that it adds one extra layer to the root path that matches the internal name of the PAK.
This has the interesting side-effect of allowing 'patches' to existing assets.

As an example, if the original release of Exile had utilized this system and I wanted to fix those holes in the maps without having to build and release the entire game again, I'd just release a "patch1.pak" that overwrites the faulty maps.

Additionally, the VFS class also handles general file IO. So writing new files or reading from text/binary files is managed at a relatively low level via this class.

The GFile class

Well, time to discuss the data the VFS actually deals with.
The GFile class is pretty much a wrapped ifstream with a virtual Get method that returns the file contents.

In the case of the plain GFile, it returns a reference to the opened ifstream.
Other variants I use so far are GTextFile (Returns a block of text), GTextureFile (Returns an sf::Texture) and GSoundFile (Returns a pointer to the beginning of a Sound for SFML).

The implementation for each is black-boxed so that the caller doesn't have to worry about how it gets the data, just that it'll get it (Or an exception if the file isn't the correct type).
The VFS class manages instantiating the correct types via a table of lambda functions mapped to extensions.
If an extension isn't covered, the default GFile handler is used.

Well, that's enough of that. I'm going to go find something to do. Work is slow today...

Engineering Logs - Singletons
Posted on January 12, 2015 at 14:40

I'm feeling the need, to write blogs people won't read.

EDIT: Link to Part 2

Over the last year or two, I've been spending a lot of my time working on my ideas as quietly as possible. I have a 'major' game I'm slowly piecing together, bit by little bit.

One of the things that always slows me down is the engine I use for my games. I'm always torn between using an engine like GM, or creating my own.
I always want to create my own for the added benefit of being able to implement things that are unwieldy in GM, or even in Unity.
But as I've been noticing over the course of the last few competitions, I've always started out in C++ and ended up using GM (Or Unity in the case of Project Phoenix).

My work flow tends to involve drawing some initial artwork, and beginning work on the framework I'll be using. What usually happens not long after drawing the artwork is that I start to get anxious with regards to testing mechanical concepts, and seeing my animations in-context.
So I invariably end up just choosing the GM route for a quick game; at least with my competition entries.

In this case, especially with my long-term project (Called Fallen Keep), I've been sticking with C++ for the long haul.
My main reason for this is that it's far easier to express certain pieces of game logic in C++ than it is to fudge it out in GML.

Anyway, I've been working on the latest iteration of "my engine" for quite a long time now. About 18 months ago was when I started working on this game, and the new framework with it.

The engine that powers Exile was my original choice, but I realized shortly that the engine was very much locked in to creating 3D games; 2D games were too unwieldy. Much of the code was modified to fit into what I needed for the game.
If you ever want to see mangled code, give a programmer with nothing better to do a month and a simple 2D game engine, then tell him to make a Hexen clone.

Fallen Keep is 2D, and relies on the Core OpenGL profile for various effects. Exile primarily used Fixed Function OpenGL, and later mixed GL3.2+ features to add the lighting model I used for Abyss.
As a result, the render code is pretty much screwy. Rewriting in this case was the sane choice.

Anyway, enough rambling. I've learned a lot over the past year with regards to quickly implementing a game engine from scratch. A lot of experimentation has gone into this, and I decided to start writing a few pieces on some of the patterns and ideas I've been using for it.

Take everything with a pinch of salt. No doubt some of you will have an alternative, or 'better', way of doing things; that's fine. Discuss it, I'm always interested. :P

Singleton Pattern

This is a mildly polarizing design pattern; some people swear that you should use the things "wherever possible", whereas others insist they be treated as something akin to goto.

My opinion is that they fit the bill perfectly for their intended purpose: To provide the programmer an instance of a class, and only ever that one instance of that class.

Originally, I used to create purely static classes for things like this. The AssetManager class from Exile is an example.
There are downsides along with advantages to static classes, but in the end it boils down to aesthetic for me. I hate using the :: accessor outside of the only context I believe it fits: Namespaces.

Anyway, on to the actual definition of a Singleton.
The Singleton Pattern is a specific manner of coding a class in such a way that you can only ever instantiate a single instance of that class at any given time.

This might sound stupid to some, and in many cases it is. You wouldn't make, say, a GameEntity class a Singleton.

But for some things it provides an elegant solution to the problem of access.
A lot of 'tutorials' I've seen on GameDev and other sites that involve creating game engines tend to either make liberal use of global variables, or pass certain objects as parameters.
Something like this:


// Using some basic SFML code.
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

void update(const sf::RenderWindow& window);
void draw(const sf::RenderWindow& window);

int main(int argc, char** argv) {
    sf::RenderWindow *renderWindow = new sf::RenderWindow(sf::VideoMode(640,480));

    sf::Event event;
    while(renderWindow->isOpen()) {
        while(renderWindow->pollEvent(event)) {
            if(event.type == sf::Event::Closed) { renderWindow->close(); }


void update(const sf::RenderWindow& window) {
    // Do stuff, update view, etc

void draw(const sf::RenderWindow& window) {
    // Render game objects

This is a 'flat' example, just here to show the concept I'm talking about. I've seen quite a few "C++" engines that depend heavily on coupling like this (The function definition requires another object to exist, instead of being able to exist on its own).
Decoupling is fairly important to building stable programs, in any given situation.
Some classes and functions are designed to work with each other, but in some cases you're passing references out like candy. Break or change the thing being passed, and you start getting potential cascades of breakages.

The point with the renderWindow variable above is that it's something that will need to be accessed by a large number of classes.
If I was using SFML's built in draw functions, every Drawable object would need a reference to the render window.
And things will get messy very quickly this way.

Static classes alleviate the problem somewhat, but in my opinion are somewhat messy to handle.

So I'll skip those and dive right into the same program segment above, reworked to use a Singleton class.


#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

#define INSTANCE(singleton) singleton::getInstance() 

class GSWindow { 
        static GSWindow& getInstance() {
            static GSWindow window;
            return window;

        sf::RenderWindow& getRenderWindow() { return *this->renderWindow; }
            this->renderWindow = new sf::RenderWindow(640,480);

        ~GSWindow() {
            delete renderWindow;

        sf::RenderWindow* renderWindow;

void update();
void draw();

int main(int argc, char** argv) {
    sf::Event event;
    while(INSTANCE(GSWindow).getRenderWindow().isOpen()) {
        while(INSTANCE(GSWindow).getRenderWindow().pollEvent(event) {
            // ...   


void update() {

void draw() { 

Longer winded, perhaps, but neater... at least to my eye. :P
And yes, I'm using simple Macro expansion. I could also just call GSWindow::getInstance(), but I prefer the INSTANCE macro to be 'first'; makes it easy to read that I'm using one of the Singleton classes.

The 'creation' of a singleton can be automated somewhat with templates, but I prefer to hand craft them to a degree.

A way of creating something like "INSTANCE()" without using the pre-processor is to create a static method that operates on anything of the Singleton 'type', but I consider it too much work and extra processing to be bothered for the scarce few Singletons I use.

Anyway, back to the subject at hand.
This setup allows for a few things. First of all, clarity. Reading this code in my engine I see immediately that I am using one of the few Singletons I have.
Secondly, I can access everything with a guarantee that everything is initialized and ready to be used.
Thirdly, and class method or function can access and use the instance of GSWindow as long as it 'sees' the class declaration (Normally I'd split that GSWindow class into separate .h .cpp files).

So, a few notes. I only have three major Singletons in my engine, each of which are natural fits for the pattern.
These three Singleton classes are :
GSWindow - Wraps the sf::RenderWindow and associated window functions.
GSVFS - Virtual File System for game resources.
GSTasker - Task management system

The "GS" prefix stands for "Game" and "Singleton".
I had a GSInput class for a while, but decided that it was a poor idea if I ever felt like implementing multi-source input (for local multiplayer), or for input streaming (for demo playback, AI control, or even network play).

A little quirk you'll notice if you stare at the code hard enough is the way I implement getInstance(). I'm specifically taking advantage of the static keywork, initializing an instance of the class (Possibly on the Stack, depending on compiler and what the optimizer feels like doing, so don't get too carefree with them).
When the program ends, this instance falls out of scope and will automatically delete itself. Nifty, as it allows you to 'black box' the details of creating the instance.

Anyway, that's enough rambling for now. Next time I'll write about my VFS system, why I'm using it instead of my old AssetManager system, and maybe some other stuff.
Feel free to argue inefficiencies below; don't get too hard-assed about doing things 'right' though - there isn't any such thing as far as I care. If it allows me to make games, it's right for me.

F4D Progress Blog
Posted on December 19, 2014 at 16:19

I'll post micro-updates here.

I'm making a mini-RPG thingy, because that's what I feel like making.
So far, I've created a character template, and started on an icy dungeon/castle tileset. I'm trying to go for a somewhat SNES/GBA style of art this time round.

Here's what I have so far:

I also have some basic music I've started to hammer out. You can hear it here if you have an NSF player:

Not doing much more tonight; I have work in the morning. :P

Posted on December 08, 2014 at 15:36

I had a somewhat amusing day at work. I arrived this morning just before 9AM, and noticed something out of the corner of my eye.
There, on our store-front window, was a swarm of bees clustered together, about the size of a grapefruit.

I hate bees, and being stung. Fortunately, these bees were not interested in me in the slightest.
Still, as a precaution, we kept the doors closed for most of the day and put a sign up "CAUTION: Door closed due to bees" with an arrow pointing to the swarm.
Most people thought it was a joke, until they looked. Some of them jumped pretty far.

We don't know why they were hanging there, but they stayed that way all day while we waited for some beekeeper or other to show up. He didn't, and my boss was getting tired of waiting. The bees were hurting (literally in some cases) our business.
So she grabbed a can of Doom (Insecticide), sprayed some quickly and dashed back inside.
The bees didn't die, but they did start to fall apart. One of the last 'pieces' of the swarm that fell off had the queen in it, surrounded by a ball of other bees. Reminded me of Katamari...

The funny thing is, there wasn't anything there for the bees to make a hive in. They were literally gripping onto a tiny bit of dried paint that had formed a small bump in the paintwork, on the underside of the window lintel (Concrete and metal construction).

That was certainly the last thing I imagined happening today; would've taken a photo, but I kinda forgot. :P

Ludum Dare
I kinda flunked this. Not intentionally, nor because I didn't have time. The whole country has been going through rolling blackouts, and they were particularly bad on the weekend. I lost quite a bit of work to the first one, and had a lot of trouble getting back on track after that.

I didn't upload my 'final' product, but here's what I had at the end:

The theme for this LD was "The entire game on one screen". I decided to make something arcade-like. Waves of enemies would be beamed in by that contraption in the middle, and you'd have to survive for as long as possible, collect randomized powerups and possibly have a second player join in.

Somewhat low-key for me, but that's because of what I coded this in. What I do have, I made entirely from scratch in C++. I was originally planning to use one of my existing frameworks to accelerate the workflow, but decided to test the difficulty of doing something like this from scratch.

Turns out, not too long.

All I really have here is animation, running and jumping (And collision, of course). I had started on an enemy, projectile and health system when the power went out. And of course I hadn't saved.

I did stream a bit. Potato quality if you want to take a look:

Uhh... Impulse post mortem, I guess?

Overall 'engine' design
I decided to use a system that was a hybrid of my old Exile system, and a newer one I have been working on.
In Exile, all GameObjects are spawned into a single list. Every frame, this list is traversed, dead objects are culled and the update() method for each object is called.
This is great, when you're dealing with a small number of objects.
It's also great when you don't need any information about the type of object.

Oh, and it becomes a bloody mess when you need to do collision detection/object interaction. Loops within loops within loops...
Exile worked though. :3

My 'new' system uses a few different techniques. Here's the base game object class:

class GObject {
    static GRegistry registry;

    std::string id = "object";
    GSprite* sprite = nullptr;
    float x = 0.0F, y = 0.0F;
    bool dead = false;

    virtual ~GObject();

    virtual void update();

It's very similar to what I used for Exile. It has a 'dead' flag, it has a position (I could decouple that into a separate object, but I was rushing), and it has the update method.
The magic here is in the static GRegistry object.

A GRegistry is nothing more than a list of objects. Which isn't a big deal. Here's the definition:
class GRegistry {
    void add(GObject* obj);
    void cull();
    void iterateOver(std::function<bool(GObject&)> func);
    void update();
    void cullAll();
    std::vector<GObject*> objects;

The only mildly unusual thing is the iterateOver() method; it may be alien to C++ developers who haven't yet begun poking into the newer C++11 features.
An std::function is basically a 'safe' function pointer. Much cleaner than the old syntax.

In GObject's constructor, only one statement is called:

This basically means that any GObject is automatically added to the list.
The 'trick' here only comes into play when I start adding new classes to the game.

The first one I added was a "block" type, for level pieces.
class EBlock : public GObject
    static GRegistry registry;
    EBlock(int tx = 0, int ty = 0);
    virtual ~EBlock();

    virtual void update();

Note that it also declares a static GRegistry member. This overrides registry for the EBlock object, but leaves GObject's registry intact. This has a nifty use, as can be seen a bit later.

The EBlock constructor is basically this:
EBlock::EBlock(int tx, int ty) :

This explicitly places a pointer to the newly instanced EBlock into EBlock::registry, but also calls the base constructor, which will add a pointer to the instance to GObject::registry.

Later, in the Player object, I need to check for collision with any EBlocks. But I only want to check EBlocks, I don't want to loop through every single GObject like Exile used to do. Especially not for level tiles (Exile actually separated level collisions completely, adding another layer of collision detection. It was complicated).

But because of this system, I can use a very nice representation to interact with specific classes of object. Like so:

EBlock::registry.iterateOver([&](GObject& object) {
    EBlock* block = (EBlock*) &object;
    // Do collision stuff with block

I treat the cast as implicitly safe due to knowing that the objects EBlock::registry should contain are all of type EBlock. This is something that would be a lot uglier to implement if it weren't for lambdas; I'd have to define a separate method, and pass a pointer to that method into the iterateOver() method.

Of course, even with this narrowing of search data, I'd still rather move away from using GObject's for level collisions anyway. Generally I create a tile-table, and check against those directly (It's easy to determine what point in a grid the player will be in by the end of a frame, making the entire thing a single simple check as opposed to potentially hundreds of little checks).
Unfortunately, I ran out of time (Though I may finish this little project at some point).

This entire system makes working with classes of objects a lot easier. In Exile, I had a string called "id" (Which is present here for reasons discussed below) that I would check to find out if I was dealing with an object I wanted to deal with.
With this system, I know what type I'm dealing with, and can avoid a lot of conditional tests I'd otherwise be using.

The id member is there more as a tagging system now. Kind of like a packed data system that can be used for anything I want.
I could set the string to "cd" and have the following in my player code:

if(object->id.find_first_of("c") != string::npos) {
    // Collide with this object
if(object->id.find_first_of("d") != string::npos) {
   // Get damaged by this object

Though with the way my design is moving, I probably won't use it like that. I'm using a Component system more often at the moment, and my Object class will change to reflect that.
To avoid extensive checking, I'd probably implement the system somewhat like this:

// Partial class definition
class GObject {
        Damage *damage = nullptr; 
        Collider *collider = nullptr;
       void DoCollision(std::function<void(GObject&)> func);
       void DoDamage(std::function<void(GObject&)> func);

// Will use like this:
void Player::update()
    Player *self = this;
    EEnemyProjectile::iterateOver([&](GObject& obj) {

        // Check if colliding and perform following
        obj.DoDamage([&](GObject& obj) {
            TDamage* damage = (TDamage*) &obj;
            self->hp -= damage->value;

The implementation for DoCollision and the like will basically only execute the function if it actually has a pointer to a TCollider, and likewise for DoDamage.

On that note, I haven't actually tested internal lambda capture rules yet. The [&] I passed to the lambda mean to 'capture' all variables in the scope the lambda was defined in. I'm not 100% sure if the nested lambda will capture the entire scope, including the one passed from the outer lambda.
My logic says it should, but the compiler may say otherwise.


I rambled more than I meant to. I'll stop now. :P

Android Tablet and LD plans
Posted on December 03, 2014 at 15:47

Last weekend I saw an ad for a tablet that was on promotion at our local Walmart.
(Called Game here, to confuse people living in the UK. :P)
I was talking to my parents about wanting one for a while, but something clicked in my head at that point and I decided to buy the thing... at a cost.
That cost being that I'm going to be eating very simple packed lunches for the next week or two... but that's OK; I needed to break my Soda habit... and Dorito habit...

Anyway... I got the tablet on Monday. It's a Telefunken TEL7JD. I'd seen a few (mostly negative) reviews about its predecessor, the TEL7J, and was expecting a really low-end tablet. But that was fine by me; I really only wanted it for one thing: Reading.
I have a tonne of digital books on my PC, from iTunes and otherwise.
Speaking of iTunes... it's kinda stupid that it doesn't let you read books on your PC. It's just in epub format...

Well, the tablet I received was better than I expected, outdoing what the store catalog said in the item description. It's got a dual core 1.0Ghz ARM processor, 512mb RAM, a 7" display with a crisp resolution (Telefunken know their screens, I'd say), has Wi-fi (No 3G, but that's fine by me. I hate mobile carriers...), and has Android 4.4 installed.
Only 2GB internal storage, but I can get large SD cards on the cheap, and already have a 4GB one installed.

The thing is a little powerhouse. I've installed a collection of emulators on the system, including PPSSPP on a whim... and yeah. Playing Super Robot Wars is now my favorite time-killer at work.
Back to the 'powerhouse' thing... I can play Monster Hunter Freedom Unite via PPSSPP without slowdown. That seriously surprised me, all things considered.
The available DS emulators do a crappy job by comparison; slow as heck.

So yeah... great little device. Got it for the equivalent of $80, which is less than I bought my DS Lite for. Very happy with it, and I may even try harder to develop stuff for Android platforms now that I have a device to play around with.

Ludum Dare plans
So yeah... found out about LD yesterday, and decided to enter again. Mostly because I have this severe urge to make something that isn't related to my job.
Of course, I tend to feel pretty burnt out on weekends. But I'm planning on taking things slowly. I'll shoot lower than usual; make a 1-screen game or something like that, but do it as well as I can.
I intend to use C++; I've been practicing a bunch of rapid (And messy) development techniques using the new C++11 features. Lambdas and auto make for an easy method of passing game logic around dynamically.

Oh, and something about Pokemon ORAS
No, I haven't played it. I don't even have a 3DS. Wouldn't mind getting one though, because I especially want to play this game (Sapphire was the second Pokemon game I ever played, and one I still have good memories of, despite the naysayers).

The other day, a friend of mine introduced me to this:

That friend and I were talking about how this theme sounds somewhat metal for a Pokemon game; sounds more like something out of Super Robot Wars, Street Fighter... that kinda thing.
I jokingly said I'd have to make a Mega Gallade Mecha mockup... and actually started work on that:

Well, that's enough out of me. Got work tomorrow, so I need my rest.

Slow Saturday.
Posted on November 22, 2014 at 03:57

I'm sitting at the PC shop; I usually don't bother opening on Saturday, but I had a minor backlog (Which has been cleared).

I stumbled upon some very amusing and gratifying articles by one David Thorne; I now have the urge to employ weapons-grade sarcasm against some of my more annoying customers.

A little blog.
Posted on November 20, 2014 at 16:39

It's been over a month since I've written a blog. And I have some excuses for that. Ranging from laziness to business and everything in-between...

So yeah... I regret not being able to finish my game for S4D. I haven't even opened the project since three weeks ago, nor have I even given game design much thought for that time either.

The main reason for this is that my job is becoming busier. A lot busier. My range of responsibilities has increased, the number of customers we get on a daily basis has increased... and this is all great. It means I have a modicum of job security to look forward to; we're starting to get people from the next town over come to our shop for our prices and service! (And they have three franchise stores there).

And, with encouragement from my boss, I've been using the spare time I have at work to develop my programming skills further, specifically tackling areas I'm not comfortable with.
Things like GUI programming, design patterns, networking, inter-process communication, Unix/Linux specific stuff... and it's been great so far.

Within the space of three weeks I've become proficient enough with wxWidgets to create a simple GUI off the top of my head. It's dead simple once you get your head around the way it presents itself.

More C++/wxWidgets/Linux stuff
Linux. The more I use it, the more I love it. I've reached the "convince customers that Linux is a more-than-capable and free Windows upgrade" point. I've installed Lubuntu on three machines over the past couple of weeks; and the customers are satisfied.

But what I really love about Linux? Programming for it. It's so ridiculously easy to pull off what would otherwise be a hair-pulling exercise in Windows. Case in point being the existence of the Posix threads library.
Sockets are suddenly straightforward and easy to use. Child processes are relatively easy to manage... Yeah. It's been a fun time.

For the first time ever, I've been piecing together a "real world" application. A Point of Sales program, with an Inventory Tracker (Compacted to "POSIT").
After reading a few books on design patterns, I spent the time designing a decoupled system in which the core logic doesn't need to know about the data, and neither of those need to know interface internals, and so on.

wxWidgets allows for dynamic binding of event handlers during runtime, and I've been using that to my advantage. For data, I've been using a custom key-record system that defines the fields and types of the record as well as the content.
Each 'system' provides basic interfaces to the outside world, but I could just as easily use the Core and Data systems from a CLI implementation (And do, for testing), or create a socket based interface that can use a Node front-end. It's fascinating to piece together such a system.

The Inventory manager has been pretty fun to write; the fun began when I essentially noted that the "real" inventory classes more or less mirrored "game" inventories (In that the inventory contains a finite or zero number of items that have "effects" and cost/value associated with them).

The interface is designed in wxFormBuilder, and because of the way I detached event logic from the UI classes, updating the design is a breeze; even after deciding I had to redesign the entire interface using SplitWindows (For resizable panels), the existing logic worked just as it did before.

I'll try remember to snag a screenshot of the interface tomorrow. I'm rather pleased with how easy it is to piece these things together, and I'm already planning a new editor for my engine.

In other news, I've begun to use lambdas a lot more in C++. They're great; just enough functional programming without making the language a complete headache!
Also, I've begun to see proposals coming out involving the addition of modules to the language as a replacement for the old #include directive.
I think this could potentially alleviate a lot of headaches we tend to face when dealing with circular dependencies and such.

One feature I'm waiting for is for somebody to add the ability to replace :: with . when dealing with namespaces and static methods/members... because :: is ugly.

Shop stuff
Stupid stuff still happens on a daily basis at my workplace. It's usually quite frustrating while I'm dealing with it, but it's funny in hindsight.
Some new samples of the local flavor:
- Being told to "make" a PCI-E card fit an AGP slot because "it's your job".
- Having to deal with and attempt repairs on a laptop in which the HDD was taken out of the bay rather violently, and the SATA connectors were literally ripped off the board. The solution involved copious amounts of fuming, an SD card, external HDD bay, and RAM-loaded Linux.
- People buying a cheap second-hand machine from us. I tell them it won't play games. They still come back a few days later accusing me of selling them faulty hardware.
- One of my 'competitors' coming into the shop with his own PC. The problem? He didn't know where to plug the front-panel cables in on the motherboard (Even though it was clearly labeled). Took me all of 10 seconds...
- Being told that Minecraft, Borderlands 2, Far Cry 2 and several other games are "Free games, the ones at the shop are illegal".
- Again, faxes. And when I ask for the fax number, they hand me an email address. Explanations and hilarity ensue.
- Also, emails. When I ask for the email address, I get a fax number. Involuntary spasms may occur.
- Having to explain that Windows 7 or 8 (Or Sevenorate as some of the locals are calling an imaginary combination between the two...) will not slow your piece of shit laptop up by any stretch of the imagination.
- Ditto for desktop PCs.
- Same, but this time with fans being the preferred 'upgrade'.
- Getting paid in R200 notes for a R2 printout. I tend to point-blank deny these, though, much to the annoyance of the "valued" customer. Spend more money and I'll assign more value to you.
- Having people stop outside the shop, read the sign that clearly says "Friendz Computers", and still asking us "is this a computer shop?". This behavior has convinced me that the people in this town can't read, as they tend to ignore our other signs too (Back in 15 minutes, Away on Callout, etc).
- "I took this box out of my computer, it was making a noise. Why isn't my computer working?" - confused customer pointing at HDD.

I'm starting to really enjoy the work a lot more though. It's really satisfying to repair a machine quickly and get thanked by customers for efficient service.

I actually received a tip from one of my customers a few days ago. An Irish couple on holiday visiting a relative. They wanted me to pull the photos off this relative's computer and put them on a USB drive; the old man didn't want the PC anymore.
Not only did they give me a large tip afterwards (Precisely the same as the service fee), they donated the PC to the shop!

Well, it's back to work tomorrow. This week has felt really hectic; I felt like yesterday should have been Friday with how dragged out everything felt... and I'm only facing Friday tomorrow.

I still find an hour or so after work to play a few games. For the most part, that's been nothing but Risk of Rain for the last week; it's addictive as heck.
Just beat it for the first time last night.

I've also got my copy of the Witcher 2. Even better, it's the Enhanced Edition, which is very nice of GOG. I'm just waiting for it to download.

And on a final note... Dark Souls is extremely close to updating.
But here's a little twist... it seems that the update isn't merely a patch to remove GFWL...
SteamDB has a few interesting nuggets of information on what's going on behind the scenes.

One of the first things I noticed is that the new Depot size is 7.4GB, up from 4.06GB. This indicates strongly that there are some potential content additions and fixes.
Secondly, the depot branches. There are two major new branches of interest.
The first is "steambuild", with the description NOG4WL. Obvious what this one is.
But a new one popped up the other day. "hybrid", with the description "G4wl + Patch".

So yeah, it's pretty obvious that something is being patched, and it's probable that something has been added to the game. 3.0+GB of content is a bit much for a mere migration to Steamworks :P


I'll love From if they release the patch tomorrow, just in time for a weekend of invading. :3

Well, that's enough blog from me. I need to get to sleep.

Prev Page | Next Page

Recent Activity
Active Users (0)