Mega

Last Login:
April 20, 2015
Warn:

Rank:
Member



User Profile
Comments
Follow

Hits: 120,878
Joined August 08, 2010
Games (11)

Game Music Player
October 10, 2011
Exile
August 01, 2012
In a word
August 10, 2010
Trace
October 07, 2010
Flood the mines Demo
November 12, 2010
Tetris
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


March Blog
Posted on March 23, 2015 at 16:38

I've got a distinct lack of blogs for this month, besides that UE4 announcement thingy.
So here's a hodgepodge of a blog; I'll try to section things off neatly and remember to use paragraphs for once.

Work
Work has been... interesting. I still get basket cases bringing their PCs into the shop, along with other electronic devices.

I've been asked, over the last two weeks, whether I can repair:
> Fax Machines
> Toasters
> Televisions (CRT & LED with a busted screen)
> Amplifiers
> Microwaves
> DSTV Decoder (Set-top Satellite Box)

The looks on people's faces when I remind them that this is a computer repair shop straddle the line between bewildered and horrified.
They seriously don't see why I don't fix these objects. I mean, heck... I could try, but I'd more likely break it/turn it into an analogue computer than actually do what they want me to do.

Also had one of the usual dicks in the shop last week. I was pleased to learn that most of the other shopkeepers I know refer to him as "That Bloody Wanker".
He's a musician, plays Afrikaans gigs (Guitar + Singing, solo) and obviously thinks he's a Big Deal.

So, he walks into my shop with his laptop. He uses it to play his backing tracks and record music on, and for some reason his audio ports have stopped working, and he has a gig the next day. So it's a big emergency, and I help him out.
About 10 minutes and one driver repair later, they're working again. He's overjoyed, until I tell him the repair cost.

Our shop has a basic "service" fee, per hour. So the first hour costs a fixed amount, at our discretion. This applies to any 'basic' job such as the above, or helping people "Fix their Facebook", and so on.
It's about $15, R150 locally (And about 15 loaves of cheap white bread around here).

This is a middling bit of cash; it's not huge though. We pride ourselves on having lower basic rates than the other computer shops in the nearby area. The next lowest price for this sort of thing is R450, three times what we charge.

This guy proceeds to throw the biggest tantrum I've ever heard an adult throw. He goes on and on about how he's a "Starving musician", that I'm a "greedy son of a bitch trying to take his hard earned money" and the usual allotment of swears that the locals learned in school.
If this was my first month on the job, I'd probably have been scared off. Fortunately, I've figured out the best way to deal with them:
"Shut the hell up, pay up, and get out. I don't want to see you in my shop again."

A lot of the customers I have in the shop tend to have a bit of an attitude, like they're doing us a 'favor' in bringing their problems to us.
I often have to remind people that if they knew what they were doing, a lot of the problems they pay for me to fix wouldn't happen in the first place.

I get three primary customer groups (Four if you count the Toaster brigade).
> People needing a problem solved (Repair, Viruses, etc)
> People wanting advice
> People wanting to buy a retail product

The latter two are usually amiable, and never cause any trouble.

People who fall into the first category tend to either be very polite, or extremely vitriolic.
Often, when they see how 'simple' a problem was for me to solve, they get angry and seem to think it's somehow my fault that they didn't know how to solve the problem.

But yeah, my policy with these customers is that I don't want them or need them. Let them go; they'll probably come back later with mumbled apologies (Which has happened a few times when they go to the competition and pay through their nose for the same job).

On a more cheerful note, our landlord told us to move at the beginning of the month. And no, I'm not being sarcastic; she's letting us have another shop in the building that's 6 times the floor space, with a storage room at the back, and all for the same rent!
We're actually in the position where this feels like too much space, and we're puzzling out ways to effectively use it.

One of the improvements we're making is the placement of a coffee table and armchairs, along with a coffee machine and a stack of computer magazines (Those being provided by me; have nearly 300 assorted mags).

To make our shelves seem a little less empty, I'm putting a bunch of old empty part boxes on display; things like GPU boxes, motherboard boxes, etc. Looks nice, and also happens to be stuff we can order.
I'm going to make sure to put an "Order on request" sticker on the empties though, because otherwise I'm going to be explaining myself every day.

Programming
I haven't been doing as much programming recently as I'd like to be doing, but I'm slowly getting back into it. I have a multitude of mini-projects I'm working on at work.
These include:
> QRL - Quick Roguelike; something like Binding of Isaac, with rudimentary graphics. Looks like an Atari 2600 game at the moment.
> QRL3D - Working on a span-renderer akin to Doom and making a simple shooter/roguelike hybrid.
> CSH - C-like scripting language library, trying to make it as tight as possible.
> RAY - Simple raytracer I'm kinda piecing together using the materials below.

