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