Skip to main content


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Radnen

Articles / Sphere Tip: Working with sprites
So I'm going to start things off with a series of tips for future Sphere Game Developers. Today I'll be talking about a neat trick for making maps quickly in your Sphere game.

Have you ever used Sphere's map editor and realized how slow or clunky it is to map out each item tile by tile? Well, there is a good remedy for that, at least when it comes to props such as trees, lamps, tables and other pieces of scenery or furniture. Use sprites.

We tend to think Sprites are NPC's. In Sphere at least, a person is regarded as an object that does some kind of action, whether it's on talk, touch, create or destroy. It may even have animations since they are tied to sprite sets. But what about static props? They don't interact with anything - and that's okay. Today we will be talking about the benefits of using sprites for mapping.

1. Dynamic sizes
If you change the look of the sprite you don't have to re-tile them. Now I know you don't have to worry about that since all external tilesets will affect the tiles on every map (if you repaint over the existing tiles). But if you make a tree taller, wider, or even smaller than it is, then it gets very messy very quickly on how you handle that. With a sprite, if you drastically change the size, you can see it everywhere immediately. No tiles or layers to mess with.

2. Easy placement
All you need to do is operate on the same layer the player sprite is on. Some trees and other tall objects may utilize several layers, e.g. the player layer, a top layer and maybe a ceiling layer. With a sprite, you only need to place it on the same layer as the player. If you want to move the sprite, you can just use the sprite mover tool and entire trees can be lifted and moved in a literal snap. Don't like one configuration of trees? Move them around a bit and see what works.

3. You get z-index shuffling
As a neat benefit, unlike tile layers, sprites reorganize. If the player sprite is behind a tree, it will shuffle in front of the player and vice-versa. This allows for neat depth effects, much better than what static ceiling layers give you.

4. You get advanced animation opportunities
That's right, since the tiles are now a sprite, you get frames and directions that you can animate. Throw down some code and the name of the person object you created and you can have your props react to the world around you. Light switches, chests, bushes that got caught on fire, you name it. If it's too much trouble to animate the tiles, animate a sprite instead!

5. You get analogue.js/persist.js support
For the experts here, in addition to advanced animation you can now store state with these sprites. A berry tree that grows berries only during certain times can be made easier moving the tiles into sprites. That is, if you use one of the advanced map scripting systems.

Now, hold on a sec! You don't want to convert everything into sprites. Keep your sprites only for NPC's and props. Terrain, cliffs, houses, and other larger and more static structures should remain as tiles. Animated water is hundreds of times better left as an animated tile rather than as an animated sprite. If it's going to take a lot of intricate tiles, stick to using tiles, but if the prop will be used throughout the map as a standalone object then use a sprite. Ask yourself if you want to move a tiled out tree vs. a tree sprite. You'll find the latter easier to manage.

Buildings could be sprites too, but due to the bounding boxes, it might be easier adding doors or layers with balconies the player can visit to tiles instead. I see buildings as cliffs. If it can't be climbed, but walked on, keep it as tiles. Lamp posts, signs and the like can be sprites. But objects that decorate cliffs - like windows and rock outcroppings - should remain as tiles.

By replacing props with sprites, not only do you get the advanced features listed above, but you will be creating and populating your maps in no time. If you are worried about performance, don't be.  Modern Sphere engines can handled hundreds of sprites on a map. In this era of 2D game design I'd take advantage of that whenever I can.
So, I just realized that in these new forums I don't seem to have created a topic for Blockman. So, here it is.

Old Project Page:
Old RMN Page:

I have renewed my interest in game making and seeing the success of 2D pixel art games on steam and GOG (I'm looking at you stardew valley), I have decided that this project is still worth pursuing. In the coming weeks I'll update this page with anything new I'm doing. I really want to get a new demo out to you guys soon. There is an old demo on the rmn page.

My time is limited and made more so since I have many things I need to figre out in my personal life (like a new home, for instance), but whatever free time I do have, I'll spend it on tweaking some things here and there in this game.

I have already decided to overhaul many of the graphics, so stay tuned for some screenshots. BTW, I'm calling this game "Shadow of the Nexus" but I'm not committed to it. Basically it's a nod to a theme throughout the game: that some evil corporation is pulling all of the strings and so you are sort of playing in their shadow without knowing about it. It's a very square-like story type thing (I guess?).
Programming / Operator Overloading in JS
Guys, here's something neat I think some of you might find interesting. I was thinking of how I can overload operators in JS and was thinking about using the toString method, but if you use valueOf instead you can add some interesting logic to make operator overloads possible.

Pay attention to how the number 3 is used to figure out which operator was requested in the overload process.

GitHub Demo:
Off-Topic Discussions / Windows 10
It's out guys and it's awesome!

Look what it did when I ran a game in Sphere. I can record and stuff. Sphere Studio works, and heck everything works like it did out of the gate. It's amazing how there's little to no effort to upgrade to it. I'm impressed. :)
Site Comments / Site Errors
I often get "No Data Received" errors while visiting the forums. What's up with the hosting?

Do other people get this? It doesn't happen often, but I have lost a post or two because of it. (not a big problem for me as because I'm in the habit of copying the message before posting just to make sure).
Articles / Fast In-Engine Particle System
So, I've been playing around with my Sphere SFML and ended up creating a rather fast particle engine by being slow. Sounds interesting right? It's the tortoise vs. hare approach and I'll show you how it's done.

