Tuesday, March 13, 2012

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

Saturday, March 10, 2012

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.



Monday, March 5, 2012

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

Thursday, February 23, 2012

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

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)):
  • 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.

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.