I've been getting into the recent habit of naming all my projects in upper-case, as you can see.

At home, I'm working on a Super Secret Project with Jeremy; if you know what it is, let it be known that major progress has been made on it.

I've also been working on a simple port of Exile to UE4, just to learn the ropes. I haven't got much further than importing my assets though. :P

Interesting programming materials
I've been reading from these two sites recently:

Fabien Sanglard's Site
Full of wonderfully constructed breakdowns of classic game engines. Wonderful to read, especially how the Doom & Quake engines work.

ScratchAPixel
Want to learn CG? This site is an absolute gem. Written by anonymous programmers who may or may not work for Pixar and other big companies, it even includes a primer on the basic math you need to know to start writing raytracers. All in C++ too.

Also FlipCode, which I'm using to write the semi-software renderer for QRL3D above.
I say "semi" software, because I'm technically using a GL context to provide an easy way of writing pixels to the screen in a simulated limited-color environment.
Screenshots when I remember to bring them home from work.

Games
Recently, I've been playing quite a lot of Guild Wars 2 (somebody bought it for me, and insisted I try it).
I've never really "gotten into" an MMO before, but this one is definitely interesting. Lots of platforming, adventure, dynamic events, and smooth combat. Musical score is decent too. :P

And for those times when I don't feel like playing anything online, I've been playing a ton of heavily modded Minecraft. I've got about 230 mods installed on my main pack, and I'm having fun building virtual server farms. I'm obviously channeling my rage at a work-related thing from a few weeks ago involving a server, a horrible network and other nameless horrors.

At work, when I'm bored and remember that Klondike/Solitaire isn't healthy, I've been playing through Megaman Zero again, as well as Super Mario Bros 3.

Footnote
The year is just about a third gone. It's scary, because it feels like my birthday in November was just a few days ago. Time flies when you have a job.

I'm thinking of joining both 7DFPS and LD again this year, when they next come around. Assuming I remember, and assuming I have the time. Events tend to conspire to steal time from me just as I'm about to do something I enjoy...

Well, that's enough out of me. Go blog some more you lazy cactus-people.




Unreal Engine 4 Free to all users
Posted on March 03, 2015 at 02:43

Apparently, on Monday, Epic decided to spontaneously drop all subscription fees for everyone, making Unreal Engine 4 free for download and use for anybody.

The only fees still in place are those related to income (After a certain amount of income, you pay Epic 5% of the game's revenue).

Here's the official blog:
https://www.unrealengine.com/blog/ue4-is-free

I'm gonna get to downloading this when I get home.

EDIT:
In other news, Khronos has just officially announced the successor to OpenGL, to be called Vulkan




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.

Code

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


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

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


And use it like this:
Code

int main(int argc, char** argv) {
    Tester::getInstance().doSomething();
}


Or, as I like to do it:
Code

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

int main(int argc, char** argv) {
    INST(Tester).doSomething();
}


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.

Code

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

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

        DECL_SINGLETON(Singleton)
};

int main(int argc, char** argv) { 
    INST(Test2).doSomething();
}


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.

Footnote
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.

VFS


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:
Code

# 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.

Code

class GSVFS {
    public:
        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.
    private:
        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:

Code

// 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(); }
        }

        update(*window);
        draw(*window);
    }
}

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

void draw(const sf::RenderWindow& window) {
    window.clear();
    // Render game objects
    window.display();
}


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.

Code

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

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

class GSWindow { 
    public:
        static GSWindow& getInstance() {
            static GSWindow window;
            return window;
        }

        sf::RenderWindow& getRenderWindow() { return *this->renderWindow; }
    private:
        GSWindow(){
            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) {
            // ...   
        }    

        update();
        draw();
    }
}

void update() {
    
}

void draw() { 
    INSTANCE(GSWindow).getRenderWindow().clear();
    INSTANCE(GSWindow).getRenderWindow().display();
}


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: https://dl.dropboxusercontent.com/u/11942397/Frosty2014.nsf

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




Bees.
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: http://www.twitch.tv/64mega/profile/past_broadcasts

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:
Code

class GObject {
public:
    static GRegistry registry;

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

    GObject();
    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:
Code
class GRegistry {
public:
    void add(GObject* obj);
    void cull();
    void iterateOver(std::function<bool(GObject&)> func);
    void update();
    void cullAll();
private:
    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:
Code
registry.add(this);


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.
Code
class EBlock : public GObject
{
public:
    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:
Code
EBlock::EBlock(int tx, int ty) :
GObject()
{
    this->registry.add(this);
}


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:
Code

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:
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:
Code

// Partial class definition
class GObject {
    private:
        Damage *damage = nullptr; 
        Collider *collider = nullptr;
   public:
       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.



Prev Page | Next Page

Recent Activity
 
Active Users (0)