SpaceThreat updated

Just a quick one to let everyone know that the "Wannabe Aliens" experiment has been updated to use the most recent version of KineticJS and the CDN has moved to github.

You'll find the demo page here:

I'm pleased that the minified version of the game is under 20kB... I'm also happy with the new JavaScript workflow provided by RequireJS and Almond. It makes it easy to keep your code-base and deployment-strategy unified-yet-separate.

My previous workflow relied on many custom tools, and by the end, an update to the minified served version required about 10 minutes of tinkering. Now I just need to run the build scripts and push to gh-pages. The process, once set up, takes around 30 seconds. That makes it an order-of-magnitude quicker at deploying changes across all clients. That is the difference between "Urgh... I'll do it just now" and "Lemme do it now quick".

Game-play concept for Rogue-Like project.

EDIT(7 July 2013): Code moved to github: https://github.com/zskilz/manband
github.io page not up yet, sorry, been busy. To play download the zip and open manband.html in Chrome or FireFox (Requires webGL).

Ok, so making a fully fledged Rogue-like in three weeks was a bit unrealistic... but considering I didn't know three.js when I started, I think I did ok, though unfortunately I'm one day late on delivering something playable (on Chrome at least).

Here is what is missing, or buggy, from the game-play experience:

• EDIT: Firefox, weapon sprites not showing... 
• There is a bug where the  bites from small zombies are ineffectual - I know why, and I will fix later.
• Inventory management. 
• The ammo indicator needs a reload display to let you know when you can shoot.
• Improved passive AI to help avoid structures.
• Flocking, for group behaviour.
• Group commands with the right click.
• A proper map with multiple arenas.
• Game events - for dialogue, death-screens, etc.
• Help screen with legend.

The graphics are very debug, but I make no excuses for this... The focus is still game-play. I will only focus on polish once the game-play is to my satisfaction. 

So there you have it. Deadlines are silly, and silly people like me always tend to over-estimate their abilities. To complete the above list I now guess would take maybe another week... but then again it could be two, or three!

Quite a bit of work went into this project so far, and if you cruise the code you'll notice that many parts are still in development and left dangling uselessly, hoping to be used soon. So, much of what you don't see, has some place-holder code waiting to be implemented... but then again lots of code is just plain not there yet.

Next up: As a priority, I will do some bug fixes, and add any improvements to the inventory system since currently the weapon with the highest damage points gets automatically selected, which means that you need to reload and try avoid some pickups to try others. Also, a reset button is desperately needed.

After the important fixes, I suspect the pace of development will slow down since I need to spend more time on polishing my personal website, and to focus on getting possible financing so I can hopefully make games for a living...

Anyway, go check out the game-play demo here

That link again: https://github.com/zskilz/manband

Game challenge 2 update.

TL;DR: My grand Rogue-like game idea is turning into a zombie shooter... NOOOOooooooo!

I've bitten off more than I can chew and as of today, I broke the combat system, the loot system is in a primitive state, and the team artificial intelligence is, well... let's just say you can't call it intelligent.

I'm busy fixing the combat system to be more projectile friendly... If I don't get it to work I can fall back to the melee-only system whose implementation I'm not happy with. I aim to have a playable demo up on monday, but it will be the equivalent of the 1st week of the 1st project in terms of being presentable. The focus will be on core game-play concepts.

The following sacrifices will have to be made to the great deity of Keeping-timely-dead-lines:

• Player vs. world only - the AI is still too dumb. 
• Loot will be kept in it's primitive fps-pickup style of functioning... and since it's single-player, no point in rushing the team loot management.
• Since the AI is dumb, you going to have zombies, because zombies are dumb... sorry.
• If any other characters appear, they'll be about as bright as the zombies.

There is currently a nice fluidity to the game-play I hope players will appreciate; in spite of the lack of inspired  graphical representation.

Something completely different

TL;DR: The new project is coming along... one week left!

So, I'm getting along with my Rogue-like project which is currently consuming most of my time. Things are looking better but the game-play isn't near the point where a public presentation is wise. The initial set of characters will be tiny and you can expect about four types of weapons and three types of armour as loot. Coins might make an appearance, but only as upkeep for your army, acting as a pacing mechanism to add urgency. The upkeep rate will also be proportional to difficulty level.

I have settled on microphysics.js to temporarily provide dynamics. I will need more time to properly research physics library options for html5 development. The options are varied and solutions that use CPU or OpenCL acceleration would be preferable.

Anyway, there's the work-in-progress screen-shot and I apologise because it isn't very pretty :

The brave adventurer surrounded by dogs.

Progress on Rogue-like with working title "manband":

