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