Friday, 18 December 2015

LD34 - StarNinja vs SpaceHydra


This was my entry for LD34.
The game was based on Ninja/Cowboy; the game I've been working on for the past 2 weeks.

I incorporated both themes, 'Growing' and '2 Button Controls'. Because of this the way the character moves is slightly different from Ninja/Cowboy. You are only 1 block tall and cannot crouch, and instead of different height jumps, you have a double jump. You can hover at both levels but not jump again mid hover and because of this I think some people struggled with the controls.

Normally I excel in 1 or 2 areas and do badly in a couple of areas. This time however I seem to have done just okay in all categories (It's actually my second most successful LD based on scores alone). I would really have liked to have been in the top 50 for a category though.

By the comments on my game it seems people are quite split. Some people love it and others had trouble getting the hang of it. In hindsight, the game is probably too difficult. It has finicky controls (which I actually quite like) and the only people that tested the game (Me and 2 other friends) had also been testing Ninja/Cowboy; the game this was based on, so they already had a feel for how to play.


I spent longer juicing the game with particles and animations than I normally do in Ludum Dare and I think on a subtle level it connected with people but overall I don't think players were entirely impressed with the art style.

I am happy with how the audio turned out though. I used a similar method to what we used on out teams gamejam game 'Alien Deception', where the audio overlays different instruments based on what's happening to the character. I made all the music myself this time.

I'm tempted to use this same type of movement in Ninja/Cowboy for the ninja character (and the other movement for the cowboy). If I do though, I've learned that I need to give people some time to get used to the intricacies of the movement before I start throwing loads of bullets at them.

Saturday, 12 December 2015

Ludum Dare 34 - 2 Button controls/Growing

It's a tie theme: 2 button controls & Growing
I voted for both so I'm happy but my primary theme will be 2 button controls I think. It suits my style of game well. I'll attempt to do both themes though if I can.

I sketched 12 themes but for a variety of reasons I think I'm going to try theme 2. And if it doesn't work out maybe theme 11 or theme 12. A lot of these ideas I really like so if I have a free week or so I might make some more of them.

I know how fun gun game is already so I'm using that as a base for a variation. I know I can make it quickly so I should have a lot of time to work on visuals, audio and juice.

Also, 2 birds with one stone right? Maybe it'll give me something to work off for GunGame (Now called Cowboy/Ninja)

I'm not reusing any assets or code by the way. I'll be making this version from scratch. It'll be it's own game that plays differently.

Friday, 11 December 2015

3 Week Prototype - Story Mode

This gif shows a potential tutorial level that introduces the player to the majority of movement (I haven't put any instructions in the level yet because it's actually not that good yet).

I think it introduces too many things too quickly with too much risk.

I feel like the things introduced in this level might be better introduced over 2 or 3 levels.

The only other change is the scrolling camera for longer rooms.

This second gif shows a few enemy types I've been working on.
Some enemies only shoot and reflect red bullets so have to be beaten with your own, double reflected bullet.
You can also beat these enemies if they land on or jump into a bullet that they don't have time to reflect.

There's something about this version of the game that isn't as fun as the others.
It could be the high difficulty and long stages, but Super Meat Boy had that towards the end and it was still fun.

It's satisfying when you struggle against an enemy and then pull off a skillful move to beat them.
But it's less fun when you fluke your way through a fight. Like when the enemy lands on a bullet and it feels similar when they happen to jump over a red shot (maybe only because I know that it's random when they jump).

So I think the reason this version isn't as fun is because the enemy ai is mostly randomized (shooting and jumping) and it would feel better if it was more reactive and maybe a little less hectic.

I also think if I were to shorten the levels a bit or add checkpoints it would feel less punishing to die (by what is currently RNG).


Finally, the game has and has had an annoying quirk I've been unable to fix where when you land after a jump you lose all of you're horizontal momentum. It's subtle but it makes the game feel a lot stiffer as a result.

Thursday, 10 December 2015

3 Week Prototype - Menus

This is what I currently have in terms of menus.
This version of the game contains 2 player deathmatch mode, a recreation and variation of some of the arcade modes I prototyped earlier and the start of a single player story mode.

I imagine the story mode, when the text is clicked would pan upwards into a mario-esque map.

I think my menus need a rework at some point to be honest. Personally I remember the location of the different 'areas' of the menus rather than the name if that makes sense. So I often click on the wrong text and have to go back.

Instead I think it would be better if I had the text to the left or right with an icon.

Aesthetically I quite like the idea of the menus being underground and you scroll up to overground to play the story mode.

I won't include a build in this version since menus don't really have 'gameplay' that you might want to test.

The next thing I'll work on is enemies and maybe a tutorial for the single player version.

Other things to do include:
- Reworking menus and making them work with gamepad and keyboard (rather than just mouse)
- Adding more arcade versions in (make them unlockable at some point through story mode progression)
- Art
- Remaking the entire game in UE4???

Monday, 7 December 2015

3 Week Prototype - 2 Player Deathmatch Mode

The best version so far

I know it's only been 2 days but 2 player mode has undergone quite a few revisions.
But so far things are looking fantastic.
Whenever I turn on the game for playtesting we normally spend at least an hour because it's just too damn fun to stop.

