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

Bump in page-views.

TL;DR: Some people came to look at my blog, and now I'm blogging about it...  yeah.

My blog received a welcome boost in views when kineticjs referenced my first personal game challenge which used their library... Thank you kineticjs.

What this whole experience has opened my eyes to is the power of market-specific references. Being referenced on a site that deals with specialist information attracts a considerably larger audience than posting about it on google+ or facebook if you're not known in your field.

Meanwhile, in unrelated news...

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

New game challenge...

TL;DR: I'm starting a 3d web game Rogue-like project. OK, no pictures, you can go away now. :)

Next stop, 3d and more complete game dynamics. The previous release was a retro-inspired title, so it is fitting that we continue along that vein, but this time on a more serious note. This project will tip its hat at all the Rogue-likes out there...

The great thing about Rogue-likes is that you can still get away with using ASCII characters, and by providing a text description, you can convince a player that a "@" character is a human. I've had the experience of playing Dwarf Fortress for 2 hours where I would imagine a dog instead of the "d" character actually running around. Reading a book has a similar effect. Your eyes sees words, but you imagine worlds.

But I'm not just doing it for the snob-appeal, it also allows me to develop a game-play experiment without having to expend massive amounts of energy on modelling lots of items and characters, but rather focus on the game-play and game-dynamics... and attempt to do so in under 3 weeks.  It is also for this reason that I believe concept art would be pointless for this post. ;)

Project brief (Man-band (working title)):

• Rogue-like 
• ASCII character sprites to represent creatures
• Simplified physics using box2d-js
• 3d environment, though all character interaction and AI will happen on the horizontal 2d plane
• no enter-able buildings, all structures effectively block or spawn creatures.
• Game-Play:
• Real-time (possible turn based option, but not a priority)
• all action is top-down 
• aswd/arrow keys to move. (Relative and absolute options)
• mouse to aim and attack. (full-screen, but no need for pointer-lock API)
• troop commands:
• assign to/select squad
• move to (move to selected spot -behaviour affected by hold/free)
• hold/free (stick to formation or chase enemies for a certain radius)
• rejoin
• chain commands.
• Game-Dynamics:
• Simplistic revenge plot with minimal dialogue and lots of fighting and looting.
• Simplified statistics and items (no magic/acid/flame/etc... just physical damage)
• Arenas represent basic location blocks. The player moves his troops from arena to arena to progress.
• Creature generator structures in arenas will cause creatures to be spawned. Creatures will also periodically spawn in neighbouring arenas. You need to destroy  generators to stop the spawning and gain loot.
• Game progress involves clearing arenas of enemy creatures, saving people and recruiting followers and arming them with loot. When you have enough stats, weapons and followers you can take on the boss arena, upon whose clearing the game completes.

Agreeably not a unique idea, but I hope to implement it so the game-play will be satisfying despite the lack of "real" graphics.

For now, implementation details and plot details will be held back until I have more to show.

Javascript hosting site up.

TL;DR: I have a new site up which will serve my game scripts.

The site is hosted here: http://zskilz.webfactional.com
The first demo is available there: http://zskilz.webfactional.com/demo/1

Also, the "Game challenge complete!" post now relies on properly importing JavaScript from this site, rather than having to paste JavaScript into the blog post. This means I now have one place where I can apply my fixes. Fixes will be reflected in the games in my posts without any extra editing of the blog.

The site, though not impressive looking yet, gives me the ability to define JavaScript bundles : usually a collection of scripts written for a game I've finished working on. The bundles get concatenated and served as one big file which can be included in a script tag.

This provides me with a more flexible deployment strategy for free games. The site will also serve as a portal people can possibly donate to or purchase from in future.

My next focus will be on a 3D mini-game, to be announced on Sunday.

Pointer Lock API means more input for your mouse.

TL;DR: FPS mouse input soon to be natively supported in Chrome browser.

Scheduled for release with Chrome 18, comes the much over-due, [plugin/Java-applet/NaCl]-free, ability to make games for the web with FPS style (or custom) mouse input.

