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

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.

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 

What went wrong this time? (Adventures with STK)

Sorry, no pretty pictures in this post... Also, this post is moderately technical in nature, so browse away now if you are not interested in audio-programming jargon. You'll be happier for it. If you know Qt and STK well, you might find this post slightly amusing. If you are new to Qt and STK, you might not know what I'm talking about at all. This post is personal, I guess.

I've made the first steps for physics, interaction and graphics, and since I'm interested in making desktop games, it is only natural to do audio at some point...

I thought it would be easy to integrate Qt's audio functionality when using the qmake tool-chain... add qtmultimedia to the config in your .pro file, and include a QAudioOutput class somewhere and trigger sounds from that... Right?

Well, it kinda is... but not really... QAudioOutput is a reasonably low-level interface class and can read from a custom QIODevice derived class (pull mode, good for streaming... limited real-time application) or you are provided with a QIODevice which you can write to once a notify interval has elapsed (push mode... more real-time).  A QIODevice "talks" in raw bytes... so either way you still need to take care of formatting your audio data correctly to match the stream parameters (code for this can be seen in the Generator::generateData method in the Audio Output Qt example ). Also, no mixing/routing functionality is provided... you're expected to implement that or use some third party library like STK. So, although the QAudioOutput class provides a solid cross-platform starting-point, it still requires you to implement a lot of the low-level, broiler-plate, byte-array, endian-conscious code. Also, this part of the Qt framework is under active development so it might drastically change  in the main Qt distribution as projects become merged into it. It is inevitable that technology will pass you by... but it is all part of the learning process.

For a while I've wanted to use Perry Cook & Garry Scavone's STK (https://ccrma.stanford.edu/software/stk/) to provide the basis for a soft-synth audio framework for my game engine. As a preference I decided on RtAudio and STK over PortAudio and CSound, though I know much is interchangeable and CSound has a great deal more features. I was drawn in bySTK's well balanced compromise between latency (#1 consideration for games), footprint and readability.

The aim was to have an audio engine class which gets instantiated along with the script environment, which would also provide script interfaces into a range of STK classes and to dynamically connect them in a modular fashion... Since STK can be compiled without RtAudio dependence I though it best to stick with the QtMultimedia module since I was relying heavily on Qt already.

One can conceivably tie STK's non-real-time build in with a push mode implementation involving QtAudioOutput, but, after wasting much time, in the end experimentation with RtAudio  made me decide to use it instead of QtAudioOutput. The biggest factor for me was that RtAudio already deals with floating point samples and transparently does the conversion to raw audio for a wide range of audio formats. Also, it has a relaxed open source license and is cross-platform (Linux/Mac/Win). My DSP courses dealt mostly with audio signals represented as numbers in the range -1.0 to 1.0, so RtAudio is a more intuitive fit in this regard also.

On the plus side, choosing RtAudio over QtMultimedia also provided the additional ASIO support in windows ( although ASIO support is compiled and tested, I'm  defaulting to dSound on Win32 platforms for now) and RtMidi cross platform MIDI IO support ( which has also been compiled in but is waiting untapped). The STK source files have been statically incorporated into my project not because I planed it, but because I was initially only using some elements of STK... Eventually all of STK source got included. I might eventually move back to just linking to the STK library. Right now I don't care much because the code footprint is small and all the STK classes are pre-compilable, so they don't affect consequent compile times much (exception is lesson 1).

Lessons learned:

1. Complacency can make you forget the classics: Changed a define in your project file? CLEAN! REBUILD! (And don't forget the cleaning part. Too embarrassed to say how much time I wasted dealing with puzzling bugs after forgetting to do this).
2. RtAudio's closeStream() method should never be called from a destructor of a class your RtAudio instance is part of... safer to have a pointer to a RtAudio instance which you manually delete after step 3.
3. You need the "bool done" tick-data element you see in all the STK code examples... no escaping it if using the tick() callback functionality. In the main tick() callback check for data.done and return -1 if it is true; The audio engine class destructor should set the "data.done" value to true and should sleep for a couple of microseconds to allow any pending callbacks to return a -1... only then is it safe to delete the RtAudio instance without a hang (on my system at least).
4. Building STK with Qt(Qt Creator/qmake) MINGW: If like me, you added all the stk/include and stk/src files to your Qt project, you'll need to add some defines and library dependencies to your .pro file to get everything linking and compiling right. To get the compiler setting and project defines for STK, run STK's configure script from within a msys shell to generate a makefile. Reading this makefile will tell you what defines and libraries you need to add to your Qt .pro file (you can also look at the VC project files that come with STK but it is more verbose and the linker syntax is different). 

So, what do I have?

Not much really, just getting everything compiled together and first steps of simple integration for now. Tones are generating; instruments are playing; filters are filtering; effects are effecting even... but only C++ tests hacked into the audio engine's initAudio() method for the interim. The initial tests show promise. No audio script interfaces or script definable modular flow graphs have been implemented yet... that is next.

I still have a lot to do with the sound-programming before my next update... sorry, I know I can ramble sometimes. This post went on for longer than intended.

Useful links:

• http://www.mingw.org/ (msys doesn't come with Qt Creator installer)
• https://ccrma.stanford.edu/software/stk/ (STK Home page)
• http://www.music.mcgill.ca/~gary/rtaudio/ (RtAudio Home)
• http://web.mit.edu/carrien/Public/speechlab/marc_code/ADAPT_VC/rtaudio/doc/html/ (MIT RtAudio Tutorial)
• http://www.music.mcgill.ca/~gary/rtmidi/ (RtMidi Home)

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