I've made a fair few subtle tweaks to the movement and collision detection. You have to program all the collisions yourself in GameMaker which can be a real pain when it doesn't work as intended. Especially since movement is so important in this game.

I had to change the bullet bounce slightly to a maximum of 2 bounces because otherwise it would become far to hectic.

GAMEPAD SUPPORT - The game now supports both a single gamepad and keyboard for the different characters OR 2 gamepads, 1 for each player.

The gamepad controls went through a few revisions where initially crouch was the X button and right bumper was shoot.
I made it this way because I figured that it would be difficult to move horizontally when trying to push the joystick down too.
However when testing quickly realized how difficult it is to play with this layout and very regularly was I jumping when I meant to crouch, letting go of the wrong button when trying to uncrouch mid-air etc.

I tried the game where crouch is down on the joystick and against my expectations it actually works quite well.

sounds are back in ^^

There are NEW WALL TYPES in the 2 player version that I'm testing out for the single player version too:

- Grey blocks don't reflect at all.
- Red Blocks kill you instantly.
- Glass Blocks reflect all bullets except for red ones in which case they are destroyed. I think they'll have a lot of potential in the single player version and for use in puzzles potentially.




I made 14 different stage variations to test out 2 player mode. You can switch between them with 'O' and 'P'.

ALSO, the player has a NEW WAY TO KILL THE OPPONENT by landing on their head.
It works very well. In playtesting I found that it caused players to risk getting closer to their opponent and it can be used for map pressure too (threatening the player back).
It's a good mechanic because it can take you by surprise but it can also be countered quite easily by moving to the side and shooting point blank.

Sunday, 6 December 2015

3 Week Prototype - Horizontal Movement

In this single player mock up, the players goal is to get to checkered door

I made the game again from scratch to more easily work with the new movement and shooting/reflecting both left and right 

I've done as much as I can to make the transition from 1D movement to 2D movement as easy as possible for the player

For example, if the player jumps whilst standing and their head would hit the ceiling, the game automatically makes them crouch until their is room for them to stand up again. Obviously if the player holds the crouch button during this time they will say crouched until it is released (and there is room to stand up)

I'm quite proud of what I've made so far. With a bit of practice it becomes very easy to make the character do exactly what you want.

I had to make the character smaller relative to the size of the screen so the player can see more of the level and plan accordingly. It allows me to make harder challenges without them getting frustrating.

I also made some challenge rooms with endlessly bouncing bullets to test quite how well the movement holds up in a sadistic kind of platforming environment. It works very well. I think this game has a lot of potential.

Download this version of the game HERE

Also I made a version where you could charge the shots to make them go faster like in 'Towerfall' and honestly it wasn't as fun so I scrapped it. 

Saturday, 5 December 2015

3 Week Prototype - SwordGun


In this version of the game, the player has the ability to shoot and reflect

Both actions are mapped to the 'X' key but the game figures out whether you want to reflect or shoot based on whether there's a bullet in range of the player

Only Red (3rd) tier bullets damage the enemy.
In this version the player will never encounter a red bullet first hand because the enemy only reflects up to orange (2nd tier).

This version of the game feels a bit more varied and there's some level of deeper strategy to it.
The sword/gun mechanic is surprisingly intuitive which is good because I hope to include it in the full game.

I have also made a version where the enemy reflects the bullets up to red (3rd tier) which essentially makes bullets that the enemy shot first impossible to use against them. However the player can still defend themselves whilst the bullet is yellow (1st tier).

To damage the enemy in this version the player must fire a bullet, wait for it to come back at them as an orange (2nd tier) bullet and reflect it back as a red (3rd tier) bullet.

Both versions are fun. As I add more complex interactions to the game, the game starts to acquire more strategy but it also gets more difficult as the player has to try and figure more things out at once.

I find the more complex versions are less fun initially but have the potential to get more fun once the player starts to feel comfortable in the environment.


This tells me that I should take a similar approach when making the game as a linear adventure.

I should introduce the player to maybe just the gun or sword first before combining them into one weapon.

The first enemies I introduce the player should be unable to reflect or maybe only non-lethal reflections until a bit later into the game.


If you'd like to play these 2 versions of the game you can download them both

Friday, 4 December 2015

3 Week Prototype - BounceBulletDefender

I've made another version of the game that doesn't really add any mechanics so it isn't directly relevant to the 'full' game but it's potentially an interesting idea for an enemy and as an arcade game it's much better.

I fixed the problem of having to wait for the right height bullet to progress

In this version any reflected bullets earn you points but the player can still not cheat the game by waiting for bullets at the lowest (easiest to reach) heights because any bullets that the player misses deducts 25 points.

The other change I made is to increase the speed after every single reflected bullet

The fire rate in this version gets very high very quickly. It definitely the most fast pace version of the game so far and arguably the most fun.

The short play time of this version makes for a VERY 'one more go' feeling.
And it never feels unfair because it controls well and the goal is simple.

I also made a version like this that uses the 3 tier bullet system again.

It's more difficult because it often puts the player in a situation where they have to make a snap decision of which bullet is better to try and reflect.

The player has to take into account the colour of the bullet as well as the height of the bullet relative to themselves and relative to other bullets which could potentially hit them mid jump.