So, first things first we create a particle budget. This is the first trick to the system. We create a static sized array filled with dead particles. A dead particle has all the data fields it needs to do work, but is turned off when it's action is complete. Usually when a particle fades out, we can consider it dead since you cannot see it anymore.

Here's how the particle budget looks:
Code: (javascript) [Select]

var ParticleEngine = (function() {
var particles = [], budget = 500, idx = 0;

function Setup(b) {
budget = b || 500;
for (var i = 0; i < budget; ++i) { particles[i] = new Particle; }

return {
setup: Setup

Next we define a particle:

Code: (javascript) [Select]

function RenderP() {
this.color.alpha = this.alpha;
this.image.blitMask(this.x, this.y, this.color);

function UpdateP() {
var tstep = StateManager.timestep * 60;
this.x += this.vx * tstep;
this.y += this.vy * tstep;
this.time -= StateManager.timestep;
this.alpha = (this.time / * 255;

function SetupP(parent) {
this.alpha = 255;
this.image = parent.image;
this.x     = parent.x;
this.y     = parent.y;
this.vx    = parent.speed * _cos(parent.angle);
this.vy    = parent.speed * _sin(parent.angle);
this.time  = / 1000;  = / 1000;
this.fade  = parent.fade;
this.color = parent.color;

var _cos = Math.cos, _sin = Math.sin;

function Particle() { this.time = 0; }
Particle.prototype.update = UpdateP;
Particle.prototype.render = RenderP;
Particle.prototype.setup  = SetupP;

There happens to be minor speed increases caching functions like the above, but it seems to vary a lot depending on engine used. This is just the safest, fastest approach to use. These particles are simple, they only fade out and move in a single direction. But they don't have to. We can always add more logic to them to make them more complex. It's really up to you.

Next we create an emitter:
Code: (javascript) [Select]

function Emitter(obj) {
this.image   = obj.image;
this.x       = 0;
this.y       = 0;
this.angle   = 0;    = || 1000;
this.speed   = obj.speed || 1;
this.color   = obj.color || CreateColor(255, 255, 255);
this.fade    = obj.fade || false;
this.rate    = (obj.rate || 25) / 1000;
this.last    = 0;

Emitter.prototype.emit = function(x, y, num) {
this.x = x;
this.y = y;

for (var i = 0; i < num; ++i) {
var p = particles[idx];
if (p.time <= 0) { p.setup(this); }
idx = (idx + 1) % budget;

I could have done some minor optimizing but I think it's safe since we use very few emitters in a game compared to particles rendered.

Take a look at the emit() method:
Code: (javascript) [Select]

Emitter.prototype.emit = function(x, y, num) {
this.x = x; // here we set an emitters x/y since for neat effects we could have emitters move around the screen.
this.y = y;

for (var i = 0; i < num; ++i) {
var p = particles[idx];
if (p.time <= 0) { p.setup(this); }
idx = (idx + 1) % budget;

Heavy logic parts ahead, know your O-notation. ;)

Here is the good part. This is where dead particles get turned back on when an emitter emits particles. Rather than doing many O(n) lookups to find dead particles, we blindly loop through one at a time and turn them on. All emitters access the same global array in this same linear fashion so all emitters are essentially running the same O(n) complexity at the same time. It also skips over alive particles on the same burst. It turns out in practice that alive particles rarely overlap, unless the buffer is full. Technically we can be more accurate here, but remember on a full buffer it would repeatedly do O(n) lookups and "busy-wait" for a freshly dead particle which is incredibly slow. I'd rather it step over alive particles while it continues to decrement the burst count so that there is always a finite end to each burst (yes it reduces accuracy, but in practice it's not bad, especially with very high particle budgets).

Another neat thing here is the modulus. It makes sure we wrap around the particle buffer freely and efficiently. Otherwise I'd add if statements which are a tad more costly than a modulus and again, depends heavily on the JS engine used. What about not wrapping it (since wrapping really only happens at a fraction of the total size)? Well... we could forget about particles greater than the size limit and instead just skip the burst altogether and reset the count. But then large particle bursts can look ugly if timed incorrectly, so for a gain in accuracy we use the modulus. Also not wrapping still takes if statements and other control logic, and so is slower.

Finally, the meat of the emitter is the "if (p.time < 0) p.setup(this)" statement. It tells that particular particle to turn alive with parameters fed into it by the particular emitter used. This maintains the static particle budget and completely stops GC'ing from occurring. If we deleted and recreated particles each time we would have initially a faster particle engine since we are maintaining smaller arrays, but then there would be an unforeseen cost to GC collection and there would be constructor overhead as memory is acquired. The create/destroy approach is 100 times faster than this approach but scales horribly at the 500+ particle mark. This static method scales beautifully even at 15000+ particles.

So to continue in the vein that slower is better, let's take a look as to why. In a static system we must update and render all particles all the time, always checking if they are alive or dead.
Code: (javascript) [Select]

function Update() {
var l = particles.length;
for (var i = 0; i < l; ++i) {
if (particles[i].time > 0) particles[i].update();

function Render() {
var l = particles.length;
for (var i = 0; i < l; ++i) {
if (particles[i].time > 0) particles[i].render();

I could micro-optimize this, but nevertheless the speed hit is the same. Whether you draw 1 or the entire buffer, the script speed hit is nearly the same. So your games base FPS will be slower by using this, but it'll end up steadily drawing 10000 particles whereas other methods will crap out at 1000 or less even if they draw the first 50 thirty or more times faster than this method.

It just goes to show that sometimes extremely high FPS is not the answer to a fast 60 FPS game. It's rather a steady framerate that can take pressure under larger loads.

I'm currently creating a space-sim game in Sphere SFML (flexing my math muscles a bit) and the fps in SSFML in that game went from 3500 FPS using my old particle system to the more stable 1000 FPS. At 100 particles the fps was at 200 FPS on old system and at 900 FPS new system. At 1000 particles the FPS was 60 on old system and 850+ on new system. The fps only dropped as more particles were rendered, but makes up for it in the fact the JS is constant time whereas before more JS was executed per particle, blowing up the complexity of the system. That and HW rendering becomes the next major bottleneck (which is rather good so no problem there).

I have likewise used this approach to draw other things too. Like a static sized spaceship pool, GUI element pool, etc. It really is a much faster approach and probably closer to how games were originally coded on low-powered devices like the GameBoy, NES etc.
Guys, you can get 20% off of The Witcher 3 on if you happen to own Witcher 1 and 2 (regardless of where you bought the games). 15% off if you own one or the other, and 10% off if you own neither. The best deal tallies to $48 USD for the game (€35.45 EUR, £28.29 GBP).

You get a completely DRM free game (looking at you steam), and you get the entire Neverwinter Nights game (diamond edition, so all of it's DLC's) and all the other goodies that come with Witcher 3 (soundtrack, art, map, etc). Look, guys, this is easily the best deal I have seen ever in my gaming life. This is unbelievable in scope, cost, and freedom. This makes companies like EA weep; this is marketing that we are unlike to see until the next big CD Projekt Red game comes out. This is without a doubt the holy grail of all promos... and I don't know how long it will last. But I'm going to purchase it soon. Too bad the game comes out in Feb. 2015, I'll have to wait exactly 8 months. But it is so worth it.

Get it while it's hot! (I otherwise don't normally post about deals I see online).
Site Comments / Hello?
Place is barren for a while now... Where is everybody?

I have a job now and don't have a lot f time for Sphere. I also am playing a lot more games now to relax instead of writing code when I get home. :P

So, I don't know when my next Sphere contribution will be.
Guys, so I've been off and on for the past two weeks because my brother and I came up with this crazy idea of creating an online database of video games. Sure there are similar sites out there but we feel that they don't do gaming culture justice. So, my brother and I set out to use the latest web technologies to try and make it happen. Here is our current progress report.

We believed that presentation, readability, performance, and navigability are key. So, I implemented a breadcrumb, the ability to view games by series, game identities via a 180*180 sized tile that represents the game, and so on. What I wanted was to personalize the vgdb to each individual game, and to you. The website is going to be heavily media-driven and I'll need all the space I can get to store the data. I'm expecting to use 80GB';s by the first year and 512GB's by the end of it's third or fourth years. It doesn't sound like a lot, but god knows how it will be used by it's members, I can easily see terabytes of space once user screenshots and videos are added to the mix (hopefully sites like youtube can reduce the load).

The end result can be spectacular. This website was not made for older browsers. It is however fully responsive and can work on mobile smart phones.

The site is still largely incomplete, there is just so much to work on it can get overwhelming. Each game page is specially curated, and I'm hoping on making tools for the community so people can get their hands dirty in editing the content. I didn't decide to use a CMS because I wanted full control over the data and how it gets processed, plus I'm running a different stack utilizing a different set of technologies.

If you are web-knowledgeable then here is where things get interesting. The website is ran in pure JavaScript. There is no PHP, .NET, or Java to speak of. It's a server stack called the MEAN stack. That means I use these technologies: MongoDB for the database backend which basically stores items as JSON. The benefit of this is that the data can be stored however you want. (Don't worry it's schema-able, so I can define a normalized data structure for each document collection). E is for Express the Node-ran Server side routing engine. This allows me to define a RESTful Api for data modification and collection by the client. A is for Angular a client-side templating engine. Now, don't get worried about that, in fact Angular is good for sites like this whose content often changes and is loaded in dynamically. A client-side templating engine means less overall html is loaded all the time, and less work that has to be done. Also, Angular makes sure there is a very small template to load, and all of the rendering logic happens on your computer, which is peanuts to render rather than the server to render for everybody (even with caching!). And finally the server is Node.js. Yep, for better or for worse this is what a pure-JS setup looks like. There are no hits casting between some other language and JS, by keeping everything to one lean setup I'm hoping the site can be fast, responsive and most importantly scalable. All these technologies claim to be scalable, and I'll try to put that to the test.

I'm hoping to someday run a kickstarter, but I'm uncertain. My father wants to me to get a job, but what if... this becomes my job? I was hoping to add features to it so at some point a user can have a power-account that grants them access to more features/increased bandwidth for uploading screenshots or videos of their favorite games and even get featured on games pages. It's still a long ways off, but what I'm hoping is that my prototype (designed by my brother, and coded by me) will get us somewhere. Plus ad revenue, that's always a consideration (even if disliked).

You can't demo it right now, it's on localhost and I don't know of a web service right now that I can trust and run both my custom server setup and host my data. I'm likely going to run my own server, or when the time comes to find a home for it (meaning I'll need to factor in external server costs). So, tell me what you think? Am I going crazy???
I tried making in-game screenshots in Sphere 1.6 a few weeks ago, by hitting the usual button (F11), but something strange happened. I just found out today, by running WinDirStat, that on my SSD, PNG images took up 4.3 GB's of space on my computer. It points me to one large folder in particular, the Sphere screenshots folder.

I check it out and it has over 132,600 files in it weighing in at 3.90GB's of space. It seems every few milliseconds a new image was added, judging by the filenames. (Screenshot attached as proof). I didn't notice this work-load on the computer at the time since the game still ran at 60fps, and since it's an SSD the file writing must have been damn fast (between 10 to 20 ms). My SSD is only 120GB's, and so space can be precious. So, I'm glad to have found this nice chunk of data to happily delete.

So, I guess you don't use the screenshot feature in 1.6, or this could happen to you! This is not the first time that happened to me. It's like the third time. What's strange is that hitting the screenshot button in 1.6 usually does nothing but sometimes this happens... (I sometimes hit F12 when going for F11).
Site Comments / Redesign of our Games Database
Possibly even a redesign for this Website in it's entirety.

So, guys, I've been playing around with Angular.js and I have made a really nice website for finding your favorite games. I made this for my personal website and I think I can expand this easily to include all games made for Sphere.

Website is here:

Angular.js made the above possible in only a few dozen lines of js and annotated html. It's really a miracle-worker in terms of programming your website. I have tags, a database, pagination, images, plus soon the ability to link into a personalized game page. What do you guys think?

How to use:
Click on tags to filter to the genre/tag of the game. Use the searchbar to do '*' searching on everything within the designated tag. Click on the tag on the search-bar to remove it (it'll highlight red).

Planned feature: a quick download button off to the side of each entry. Multi-tag searching.

The current games database exists as a JSON object, like this:
Code: (json) [Select]

[{"name":"Blockman", "desc":"fghfgh",...}];

I guess it wouldn't be hard to make a moderator-level entry view in angular so moderators can input games straight into the JSON db through a web frontend. It's so small now I've just been manually adding entries to it.

I am using my link.js library to do lazy evaluation on pagination so I don't have to splice large datasets. I feel like it makes things faster. <shrugs>
Sphere General / No more vsync
Have you guys ever ran into the problem where Sphere can no longer vsync? I have the option turned on but I still see screen-tears. Furthermore, under vsync the fps usually drops to 60, but on my computer it's just not doing that. I don't know why it's not working. Any ideas?
Off-Topic Discussions / MOVED: The Wiki
This topic has been moved to Site Comments since it fits better there.
Programming / Neat game making program
So, the guy behind the bfxr tool has made something really cool:

It's a game engine and custom programming language (which must use predicate logic) to build the rules for a video game. I think that is a rather neat concept! Data representation is a really big concern in anything AI related and using a sound representational system like predicate logic, is a very neat way to do something like this.

Check out the how-to here to get your mind shattered: