Friday 9 September 2016

Fiverr - Make block move left and right!

So I discovered Fiverr recently. Actually a game developer friend told me about it ages ago because they use it for cheap voice over work.

It struck me that this might be a viable way to get a prototype of the game up and running. I also thought about streaming the playtesting of what gets developed live over Twitch. Thought that might prove interesting.

Anyway, for the sake of transparency I thought I'd document below my rough notes on what I initially want built.

The procedural generative elements are far from insignificant, from both a design and coding perspective - so they can wait for now.

Initially, I'd like the prototype to just focus on player movement, physics and environmental elements.

So I broke the game down into its core features and broke those down into tiny subprojects. Beginning with the most straightforward. What I love about thinking through this stuff is that it makes you consider every palpable element of your game in isolation. And it highlights potential problems with UI and control interfaces, graphical requirements, UX and audio requirements.

It is also good practice re game development and software development in general. In fact pretty much any kind of development.

If you're going to develop anything, break the concept down and consider the minutiae. I'm not sure if I'm insane or just a glutton for punishment but I love doing this, I get a real kick out of it. Truly.

Below is my first pass at breaking down the movement into chunks that could be built in Unity for the purpose of playtesting and refining.

It's not a game (yet). And it doesn't have any of the procedural generation stuff in it. But that's the whole point. To begin with I just want a prototype that excels at delivering agile freedom of movement.

Later we can think about graphical requirements, animations, textures, sound, blah blah blah....

So here goes:

It should be stipulated that this is, of course, a work in progress.


Initial components to be developed.