These 2 versions of the game are very fun but my favorite is the one without the 3 tier bullets. The quick acceleration just feels really good. 

However the 3 tier bullet version has a lot more near misses and quick maneuvers so it certainly feels like a positive step up from the 1-tier bullet version.

Download the 1-tier bullet version HERE 
Download the 3-tier bullet version HERE

It's a small difference but they feel quite different to play

Thursday, 3 December 2015

3 Week Prototype - Sword gifs and arcade games

Each of these prototypes are made to test out or explain a mechanic or enemy that's intended to be in the final game but they are all very addictive and fun arcade games by themselves. You should download and play them if just for 10 seconds so that you understand how they work.

Even though though they just represent part of the full game I'll still be talking about them as if they were their own game since they can be played as such.
The gif above shows an initial test of the sword in action. In this version the player cannot shoot but they can reflect bullets with their sword. I'm just testing out the reflection mechanic here. The enemy represents an enemy which could only be defeated with reflected bullets.


This gif is another variation and shows the bullet bounce mechanic in action alongside the reflection mechanic.
As you can see, it is the same as the previous version except the enemy has the ability to reflect bullets back at the player (but not increase the rank of the bullet).

Only red bullets cause the enemy to take damage.

This second version of the enemy is more difficult that the first because it often put the player in a position where they have to figure out how to react to 2 (and sometimes 3 if the player hit a non-target) oncoming bullets at once rather than just the one.

I also think it's more fun because it requires more thinking on the players part.

The biggest problem with these 2 versions of the game is the downtime when waiting for a bullet to spawn at the right height for a target. I'd like to address this issue in my next variation.

Download the 1st version (without bullet bounce)  HERE
And the 2nd version (with bullet bounce) HERE

3 Week Prototype - Bullet Bounce and reflecting bullets

I have been experimenting with a new mechanic where instead of shooting, the player uses a sword to reflect bullets back at the opponent.

The reason I'm adding bullet bounce to the game is for consistency above all else.
Although it's a new mechanic, it simplifies the rule set overall.

How it works:
Bullets have ranks: Yellow, Orange (blue in the diagram), Red
The bullets rank represents whether it can be reflected or not

Yellow bullets can be reflected and become an orange bullet
Orange bullets can be reflected and become a red bullet
Red bullets CANNOT be reflected but they can be dodged

These rules are consistent throughout the whole game
An enemy hit by a red bullet will ALWAYS get hit
But they still give me a lot of freedom when designing enemies

In other words, after being introduced to the 3 bullet types at the start of the game, the player never has to run into more weird attacks later on.

Therefor, the player will never be in a situation where it feels unfair to die because of something they haven't been taught yet.


What I intend to do is to allow the player to shoot at will except when a yellow or orange bullet is in front of them in which case they reflect the bullet instead.






This system allows me to create enemies that:
- Enemies that never reflect bullets and therefor die from any shot

- Always reflect bullets (but not red) and therefor require a shot followed by a reflection to kill

- Always reflect Bullets (not red) as red bullets and only fire orange bullets. This means that a player fired bullet will never hit the enemy. The only way to win would be to reflect an enemy bullet or to hit them with your sword.

- Same as the above except they don't shoot. The only way to attack this enemy would be directly with your sword.

All these enemies still follow the rule that if they are hit by a red bullet they take damage
The player still follows the rule that they can reflect any bullet that isn't red and increase its rank by 1

In order to further explain how this works. I'm going to make a quick prototype for my next post.

Wednesday, 2 December 2015

3 Week Prototype - Horizontal Movement 01

This gif shows another prototype I made for the horizontal movement. I call it DashDancer after the style of movement a lot of competitive SuperSmashBros:Melee Players use; Dash Dancing.

A gif showing competitive SSBM player 'Mang0' dash dancing
Dash Dancing is to bait an attack from your opponent by moving within their attack range only to move out of their attack range before the attack hits. This allows the player to punish the opponents 'lag' frames after the attack when they briefly cannot move or attack again.

Originally I intended dashing to be the primary horizontal movement for our player
However
It actually takes quite a lot of control away from the player making it very easy to accidentally run off the edge or into a bullet



In this gif (on the right) I've created various platforms for the player to jump between and you can see that it makes movement quite staggered.

When the player crouches it halts their horizontal movement speed.

This works somewhat but I feel that combined with the vertical movement I already have in place it could confuse the player.



I suggest an alternative 

The number of buttons the player has to press at once is already quite high but I'm going to experiment with a 'dash button' that when held makes your movements more dash like. Or maybe a button that automatically dashes you in the direction you're facing.

Tuesday, 1 December 2015

3 Week Prototype - Introduction

I'm going to spend the next 3 weeks improving on a series of prototypes I made half a year a go.
The original inspiration was the first section of the 'Space Mama' boss fight from Rayman 1 where you have to jump and duck to avoid laser beams whilst trying to get close enough to the enemy to get a punch in.




