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...
Thursday, February 23, 2012
Monday, February 20, 2012
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)):
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.
For now, implementation details and plot details will be held back until I have more to show.
Friday, February 17, 2012
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.
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.
Wednesday, February 8, 2012
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
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
Sunday, February 5, 2012
Game challenge complete!
TL;DR: I made a derivative "game". W00t!
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.
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.
Friday, February 3, 2012
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:
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:
Subscribe to:
Posts (Atom)