Firefox has an event intercept hack to allow control of the mouse pointer. Up till now, that has been the only plugin-free way to provide FPS style mouse input for a web app. Cross-browser solutions required a Java-applet or additional plugin to "capture" your mouse input. Hardly ideal solutions. A new W3C draft proposal, the Pointer Lock API [1], hopes to standardise this issue.

 The Pointer Lock API is for mouse input what what input.focus() is for keyboard input... It "Locks" your mouse pointer in place, limiting pointer movement to an area, ensuring the pointer input stays relevant and doesn't go off the edge into another window. Mouse movement values (not just co-ords, but the mouse deltas also) will be included in the mousemove event. This combined with hiding the cursor is what is required to code FPS style input (amongst many input schemes) for your app.

Since this feature is ripe for abuse, the specification demands that the user is first asked if they want to lock their mouse. The lock can be released by pressing the "Esc" key. The "Esc" key event would have to be promoted to a top-level browser event whose default action cannot be prevented.

The discussion about abuse is moot I feel. The HTML JavaScript "window" object allows you to resize and re-position a browser window arbitrarily. So whatever abuse a mouse lock feature would enable has already been enabled by the window API - remember "Rick Rolling"? (a video played a particularly annoying Rick Astley hit and any attempt to close it was prevented by the script simply moving the browser window away from your franticly flailing mouse pointer). The fact is sites that chose to exploit that feature in an abusive manner only got visited at most once. It might be good for a gag, but you can only fool them once. Also, the Pointer Lock API at least has the "Esc" hatch, making it safer than the existing window API anyway. And since the pointer can't go outside the locked area means the script can't go clicking on other windows.

Have a  look at the html5Rocks article for a more technical overview [2]

Links:
[1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
[2] http://updates.html5rocks.com/2012/02/Pointer-Lock-API-Brings-FPS-Games-to-the-Browser 

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.

Battle of the audio APIs

TL;DR: Native Web Audio API is better if you're making games.

Which is better? Google's Web Audio API [1] or Mozilla's Audio Data API [2][3]?

 Well, actually that is not a question which can be easily answered since the two, though sharing some use-cases, are quite different. Also, to emphasise the difference, Mozilla's Audio Data API specification, officially since 15 December 2011, falls under a more general "MediaStream Processing" API specification [3]. Just browsing the two specifications will show you that they are quite different animals and that the Web Audio API specification is currently more mature (less likely to change).

To really get at the core difference between the two APIs, known that Google's Web Audio API can be,(and has been [4]) implemented in JavaScript using Mozilla's Audio Data API. So, immediately it is apparent that the Mozilla API is a lot more "low-level". That is, it gives you some core functionality which allow access to HTML "audio" elements' internal data. The specification, now more generalized for "MediaStream Processing", also allows for access to HTML "video" elements' internal data.

So, the specification championed by Robert O'Callahan and Mozilla is great for managing media assets, and performing streaming, extracting, injecting or mixing operations on raw data from audio and video elements. Microphone input would be considered a media element under this specification. The big use-case will be for in-browser video-conferencing or web-casting applications.

What is the Web Audio API then? It allows the user to build complex audio graphs, place sound sources spatially (including features like Doppler effects and HRTF ), trigger sound sources in a timely fashion, and comes with a set of pre-defined filters and effect generators. So, everything you need to make a soft-synth or a computer game's audio.

Now, since you can implement Chris Rodger's Web Audio API specification on top of the Mozilla specification in JavaScript, why have native support for it? Answer: Performance.

A JavaScript implementation of the Web Audio API, though functional, will run much slower than a native implementation. When making a game, you need processing time for game logic. You don't want CPU cycles tied up performing a set of computationally expensive convolution operations in JavaScript. Also, since the API is only a specification, a good implementation can hand off processing to hardware accelerated back-ends (e.g. on a Creative EAX card), or a browser maintained audio thread to help boost performance. For a complex scene with many filtered and spatial sound sources playing simultaneously, like in a game, you'll need all the performance you can get to keep the user experience responsive.

 Also, since the audio sources in the Web Audio API are easy to fill with custom buffers, there is little reason why both specifications can't live side by side. AudioContext's MediaElementAudioSourceNode method seems like a move in the direction of inter-operability between the two specifications. The  MediaStream  API can manage audio streams between peer-connected clients while the Web Audio API "renders" the received data in interesting ways.

So, in conclusion, for me, there is no battle, though I personally prefer using Web Audio API since it is more geared toward the game use-case. I hope that both specifications are refined to be more complementary and get accepted and endorsed by W3C [5].

 Links:

• [1] http://www.w3.org/TR/webaudio 
• [2] http://wiki.mozilla.org/Audio_Data_API 
• [3] http://www.w3.org/TR/streamproc 
• [4] https://github.com/corbanbrook/audionode.js
• [5] http://www.w3.org/TR/audioproc/

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?)