BASIC RULES:
- The player can only move vertically, NOT side to side, ONLY jump and crouch
- The player has 2 different jump heights based on whether they are crouching when they hit the jump button
- The player can crouch whilst in the air
- The player can hold down the jump button to hover at their max jump height briefly
- The player can shoot bullets from the top half of their body (when they crouch the top half shrinks into the bottom half as if crouching when on the ground. Their feet don't tuck upwards)


The games I built look like this:
Regular Mode:
- Dodge random height bullets
- Shoot all the red targets
- Get points for each target hit
- Speed increases every 4 targets hit

Harder Mode: (best version)
- Bullets bounce Back if they miss a target (and can hit the player)

Hardest Mode:
- Bullets always bounce back (but still score if they hit a target)

Dodge Mode:
- You can't shoot
- Enemy bullets bounce back off the wall to your left (they are orange)
- Your score increases every second you stay alive




2 Player Mode:
- Both players can shoot at eachother
- Either player can have no more than 2 more bullets on screen at 1 time
(2 per player)
(This prevents players from creating unavoidable patterns of bullets)
- Looks fancy and has a day/night cycle




WHAT I INTEND TO DO:

- Prototype the game as an ACTION PLATFORMER with different levels and an overworld
- Add horizontal movement (I will talk more about that in a bit)
- Add a sword that you can use to reflect bullets
- I have designed a system for how bullets move up in rank/momentum/power

I believe that the core gameplay for this game (currently atleast) is solid. For such a simple looking system it provides a lot of depth in strategy and relies on player skill for its basic movement.

The long term and short term goals are clear and from playtesting I've done, people tend to pick up the controls fairly quickly.

No mechanic is unnecessary or unused, the player makes full use of everything in their move-set, often combining abilities for different outcomes

CONCERNS I HAVE FOR THE UPDATE:

- The controls might become too complicated if the player has to focus on moving horizontally too
     - The player has to be able to crouch, jump, shoot AND move horizontally potentially all at once

- I intend to add a dash mechanic (I will talk about this in another post) which has synergy with the sword HOWEVER this will require more testing as any tests I've already done lead me to believe that it does not work well with small platforms

- I don't know how the game will hold up with multiple platform heights
- I don't know how well the game will suit a longer play time (currently it's a play for as long as possible (normally < 1 minute) > Die > play again kind of game and that works well so changing that is risky

But that's the point of prototyping

I strongly urge you to DOWNLOAD and play the Jetpack Cowboy Collection HERE
and the fancy 2 player version HERE

Sunday, 29 November 2015

Alien Deception - 4 Day GameJam

TEAM DYNAMIC:

We worked in a group of 6 and my roles in this team was primarily programming (blueprint)
However I was also responsible for some of the game design and level design although not entirely. (I also felt like I was sub-team manager).

For example, we had to design the level with fairly linear paths in mind because I did not have the time to figure out how to implement more complicated alien ai (and I did work constantly on this game only stopping to sleep, grab food or go to the toilet).

I suggested to the team that we use Slack as a tool for communicating and sharing assets after seeing Mike Bithel speak highly of it on twitter. It worked fantastically (except when it went down for a few hours). I feel confident using this new tool now and intend to use it on using it in any future collaborative projects.

Honestly I felt like 6 people was too many people as the first day was quite frustrating with everyone trying to speak at once. It took us a very long time to come up with a basic design and what we came up with had too many elements and little thought had gone into the core game loop or how the game would ctually work.

GAME DESIGN:

On day 2 I suggested that we simplify the design (game theorist and designer) Keith Bergun style and focus on building everything around a central mechanic; 'protect the core, protect yourself'.
The suit designs were changed to be more defensive and the suit locations were changed to entice the player away from the core for more risk/reward style of play.

However I know now from playtesting that they were too difficult to see. I would make change the purple suit too as it was uninteresting and underwhelming in its benefit to the player.

Another bad design decision was the complexity alone. An arcade game should be instantly readable, the player should know how to play just by looking at the game. Clearly this was not the case as the objective was vague and the suits were ambiguous. We had to stop every player before they played and tell them what to do. Bad design.

We did have some good design:
- placing the suits far from the core (despite them being hard to see)
    - Therefor the player has to sacrifice the core for a while to go get them. Risk/Reward.

- Increasing the speed at which zombies were spawned in at a fairly quick rate (forces an endgame fairly quickly) Arcade games should be short, it's more addictive that way. See any successful ios game.
    - However it still may be too slow and 1 life would have been better if not for the ambiguity of dying

- Combo system (more kills with each bomb = more points for each kill)
    - Rewards efficient use of bombs and works in conjunction with the propellers which stall aliens and with the red suit which you can also use to stall (and group) aliens.

ART:

I made the aliens wiggle as they move to fake animation (and to help them get unstuck on walls)

The camera angle was chosen to reflect oldschool arcade games and the ui was designed to reflect this too

We wanted to make the suits distinct in colour because the player is very small relative to the screen size.

We extended this idea to make the whole level change colour and we gave the player a torch to make the direction you're looking clearer.

The top of the core changes colour if it's being attacked and the base of the core changes colour based on how much health it has. This was to make it visual without adding more UI elements.

AUDIO:

We extended this idea even further when we added music variations to the soundtrack. Again, this was done to make the game more readable as well as for aesthetic reasons.

So when the core is taking damage a warning sound starts playing in rhythm with the music.
When you equip the bubble (red) suit, a bouncy overlay plays along with the music and the alien suit has its own overlay too.

To make this work I just played all 4 tracks together at the start on loop and varied the volume for each accordingly.

Jack Douglas-Deane did all our audio and I consider it the most polished part of the game

JUICE:

We filled the game with bass, explosions, screenshake, destructible environments and particle effects. It worked well.

With more time I would have added permanence to alien death (blood splatters, rag-doll effects?) and added even more SFX to the soundscape.

CONCLUSION:

- Too many cooks
- Bad game design (over complicated)
- Good art but bad artistic direction (because it wasn't readable)
- Fantastic audio

- Working in a large team can be difficult to organize but the volume of work you can produce is increased
- Using Slack was helpful and I think using Skype would have benefited us also
- I think it would be useful to define peoples roles from the offset and stick to those roles

Tuesday, 10 November 2015

InSight - Asylum Jam 2015

I've done many GameJams in the past but Asylum Jam 2015 is the first one I've ever collaborated on.
Me and Daniel Waite spend 48hours working on this game about invisible aliens.

The rules of the Jam specifically state that the game is supposed to be scary but not include asylums or mental illness as a negative connotation.

My job was programming (everything in the engine), game design, level design
Dan did all the concept art, promotional artwork and asset creation 

I had been playing a lot of Heroes of the Storm at the time and 2 of the characters from that game, Nova and Zeratul both has the ability to turn invisible (almost) which allows them to sneak up on you and pick you off. I figured that It'd work well in a horror game because when you know something is there but you can't see it, it plays on your mind. You can never relax.

Some way into the game the player is given an ultraviolet laser that they can use to press buttons and shine on aliens to make them visible and immobile.

Because of the small size of the beam, the player can only get one thing at a time and therefor has to juggle between pressing buttons to progress and holding back multiple aliens.


I didn't want the player to be able to move whilst using the laser since by using the laser it makes them vulnerable which is scary. Very Resident Evil.

Because the aliens are always immobile when visible, we didn't have to animate them either. This was by design given that we only had 48 hours.

They also have a random chance of moving at 2x speed (just to make the aliens seem less predictable)

The game has good level design in how it introduces the player to different aspects in my opinion. Rather than explain it (because block of text) I urge you to download the game WITH THIS LINK.

Or watch THIS LETS-PLAYER


Collaborating on a game has taught me how important communication is between team members and I found that I was much more motivated when working in a team (I basically didn't stop working).

We used skype constantly to talk about the design and what we were working on at the time and this boosted my productivity a lot.

Also, it's nice having someone to make the art for me since it allows me to focus more solely on the game design and programming.

It taught me a bit about marketing and promoting the game in a positive way. 

Friday, 6 November 2015

Silk Runner

Silk Runner came about when I was thinking about rollerskating. You can generate speed just by tilting your body to one side because the gravity pulls you down and that causes you to turn and gain some forwards momentum.

This game's basically about generating forwards momentum through turning. I made a variety of levels to try it out in but the racetrack is my favorite. It feels almost like being a hockey player trying to generate as much speed as fast as possible whilst using your hockey stick to try and keep the puck in front of you.

I think the other reason it's good is because the game is about accelerating and accelerating is always more exciting than just going quickly, but the faster you go, the less control you have over your movement so the game has an element of risk/reward.
Also, Tom Francis (game designer) always said that the most important thing to get right is that the most basic player function is fun to do. I.e. with no predetermined goals, the player can still have fun messing around. This game definitely has that.

The good thing about the method of movement as you core mechanic is that it can be applied to almost any other genre. The ones I can think of off the top of my head are:
Racing Game
FPS/ Team Deathmatch (I actually added the ability to shoot and it works well)
Sports Game
Single Player Action/Adventure

Anyway, I made this in a couple of days as a quick experiment and it seems to have worked out well and it's taught me a lot more functions I can use in my blueprints from now on.

Tuesday, 3 November 2015

YEAR 2 - BA2a - Teaching the player how to play





When the player first boots up the game they're presented with the controls board that tells them what buttons do what.

To their right is the door to the first level.

Between the player and the door however is a wall of blocks, high enough to stop the player but low enough that they can still see their objective. The player HAS to mine through the blocks to reach the 'play' door. If they get stuck, they just look to their left and it says right on the wall "mine blocks: left click" so this shouldn't stump too many players.

In order to get to the first level, the player must be able to:
1. Look around
2. Move
3. Mine blocks

So before the player has even started the game they already understand it's core mechanics.

Maybe the player tries out the rest of the controls. Even on the menu screen I allow the player to try out the flares and the locator so they can get an understanding of how they work.

Also, the door is framed as an objective; a safe object. Any rational player who, coming across an identical looking door in the first level should understand that interacting with it is their goal.

So, upon spawning in the first level, the player sees this. The glowing object positioned right in the center of the players vision is sure to attract their attention and if the player is paying attention to the UI, they know that gold is a collectible item in the game since there is a counter in the bottom-left of the screen.

When the player goes to pick up the gold however, they will be in the hidden zombies sight range and the zombie will run at the player whilst making zombie noises.

The zombie will then get stuck on the wall, (exactly the same height as the one the player was unable to pass in the menu level) before eventually losing interest and turning back into its idle state.





This teaches the player quite a few things:
1. Zombies chase you
2. If they can't get to you, they will eventually leave you alone
3. They are stopped by blocks, just the same as you are
4. They make a scary noise when they chase you (i.e. if a player hears this noise later on and cannot see a zombie, then there could very well be one behind them)

Upon picking up the gold, the players gold counter increases by 100, confirming that it was actually gold. Now they know that gold is a good thing too, because it made a number rise. Also, the player will be in darkness again since the gold was the source of the light.



If the player looks to their left, they will see another gold light, accompanied by a white light. Since the player probably associated lights with good things now, they could very well take the risk and walk into the object to the left. When they do, they will see their ammo counter increase and now they know that these objects increase the players ammo.

I've even colour coordinated the objects with the UI.
all gold = yellow
all ammo = white

Since the GoldBlocks have yellow bits on them and there is gold on the top, hopefully the player will assume that when mined, these blocks drop gold.

Even if the player doesn't make this assumption, the only way they're going to be able to get to the gold is if the destroy the block underneath it. So there's really no way that the player will fail to understand GoldBlocks function.




















I've made a variation to the level design slightly for when the player unlocks the pistol, and it's simply to include pistol ammo too.
The player will see it, notice that it looks similar to the flare ammo, pick it up and see their pistol ammo increase. Now they know that this is what pistol ammo looks like.


I said in the previous post that I break the 50% chance for ammo to despawn rule and it's here. Since this ammo's function is to teach the player what ammo looks like and how it works, It has 100% chance of being there so there is absolutely no chance that the player will miss this part of the 'tutorial'.

(except the pistol ammo is still only there once the player has unlocked the pistol because obviously I don't want the player to be able to pick up ammo for an item they don't know about. It would just cause confusion).

YEAR 2 - BA2a - Ammo and Zombie Placement

This is the new map. It's been updated with ammo placements (white) for flares and for your pistol.

One way the game used randomness along with the exit placement and it's idle zombie movement, is with it's ammo placement.

First, the game checks whether the player has unlocked the pistol and if they haven't, the game only spawns flare ammo (no pistol ammo).

If they have unlocked the pistol however then the game does spawn pistol ammo.



 
The game then has a 50% chance to destroy an ammo placement on spawn.

Therefor, regardless of what items the player has unlocked, the ammo placements will be slightly different on each playthrough.

This means that the player will have to go out of their way to search for ammo, as they will be unable to accurately rely on their memory of where the ammo was hidden last time.

THEREFOR, if the player hopes to improve at the game, they will have to develop their underlying strategy and technical skill as experience ALONE will be less beneficial.


Important: There is one instance where I break the 50% rule and I will talk about why I do that in my next post


You may have noticed that there are a LOT more zombies (red) in this map.
Most of them are not in the first playthrough however.

I basically have an integer that increases each time you purchase the pistol. When you spawn into the next level, the game checks how many times you've bought the pistol (without dying since). Based on this number it will despawn some of the zombies.

1st level (no pistol) - 14 zombies

2nd run (pistol but not much ammo) - 20 zombies + special secret zombie that can teleport. I put a second one in the first room so that the player knows to expect the unexpected. I want the player to feel really powerful now that they can kill the zombies.

3rd run (after purchasing the gun a second time) - all 34 zombies + secret zombie - FPS/hell mode. I want the player to feel overwhelmed by all the zombies.
The reason I included this 3rd variation was because I wanted to test what the game might play like if I went down the design path of "This game could become an FPS shmup".

Tuesday, 27 October 2015

YEAR 2 - BA2a - Guns and Bullet Juice

The first thing I realized once I'd coded picking up items and switching weapons was that it's not particularly obvious whether you actually have the gun equipped or not. At this point, the only difference was the ammo counter at the top left of the screen.

To make it clearer I did a number of things:

1. I made a model from a few cubes and stuck it beneath the camera. Then I made it so that the 'gun' model is only visible when the weapon is equipped.


2. I made a crosshair and pasted it onto the UI. Then I coded it so that it's only visible when the gun is equipped.

I tried a few different variations on the crosshair, black was too difficult to see, white was too saturated, red was maybe too distracting. The one I went with in the end was white but at 20% opacity. Allowing the player to use it as a guide but subtle enough so that it doesn't take the attention away from the rest of the game.

HOWEVER, The reason I added the crosshair was to make it clear that the gun was equipped. I said previously that I didn't much want the player to be able to aim too easily because I wanted to instill panic/vertigo. THEREFOR, I may be looking for a solution (and despite having said that it's actually very satisfying playing the game like this).


3. I used an equip sound that I found royalty free on THIS website for when the player first picks up the gun. It's a sound the player won't of heard before in the game so they will know that the gun is now in their possession.


4. As soon as the player picks up the weapon, they manually equip it and I print the words "You can change items with 1 - N" (with N being the total number of items I eventually add to the game).


Making the Gun satisfying to use:
I want it to be a big deal when the player first shoots a zombie since the zombies make the player feel so powerless before they acquire it.

- When the player fires the gun I play a loud and satisfying shot sound.
- I also kick the camera back slightly with the impulse of the shot so that it feels really punchy.
- There is an additional red light attached to the player that flashes an intense muzzle flare with the shot.
- The bullet itself has a red light attached to it making it visually very clear.
- (The red is both for contrast and because it is associated with killing and action. I feel like this will heighten the 'power' of the shot)
- Stray bullets also destroy and blocks that they may hit, adding to the feeling of it being a tangible thing.

What I still need to add:

- Satisfying visual and audio feedback for when you hit/kill a monster
- Change the zombies AI to react to the gun shot (Scared/Run away? Aggressive/Run at you?)
- Particle effects?

YEAR 2 - BA2a - Menu and Shop


When the player first loads up the game they're presented with this level. It functions as an introduction and as a death screen.

I liked the idea of making the level as a physical space because it allows the player to experiment with how the character moves and it gives an introduces the atmosphere of the game.

The player progresses through levels by finding a hidden door.
I introduce this concept to the player on this menu level by clearly signing which door leads to where. Therefor, when the player gets to the first level of the game and they see the door they will immediately know that it is the goal and will from then on associate the door with progress



















This is where I'm currently at with the shop. I may add a shop keeper NPC at some point.

After beating a level, the player is taken here. The door is actually out of frame initially. This is because I want to draw the player to the items immediately in front of them that they can purchase. (Currently only 1 item in stock)

The items spin around before being picked up and have a spotlight on them to really say "Look, you can buy stuff". They also have their prices written above them so that it is clear how much they cost so that the player can decisions on what to buy.

Only when close to the shopfront might the player realize that the exit door is to their right. It's on the right because moving to the right is synonymous with a feeling of progression which is satisfying.

Monday, 26 October 2015

YEAR 2 - BA2a - Testing

I tested the game between friends at home and took notes as they played:

- Generally players only realized the importance of gold once they realized that you could use it to buy things.
    This sounds like a problem initially but I actually quite like it because it changes the landscape somewhat once players realize this. When they're new to the game, players only have to worry about finding the door but once they learn the value of gold they are is essence given a sub-goal that might change the way they play the next time through.

 - Most players played fairly cautiously but they were more outgoing as they got used to the zombies AI.
    It is by design that players should feel like they understand the zombies to an extent but in the full version of the game, the zombies AI needs to be smart enough that players can never feel entirely safe. Else, they will fair to find them scary.

- Once finding the outer wall, players would generally stick to it until they got close to the door
    This is a problem that would need fixing in the final version of the game. If players can bypass all danger then there is no challenge to the game and it looses most of it's meaning. A solution might be to remove the mine-able blocks by the outer wall and lose some mystery OR to have some kind of consequence to standing to close to the outer wall like an enemy that comes out of it.

- All players said it was clear that the large blocks in the outer wall were unbreakable
    Good. Their function is clear by their design so I don't need to explicitly tell players this.

I asked players some questions about their experiences playing the game. Here are my results:

Q - Did the zombies pose a threat?

A - Yeah, even when I had the gun there was still the possibility of one coming up behind you and killing you since you die in one hit


Q - Do you think that if I added other pickups you would be inclined to explore more?

A - I think I probably would. Like when I ran out of ammo I had to go back to stealth mode.


Q - Were the mechanics(after I initially explained them) clear? was your objective obvious?

A - Yeah, it seemed generally quite intuitve


Q - Were the zombies scary?

A - Initially yeah but after I git used to them they weren't so much


Q - Did you prefer this game to silk runner? (I'll talk about Silk Runner in a later post)

A - Yes, I think it was mostly because this game had an objective. Silk runner has a lot of potential if it were more fleshed out.


Q - Any thing else you want to add?

A - Maybe if it was an endless game, if you were going to go for that, it would be cool to have the decision of stacking up on ammo or flares"

Other notes:
- I need to make it clearer when you die
- I need to give the player more ecouragement to explore
- I think it's worth adding another rarer enemy type


Friday, 23 October 2015

YEAR 2 - BA2a - New Features and Mechanics

This is a screenshot from a top down perspective of my map. I've coloured in certain areas to better highlight what goes where.

Black - Player Start Point
Yellow - Gold
Red - Zombies
Green - Potential Exit Locations

The dark grey is just regular blocks that you can mine.












The player starts in the middle of the map.

They are in close enough to a zombie to hear what it sounds like but not close enough to see it yet.
    - So that the player understands what zombies sound like


The first thing they'll probably see is some loose gold which is glowing yellow (which feels safe in the darkness) when they touch it, it makes a satisfying sound so they know it's good to pick up. It also acts as a light source so that when they get to it they can see the zombie stood near by which should be facing away.




- Now the player understands that they can get quite close to the zombie as long as it's not looking at them. They also understand that gold is a good thing but is sometimes better left than taken as it gives the player greater vision.






The player should also see the glowing yellow gold blocks to their left. Since they know that gold is good they might try to mine the blocks revealing loose gold that they can pickup.


The player can throw out flares (of which there's a limited supply) that bounce around and illuminate the room

The players task is to find the door hidden at one of the potential spawn points (closest I could get to procedural generation). They have a device that sounds whenever they press the spacebar.
The higher the pitch, the closer they are to the door. I want the player to feel like they have a chance at finding the door in this huge cave without it being as easy as following an arrow or conveniently placed lights.




Monday, 19 October 2015

YEAR 2 - BA2a - Horror

In the hopes of figuring out which direction to go in for the horror part(s) of my game I've been watching some extra credits videos on the matter.

How the Uncanny Instills Fear
How Games Keep Things Exciting
How Horror Games Create Tension


Notes:

- I want to create an oscillation of excitement which starts high, cools down and then increases throughout the film
    - I can do this on a macro scale on a level by level basis.
    - I can also attempt to do this on a micro scale by placing monsters frequently enough that when you meet one it's a big deal, but not so frequently that it becomes routine. To raise the excitement throughout the whole game a roguelike/no saves style design works well. Where if you die, you must completely reset. Therefor the stakes will rise, the further the player gets into the game as the punishment for dying (time to get back to where you were) increases.


- "Quiet areas make us feel nervous"
    - The low points of the oscillation 

- Designers use limited visibility to build tension
    - I am doing this currently with darkness and destructible terrain (eg. You could mine through a wall strait into a monster).

- "The build up to the scare is actually as important as the scare itself"

    - In a proceduraly generated game like Twin Miners it will be difficult to attempt to script these kind of build ups. What I can do is use idle monster audio so that the player knows prior to the encounter that there may be a monster there. This will create a bit of a tension build up and should prevent against 'unfair' deaths that may occur from not seeing the monster too.

    - On another note I think I might use audio as a kind of indicator for where the exit for the level is. It's vague enough that the player won't be able to find their way directly to it and it should also tune them into listening out for sounds. So I can play with them on an audio level.

- Many games use false audio cues to make us think there's something there when there isn't. So we can less
easily predict when the real scares are.

- They talk about horror games which are enjoyable because they're designed to make real life feel safe relative to the game world vs horror games where the horror lingers with you after the game has ended. They don't explicitly say why they're enjoyable but I assume it's because they fall into Roger Callois categorization of 'Vertigo'.
  - Create safe zones in the game which let the player relax and feel good about what they've just overcome.

    - At some point I need to decide which style of horror I want to go for but honestly I only think I'll get that answer further down the development cycle.

YEAR 2 - BA2a - GunGodz

So Vlambeer has made a 3D game
GunGodz

I played it and figured that it was worth analyzing since it's so relevant to the FPS route of my game.

I also found this article where JW analyses the game.






- Firstly, the game has a lot of enemies. Initially not too many but it ramps up pretty fast.

This is because (as we know from vlambeers 'game feel' presentation), JW operates with the notion that lots of weak enemies are more satisfying to kill than just a few 'heavy' enemies. I guess it makes the player feel more autonomous.

This should work fairly well with my current design as the number of monsters ramps with how many monsters you've already killed. However, I can't quite easily predict the route that the player is going to take so I may have a few problems with pacing (?)


- They switch up the environment every few levels.

For variety and a feeling of progression I assume. It's always an adrenaline rush when you first come across a new area with new enemies.

I may not be able to do this in the prototype but it's definitely something to consider for the final build.


- No crosshair

I'm not entirely sure what the purpose of this is in GunGodz. It could be because they want the game to feel more like the games they were inspired by; Quake and Doom. Or it could be for the slight increase in difficulty.

Maybe it's just because I've played these kind of games before but I was never going to put a crosshair in Twin Miners anyway. If a monster runs at the player I want them to panic, miss a bunch and waste all their ammo. However, I'm currently considering adding it as a purchasable item from the vendor.


- At the start of each stage, you have no choice but to shoot a guy

Arin Hanson would probably refer to this as 'defining the core gameplay mechanism from the offset'. In other words, it's a statement; this game is about shooting people. It also teaches the player that left click is shoot.

Since shooting is optional in my game I'm not going to do this in my game but maybe I can always open up with a zombie facing away from the player or something. It's an explicit choice KILL or HIDE.

YEAR 2 - BA2a - Undertale

I've been playing Undertale a lot recently and it's been in the back of my mind whilst designing my game.

It's essentially a game about trying to find ways to avoid fighting in situations where killing is the easier option.

Essentially, Twin Miners is about trying to AVOID monsters so that they don't kill you.

I was playing with the idea of being able to KILL monsters as a last resort.


Naturally some people will just try to kill everything they come across and I figured, does it have to be a last resort?

And that's where Twin Miners crosses over with Undertale.

New Narrative:
- Your twin sibling is working on a CURE in their underground research lab for the VIRUS which has turned HUMANS INTO MONSTERS.
- You are the only person who knows of their whereabouts.
- It is your duty to find them and get the cure to turn the monsters back into humans killing/ saving whatever you see fit

Therefor, the player has a choice is whether to play stealthy and save as many monsters as possible
or
to play aggressive and kill lots of monsters
or
play somewhere down the middle.


How The Core Gameplay Loop Supports this:
- Explore
- Find gold/ Get gold from kills (?)
- At the end of the level, you can purchase ONE item (gadget for sneaking/ weapon for killing)
- Repeat next level

The game adapts to the amount of kills previously and will throw more/tougher enemies at you accordingly.
i.e. The game can either stay as a spooky stealth game OR it can evolve into an oldschool FPS