Progress #5

Wrote a function today which extends Redis’ capabilities with a combination of mget and hgetall … a sort of hmgetall.

I’ll be using this on server startup; it will attempt to get one and only one Config object stored in Cache; if it exists, then it will iterate through Config‘s stored object keys, calling RedisQuery.getObjectFromSerial(), building the application’s stored objects on-the-fly; if it doesn’t exist, it will instantiate the same, and store the new serials of the objects for later use.

Progress #4

I’d added cache object loading based on serial number; it looks something like:

redisQuery.getObjectFromSerial(someSerial).then(obj => {

// obj is the redis-cached object

});

Tonight I specifically worked on map loading, using the new WorldMap cache-object class. Works like a charm, but not being able to return a Promise and still have access to the generated ES6 object is a pain in the nethers.

Distributed Game Servers

I’d become interested in distributed computing a few years ago. I worked at a place where we built software which worked across a network of machines, and regardless of the number of machines connected into the system, the software would treat each host as one.

It was quite cool, and as time went on, I acquired new opportunities to apply my distributed computing knowledge to different situations.

The one potential situation that gripped me most firmly was that of a distributed network server used in client/server computer games. With the advent of WebSockets and Canvas/WebGL at the time, I felt it was integral to build something using these crazy tools in this brave new world. Something that I loved immensely. Around this time, my research led me to discover ActionHero.

Everything Old is New Again

Foundations. I’ve been putting together foundational pieces for Tempest once more.

Tonight’s work includes some Photoshop work to create a new 32×32 tile set (the previous one was known obscurely as “Lost Dragon”, was ripped from molotov.nu once upon a time (which has since been repurposed), has no source online that I know of, and is generally, literally, “lost”. It’s really quite complete and nice, but it sorely lacks paperdoll sprites, allowing me to enable players to overlay their characters with equippables. So I scrapped it. (It’s still checked into my repo. Who knows, maybe one day…).

My current tileset will feature an attractive combination of well-established derivatives of sprites from various online sources. Sadly, I’m not the greatest graphic designer, plus I have just so much to deal with, that the sprites I use will be graciously donated by Google Search.

Moving along, I have also found an update to the map creator source that I used previously. It has some minor fixes, so I’ll use that as a foundation, and implement my own interface into it, enabling me to generate worlds far beyond the original intended size.

Cache Objects

A friend and I had just completed the 2016 7DRL challenge. During the course of development, I’d been itching to try new ES6 features, specifically that of classes and inheritance.

I’d come up with an idea to create a class whose attributes would be stored locally on the application server, but whose attribute-values would be stored remotely in a memory cache (specifically, Redis).

Tonight I’ve written what I think will become the basis for my ‘next generation’ online roleplaying game, Tempest.

There are three kinds of objects which expose specific functionality: CacheObject, CacheProperty (inherits CacheObject) and CacheHashProperty (inherits CacheObject). Then there’s the Entity, which composes itself automagically, given a set of properties and initialized values.

In a typical JavaScript scenario, you’d have something like:

var myObj = {
attr1: ‘value1′,
attr2: ‘value2′
};

But what if you want to store these in a memory cache (particularly useful for a high-availability system where shared cache is a necessity)?

With my new system, you instantiate an object like so:

var myObj = new Entity(’myentity’, { arg1: ‘value1′, arg2: ‘value2′ });

Then, with this cacheable Entity in hand, we can perform things like:

myObj.arg1.get().then(function(value) { console.log(value); });
myObj.arg2.set(’newValue2′);

The cool trick, however, is when we need to read or write multiple parameters at once:

myObj.get().then(function(theObj) { console.log(theObj); }); // { arg1: ‘value1′, arg2: ‘value2′ }
myObj.set({ arg1: ‘newValue1′, arg2: ‘newValue2′ });

In each case, a promise is returned by the (io)Redis client, that allows a calling function to control program and I/O flow, in normal Node.js style. But what’s truly great is that this class allows any entity to be synced realtime with Redis, as well as provide a meaningful, clear and simple interface for achieving fast memory-cached data storage useful for high-availability applications.