Basic gameplay / environment / movement:

  1. Create basic environment - the game space (arena) - just a rectangle will suffice to begin with, a pale grey background in a black rectangle with thick borders in the centre of the screen, taking up about 70% of the screen
  2. Add player character - just a green block to begin with, twice as high as it is wide.  Precise pixel dimensions to be confirmed
  3. Enable block to move left and right (‘walk’).  WASD controls to be used. So A = Left and D = Right.  (Spacebar will = jump).
  4. Enable block to jump up and drop back down (basic 2D physics should be employed at this stage).  The jump height is equal to the height of the block
  5. Enable block to crouch and move left and right in crouch half the speed of walk (later this will become ‘silent creep’)
  6. Enable block to move more quickly left and right, twice the speed of ‘walk’.  (This will become sprint or ‘dash’)
  7. Enable jump from crouch/creep (later this will become ‘spring’ an attack from stealth)
  8. Enable jump from dash (basic physics should allow the distance traversed via the jump to be greater than jump from walk or crouch/creep
  9. Add a physical property to right hand wall of game ‘arena’ - for now this can be denoted by a simple change in colour - brown.  The physical property is ‘sticky’ - it should allow the player block to climb up and down it. Pulling away from the sticky (climbing) surface disengages the block from the stickiness, and it can move away, as does jumping away from the stickiness.  Jumping up the sticky surface is allowed as a faster way to move up
  10. Add stickiness to the right hand half of the ‘ceiling’ of the arena.  Add ‘shimmy’ movement - the ability to move across the sticky part of the ceiling at the speed of creep. The block now should be able to move right, attach to the brown sticky wall, climb and/or ‘jump climb’ up the wall and then ‘shimmy’ along the ceiling.  When the block gets to the non-sticky, regular part of the ceiling it should drop back down to the ground and land in crouch.  The block should also now be able to stand next to the sticky wall and jump into it and stick in that position, going from jump to climb, starting the climb a single jump height up the sticky wall.  Appropriately, attempting to climb up a non sticky surface results in the block simply dropping back down just as it would do immediately after a jump
  11. Add a ‘half-sticky’ surface to the top half of the left wall.  This will be denoted at this stage by an orange colour.  Make the entire ceiling sticky.  The quality of ‘half-sticky’ is that the block can’t climb it, but it can slide down it at a rate half of ‘fall’ (the drop movement that occurs immediately after jump). In a subsequent arena with more angled sections the block should be able to climb/shimmy across overhangs which have the ‘sticky’ quality’ but will drop off any ‘half-sticky’ overhangs. More on this later.  The block should now be able to ‘climb’ up the sticky right wall, shimmy across the sticky ceiling, ‘slide’ down the first half of the half-sticky left wall and drop/fall (at normal drop rate) the remaining normal (non-sticky) lower half of the left wall.
  12. Create a cursor controlled by the mouse that can move within the game arena and outside the edges. The cursor should look like a simple X cross hair / reticle when ‘inside’ the game arena and turn into a regular mouse pointer when ‘outside’ the borders of the game arena. When the cursor hovers over a sticky surface it turns into an up arrow.  When it hovers over a half-sticky surface it turns into a down arrow
  13. Create grappling hook feature. (I believe there is an open source community built add on in Unity for this) The way this should work is as follows: Hovering over any section of the arena border the cursor now turns into a circle (for now - later hook icon). Pressing left mouse button (console UI will come later) will ‘shoot out’ a thin white line from the centre of the block to the cursor and attach to the inside edge of the border at that point. Moving towards the ‘point of attach’ (PoA) will shorten the line.  Moving away lengthens the line.  The line is always straight. If the PoA is above the block (in the ceiling for example) by jumping up the player becomes suspended above the ground.  And will dangle from the line automatically swaying slightly from side to side ¼ block width of movement.  Unless up or down (W and S) movement is used, the line remains the same length.  When A and D are used alternately a swinging motion begins. (I believe the grappling hook add on for Unity allows for this as standard).  Typical 2D physics should be employed to convey momentum.  Mouse 1 attaches/detaches the grappling hook.  On detach the line is rapidly reeled into the centre of the block and disappears. The aim is to allow the player to shoot the hook at surfaces (typically above the block) and reel in to slightly shorten the line and allow for swinging. If the hook is detached mid swing the momentum is conveyed to the block and in this way the block can be flung considerable distances.  To begin with the max line length is 20 blocks.  This will be adjusted as required.  Later there will be an upgrade path for the grappling hook feature. It should be possible for the hook to be fired, a swing induced, the hook detached, the block flung and the hook fired again before the block hits the ground (environment dependant of course) so the hook-swing-detach-fling-hook sequence can be repeated and becomes a possible form of locomotion without the need for the block to land in between or stop moving.  Think spider man.  If the hook is attached to a sticky surface and the block reels in and comes into contact with the sticky surface, the block may detach the hook and remain ‘stuck’ to the surface.  In the case of a regular, non sticky surface the block would drop as expected.  If the hook is attached to a half-sticky surface, reeled in and detached, the block will slide as expected.
  14. Movement speed.  Walk = 1x, run = 2x, dash = 3x, creep = 0.5x, climb = 0.5x, reel in/out = 1.5x (subject to testing and refinement).
  15. Wet floors.  A wet floor (such as during or shortly after rain) will be initially denoted by a pale blue colour to the inside edge of the border (graphics example to follow). When the block ‘runs’ or ‘dashes’ on this surface and then stops the stop doesn’t happen immediately, there is a ‘slide’ or ‘skid’ that comes before the stop, the length of slide increases based on the preceding movement speed.  Calculation to follow.
  16. Ice.  Like wet floors above but with greater slide - subject to testing.
  17. Create a different arena - specifications to follow.  This will be used to test different movement types, jumping and attaching to sticky surfaces, slides and angled shimmies, grapple attaches and swings etc.
  18. Water movement / pools.  In a new environment (details to follow) create a pool.  Use pale blue to denote the water.  Opacity 50% to begin with (subject to testing).  The block may move freely left and right, up and down in water.  But movement speed is halved.  The hook can be fired underwater.
  19. Currents in water.  In the pool described above, create a current which moves from left to right. The current moves physics objects placed in the pool (i.e. the player block) in the direction of the current.  The current speed should be a variable.  The default is walking speed.  The effects of the speed of the current on the player block is cumulative, i.e. adds to the player’s speed if they move with the current, subtracts from the player’s speed is they travel against the current.  Add a +/- icon/buttons outside the boundaries of the arena as shown (wireframe to follow).  These buttons can be interacted with via the mouse and allow the playtester to adjust the speed of the current.  
  20. Add a compass icon to screen to allow the playtester to change the direction of the water current. Wireframe to follow.
  21. Physics objects.  Add another block into the arena (details to follow).  This block can be stood on, jumped over, pushed and pulled.  If the hook is fired at it, it can be reeled in.  Whilst the WASD keys remain focused on the player block’s movement in relation to the hook, the reeling in of an attached physics object is performed by mouse swipes.  Hovering over a physics object will change the cursor to the grapple icon.  Pressing mouse 1 will fire and attach the hook to the point of contact, swiping the mouse towards the player will reel the physics object towards the player block.  Having these two forms of movement associated with the grappling hook should allow for the simultaneous movement of the player block and the physics object.  The physics object can be dragged, tugged, dangled etc.  An upgrade to the hook will allow for multiple lines and multiple points of attachment.  Controls will have to be tested.  Think Just Cause.

Let me know what you think...

Wednesday 10 August 2016

Pitfallen Facebook Group

I have it on good authority that the best way to 'get the word out there' is via a Facebook Group - not a Facebook Page.  Allegedly the latter are rubbish.  Anyway, I have both. Here's the link to the group as that may well become the single point of reference going forward regarding developments.

Best thing to do is follow, like and share everything.  The more followers we can get the better.

I thank you.


Friday 5 August 2016

Loot

A big bugbear of mine in games is mobs that don't drop what they have on them.  Let me explain.  I was reminded of this recently in The Division.  I kill a bad guy who was clearly shooting me with a firearm of some kind, and he drops, gloves, or a backpack, or a scarf, or nothing at all.  Or a completely different gun.

In Pitfallen / Underland / or 'Doings in the Dark' as Alastair Cornish (he's the Creative Director of Splash Damage by the way, and I spent a highly entertaining Saturday a few weeks back, tabletop roleplaying with him.  He gives good dice.)  In this game we're going to do things differently.

WYSIWYG loot.  What you see is what you get.  (+ a few extras if applicable, because obviously you can't tell what's in a guy's pouch until you open it up!) WYSIWYG+ I might call it - conceptually at least.

I wrote about this in a blog I used to tend about as frequently as my garden. For completeness I'll include the link - (You kill the poison turtle and it drops a magic battleaxe) - the blog in general contains some meandering, unedited insights into what I like and don't like about games, with a slight leaning towards tabletop RPG, but there's quite a lot of videogame content too. If you do click-through, don't come blabbing to me about poor sentence construction and typos, I did warn you about the lack of edit - but you might, and I hope you do, find something of interest there....

Anyway, in brief, it goes on about mobs dropping what you expect them to.  You kill a guy with a sword, you can loot his sword... and his breastplate, and his boots and everything else you can see on his person.  Depending on how he died, it might be a bloodstained shirt. You get the idea.

In the game this will be handled by loot tables specific to each creature (maybe shared amongst creatures for the sake of efficiency, and we may employ additional tables for the contents of their pouches).  That's a lot of tables you might think.  But it's important to get this stuff right, I'd counter, and anyway, if we're smart about the way we pre-load stuff, then I can't imagine it slowing the game down any.

The game will have to generate environment beyond that which you see on the screen anyway, so there's no loading time, but we probably won't bundle in the loot at the point.  I like the idea of looting a corpse taking some time, rather than the stuff spraying out in a cloud or arcade bonus.  So the time it takes to loot could be the time it takes to lookup what the loot should be.  I even have a solution for environment loading time (The Dreamscape) but that's for another post.

And with that I shall bid you good night.

Farewell sweet prince / princesses.

Wednesday 3 August 2016

Pitfallen!

As you know, Underland is a working title, Dread Pirate Booty I'm just not into. I'm considering Pitfallen.  I like Pitfallen for two reasons, 1) It's a nod to the classic 80s Atari game which I'm taking a little inspiration from, and 2) the 'fallen' bit kind of suggests undead, or lost souls, which is definitely an aspect of the game.

What do people think of Pitfallen?

To be honest, I'd much rather go with something like: What we do in the shadows (which is a great film btw! - check it out).

So we could go with something like: What happens in the shadows.  Not too keen on it though.

I'm really stuck on this, I like the idea of a phrase style title.  Any suggestions, stick 'em in the comments below!

Concept Art

So after significant delay I've finally gotten around to collating some materials for my Concept Artist, the inimitable Robin Bazalgette.

Below is an extract of what I've just emailed him.  Looking forward to what he comes up with!

______________


What needs to be shown is first a normal map, and then a rendering of that map as passageways, chambers with most of the boundaries and out-of-bounds areas blacked out or with subtle rock / earth / lost trinkets detail, and the main passageways illuminated with background features and objects and entities.

The two images need to show clearly show how the top down, plan view of one, translates into the up and down, left and right of the other.  North on the roadmap = up in the gameworld.

Roadmap capture.PNG
An example roadmap taken from google maps.
roadmap coverted to subterranean passageway.png

The above images show the original screenshot taken from google maps (obvious in plan view with up being north), and the concept of how the game will convert this to 2D side view with north becoming up.  It also indicates how notable structures like buildings will become chambers in the game.  Also the type of buildings will inform background furniture or even interactable objects.  I.e. a factory might produce a chamber with a background of cogs, with some interactable levers and mechanisms the player can activate.  These will likely be tied to nearby gates, doors, trapdoors, or traps.

I included a bunch of Limbo screenshots to illustrate what a predominantly dark, moody and silhouetted game looks like. Not that I have any intention of copying Limbo in that regard, it was more for atmosphere. Below are a few more images I have trawling the web that had a similar appeal in terms of atmosphere and general weirdness.

Disclaimer: None of these images are by me or my team, nor are they part of my game or purported to be from my game. They are purely included as part of a mood board to provide some guidance and inspiration to my concept artist.

Below are some stylistic concept pieces.  These show potential content for the actual passageways, chambers and catacombs…
nightmare cavern monsters.jpg
nightmare eels.jpg
nightmare ghasts.jpg
nightmare huge cavern monster.jpg
nightmare tree beasts.jpg
nightmare turtle hydra.jpg

And here are some potential character ideas…
old pirate dread roberts.jpg
skeleton warrior.jpg
twisted tree underground background chamber detail.jpg
underground evil tree not so silly!.jpg

The actual feeling I want to go for is something like a dark fairytale with some pirate / aquatic content as well as some more traditional Dungeons & Dragons style content.  But everything must have the overall feeling of a spooky, nightmarish fairytale.

Now I certainly don't want to copy Limbo. That was unique and special in its own way. It's included here really to illustrate the style of a game where vast tracks of the screen are blacked out.

The perspective in my game is intended to be different, rather than distant diffuse backgrounds, the only real illuminated stuff will be the content you close to. That's the general idea anyway. In this case is very much a case of let the artist do their work. They know best.

It should also be noted that none of these images are mine. They are included for informational purposes only and if copyright owners wish me to remove I'll be happy to do so of course.

Wednesday 24 February 2016

Underland is getting UX'd up!

So... just got off the blower with my friend, Joost, who wants to use Underland (working title!) as a basis for a UX project he's working on.

The first steps of which will be to develop personas so we can explore core functionality and interaction design.

Obviously nothing's set in stone - I just really like the idea of a) being able to support his UX project by giving him something to focus on; and b) a bunch of strangers sitting round talking about Underland!  :-)

Now if I can only get another 500,000 people doing that!

pilch out!


p.s. On a completely separate note, I'm not overly enamoured with the name Underland, nor its original predecessor - Dread Pirate Booty.  Currently I'm in favour of going with something a little more prosaic like:  What Shape the Night Brings.

What I'd really like however is some suggestions.  So hit up the comments with any ideas you have.  As always, bonus points will be awarded!  :-) 

Sunday 21 February 2016

If you like this idea...

Please follow and spread the word!  Tell your friends about it.  Post links to it on your Facebook and Twitter.  We're really excited about this project but need support before we can make it a reality.  This means we need your help.  

Bonus points will be awarded!  :-)