Change of plans... again.

TL;DR: I'm giving up trying to make an engine for now since better free tools exist already, and they're in better state than I expected. Go look at these pretty demos from other people, or go listen to these demos made by other people, if your browser supports it.

Maybe you spend all your time working on something everyone else seems to be doing, but no one quite got it right, or maybe there exists a solution, but it is out of your price range... Sometimes you could be wasting your time doing something someone else (meaning better connected groups of individuals and corporations) already did, quite a while ago, but you just didn't delve deep enough into the research to find it. And by "you" I mean me, cos that's what I kinda did. Oops. Also, I'm running out of time, and I want to be known for games, and not engines.

I was working hard on creating modular wrappers for audio sources, and most recently managed to add a spacializer class for attaching audio sources to rigid bodies. Being single minded about making a game engine I never bothered to read the W3 specification for HTML5's audioContext object which includes everything I was trying to achieve in terms of audio routing in my own project [1]. Searching for examples of implementations using Chrome as browser convinced me that I was wasting my time [2] [3] [4]. The web audio API is mature enough in Chrome to do everything I set out to do, so I might as well use it and hope that future adopters of HTML5 will provide a half decent implementation of the autioContext specification.

Further down the line, I expect that the audioContext will make its way into QtWebKit. When this happens I will gladly base the next iteration of the engine on QtWebKit to create a self-contained executable.

In my defence, time has moved on since I started the project early last year... The state of HTML5 was matured, but not complete. It appeared to have a bright future, but that future wasn't "now" back then. I don't think we're at the "now" stage yet, but it does seem close with M$'s adoption of HTML5 as an alternative application framework in windows 8.

I had a plan to develop a game engine with emphasis on a robust scripting environment. At the time I was trying to get away from web dev for just a bit. I decided on Qt for its cross-platform Win/ Linux and MacOs support. Somewhere after the Bullet Physics integration I started to address the issue of GUI. I followed the over-painting example from QT to use QPainter for any GUI text. Even later, after doing the OpenGL script interface I wondered if I could not save a lot of effort to just use QtWebKit for the GUI, since I was already well versed in CSS and HTML... it seemed natural. Round about this point I came back to see the state of HTML5 and WebGL, and I decided that for now, they are good enough for my purposes, limited by time as I am. Seems I went full circle to land back at web-dev.

Sigh.

Anyhoo, the video below shows the point my engine got to before I decided to give up making engines.. It demos the audio spacializer somewhat (STK sources get attached to rigid bodies and the mixer parameters get updated from the motion-state callback). I was about to add the delta-Position variable to the bodies' motion-state for Doppler effects, so that is not done. (Also no texture support... the colours are generated by a simple shader):

I plan to open the source for this project soon, I just want to first remove the direct inclusion of STK in the source and link to the library instead. There is some documentation, but it is mostly undocumented. All in all, though mostly a waste of time, it was a great learning experience. Don't hold your breath for the source though... priorities.

I will keep you updated on the progress of my HTML5/WebGL game development adventure.

Links:
[1] http://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#Spatialization-section
[2] http://www.html5rocks.com/en/tutorials/webaudio/intro/
[3] http://www.chromeexperiments.com/webgl
[4] http://chromium.googlecode.com/svn/trunk/samples/audio/index.html