• Adapted terrain example to generate the arenas using Perlin noise. (I'd like to spend more time in a future post on this...)
• An arena can be defined with a small set of parameters, enabling random generation or defining tile-sets in a JSON file.
• Basic character class with RPG-related stats.

What's next?

• microphysics.js sphere/AABB limitation limits structure placement to axis-aligned orientation only. 
• Terrain dynamics will have to be faked - abstracting dynamics to spheres-on-a-plane and setting the sprite heights directly from the terrain's data.
• Character dynamics and passive AI.
• Loot management.

I plan to use dat.gui for tweaking character parameters during testing and for the loot management system.

Till next time...

Graphics test.

TL;DR: Canvas character sprite experiment here.

Since I haven't set up my server to properly serve the compiled JavaScript as static files yet, I'm not getting any 304 codes when serving my JavaScript files. This is a problem since the above demo relies on three.js, which takes up about 200kb (webGL+Extras)... Quite a bit to load, and I should really get the compiled files in the right place on my server so they can be loaded statically, and give a 304 if a cached version is found on the browser. This will mean only the first page load will be slow. Consequent loads will be much quicker.

It's also for this reason that I would not dare include the script references in this blog, since it would just slow down the loading of the blog way too much.

Anyway, go check out my experiment.... It shows what any Rogue-like needs... lots of character(s)! Ha ha, ha... ha.

A warning to other programmers writing graphics tests: The problem with writing graphics tests is that they can become quite hypnotic, and if you're not careful you can spend almost as much time staring at it like a mesmerized fool as you do actually implementing it...

Game challenge complete!

TL;DR: I made a derivative "game". W00t!

Hello. Below you will find the completed game challenge. CLICK ON IT TO START THE GAME. Use left and right to move, and up to shoot. Press "Esc" or click anywhere outside the game to pause. Click the "RESTART" button to reset the game.

EDIT(2013/05/13):The Audio has been fixed. Code moved to my github account. Fire-Fox doesn't appear to automatically cache the tentacle drawing so I will still need to optimise that to increase frame-rate in Firefox. Chrome frame-rate is good.

So, I managed to achieve my goals in the allotted time, and I even managed to get it to run in a blogger page.
You might notice that the prototype post is gone. This is because I had to remove it. It wasn't written to play well with other game scripts on the same browser page (i.e. the default blog view when people visit.). It hijacked your arrow keys for the whole page, which is not acceptable web-app behaviour. This version behaves better, and pauses/mutes when you go away from it and only captures your keys after you click on it. It would be a good template for me to use to build future browser based games.*

Many features one might expect from a proper game are clearly lacking in this game. This mini-game does not provide a full-game experience, but rather is aimed as an interactive replacement for a web picture, since the whole game-code is just under 50kb non-obfuscated (not counting the libraries, of which jquery will be cached on most people's browsers, and kinetic.js which is about 40kb). All geometry and audio resources are created on-the-fly, i.e. no pictures or audio get loaded, they get temporarily generated on the client machine. It represents an experiment used to learn some new technologies, and is only the first in many (hopefully).

If you care to know some technical details and credits:
I used kinetic.js library for canvas management and jquery.js library for event stuff. I ended up just using the vanilla Web Audio API implementation for Chrome build 10.0.912.77 and it gave me no hassles. In fact, I had such a blast with it I hope all browsers will have native implementations of the Web Audio API soon! If you don't have Chrome, you should just not hear any audio (sorry).

Thanks to html5canvastutorials.com.
Thanks for your interest, and please leave comments if you have questions or suggestions.

Game rush

TL;DR: I'm starting on a simple html5 game project.

I've decided to make a series of mini-games aimed at html5 compliant browsers. Each game will have a personal goal in familiarising myself with some key html5 technology or support library (like three.js). 

Ok, so here goes. The very first game concept "art"  is for a very derivative game called "Invaders from space! OMG!". It's a working title...

You control the TOSPOT (Tank Of Space Protection from Otherworldly Threats, or whatever other rude sounding anachronism I can think of before I make the game), your planet's last line of defence against the unknown dangers from outer space. The antagonists, being beings from outer space, are clearly more technologically advanced than you and their nimble frames can effortlessly evade your every attack. On their slow, meandering (yet evasive) path down to the planet surface, they shout admonitions and insult your inferior technology. The twist is that the invaders from space, although rude, are peaceful and just want to give you a group hug.

The end.

The personal aim of this project is to familiarise myself with the web audio API defined for html5 and to brush up on the html5 canvas element. This game will be 2d and I'm setting a deadline of 2 weeks for implementation. Let the challenge begin, tomorrow! (I mean, it's Sunday... you seriously expect me to start working on this on a Sunday?)

No pretty pictures here, please move along...

TL;DR: I made a sound from within the scripting environment, and it was hard!

Disclaimer: programmers only.

It has been almost a month since the last post and no "visible" progress has been made...
Lots of code have been committed for the purpose of making a couple of extra lines of script work.

Basically, I had to write an interface class for an abstract "sound module"... which is something with an internal audio buffer and references to inputs and outputs to other sound modules. Script interfaces had to be written for connecting modules together with logic to detect any feedback between modules. The only sub-classed objects so far is a master module, which abstracts the "default" audio output device, and a Stk Instrmnt wrapper class.

When I designed for using Stk, I planned around the Stk base interface classes as much as possible, and being obsessed with the sound module idea I settled for the most common audio processing virtual function shared by all higher level Stk interface classes... namely : StkFrames &tick(StkFrames&frames).

Since this most common tick function processes a block of audio frames, I thought it best to have the algorithm which processes the audio frames in as large a chunk as "real-time" permits... Stk defaults to 512 frames, which at 44k1Hz equates to about 11ms (good enough for games!).

Wasting of time, feeling stupid and doing more work than necessary happened when I decided to design for feedback support after already having "chunk" optimizations in place.

What am I talking about? Say you have an instrument which you plug into a mixer. That mixer goes through an EQ and into a splitter. That splitter then has an output to a chorus effect and another to a re-verb effect. The chorus goes to the master output, but the re-verb goes back to the mixer the instrument is plugged into. Why do you want to do this? Well, why not? It might sound cool... who knows, but the point is you might just NEED it somewhere.

The problem is now apparent since it is clear that the mixer's second input is dependent on the output of some later stage which is in turn dependent on the mixer's output. The best you can hope for in a digital system is to allow the mixer to do a single frame's tick, propagate that tick though all modules until you update the module the mixer input is dependent upon which will then serve as the input to the mixer's next single-frame tick operation.

So, if like me, you went ahead optimizing for chunks, and then wanted to go and have a special feed-back case which just does single ticks, then you're probably also half-wasting your time (I'm sure it's possible, just probably not with the way I went about it.).

What I kept from this misadventure was just the ability to detect if there is feedback when a connection is created, and throw a script exception if so, not allowing the connection. A lot can be done still with just feed-forward modular audio networks, so apart from the wasted time, I'm not too bumbed.

So, I now have the master module which is the entry point for connection to other modules and the Stk Instrmnt wrapper  (which currently supports all the sub-classed instruments Stk has to offer). Further sub-classed modules still need to be added to complete the whole sound experience, but the minimals are coming together nicely.

The basic functioning of the audio engine is like:

• audio callback requests buffer
• audio engine processes the master module
• master module processes its source modules recursively

...still not noticing any non-stupidity-induced breaking sound artefacts, so all is still well and real-time(ish).

Hopefully the next update will have some video with "actual" sound. In the distant future, I hope to re-visit the modular feedback issue. 

What have I been doing so far:

The video shows the summary of my progress on my ECMA-based 3d engine called "ThingMaker" (for now).

It is not impressive to look at for some reasons. You're seeing a early-stage, work-in-progress debug-render of a series of tests, so there is no attempt at aesthetic appeal... The screen recorder program slowed the frame-rate down considerably... I had to compress it a lot cos my up-speed is very slow... This site's video up-loader compressed it even more... So, that's why it is so ugly.

The video starts with the engine initialized. Next I run the test script. Everything in the video is dynamically created via the script environment. There are some script-defined geometries(floating shapes), some physics objects drawn in lines(the pool table), and physics shapes with dynamically created geometries(the reddish shapes with lines around them).

The tools used to create what you see: Qt framework, Bullet Physics.

Behind the scenes:

• Script binding of basics of the Bullet API (no soft-body or constraint support yet, and only basic convex collision shapes supported).
• Script binding of OpenGL 3.3 geometries and shaders.
• Script definable collision callbacks.
• C++ interface for physical controllers, or they can be defined in script. 

...but it is still in its beginning stages. I still require rudimentary audio support in the script environment and some simple GUI elements before I can make a rudimentary game (yeah, rudimentary games with OpenGL 3.3 support, I know it sounds like a joke, but it is part of a "plan"). I left these for last since I know Qt has enough support functions to make this easier than integrating Bullet and getting OpenGL 3.3 core profile to work properly... I hope.

Much work is still needed on expanding Bullet API support and replacing the rudimentary render list with a proper scene-graph... also, only debug builds are currently maintained and the deployment strategy is somewhat flawed. I'll save that for another post entitled : "the ways in which I waste effort"...

Welcome back.

Long ago I was part of a game development house, working as the tools programmer. The work was satisfying, but I had to leave due to financial constraints. Over the past decade I have made many attempts to make games while working "real" jobs. There was always some reason why I couldn't finish making a game - time constraints, job stress, me being an idiot, lost hard drives, technology passing me by...

This February I made another attempt. It has been 9 months of in-between-projects work and I've finally typed up enough code to resemble the beginnings of a script-capable 3D game engine.

Still no games though... but they are coming... oh yes.

The intention of this blog is to share any progress I'm making and to discuss some of the thoughts behind some design issues I might need to get out in order for me to understand myself better.

Mostly though, I hope that sharing my progress will serve as motivation for myself to get the project done and start making some games!