YEAR 2 - BA2b - Darkest Dungeon and Negative Effects on Characters

Darkest Dungeon is a Roguelike which has some relevance to Doll House because of the way it incorporates multiple characters psychology into the core gameplay. I watched Mark Browns Analysis of the game and he states that "Darkest Dungeon ultimately makes you the bad guy but it doesn't tell you that in the premise or as a twist in the story. You explore your morality organically simply by engaging with the mechanics on offer.". Doll House doesn't want the player to be the 'bad guy' but I do want players to be able to explore immorality should they please and I'm supporting that by allowing murder, cannibalism, thievery, sacrifices to the devil etc as mechanics that the player can incorporate into their stories should they please.

Darkest Dungeon makes the player feel the results of negative effects on the characters by giving the player lower chances of success and therefor leading to more negative effects on the characters. This 'snowball' effect is something I've been thinking about for Doll House. I feel like I can make the mechanics more interesting and more realistic by making one lead into another, which is why the interplay between variables (emotions) is so important. Seeing our characters fall into desperation and potentially go against their beliefs will make the dolls in doll house much more life-like than characters in other games even though they follow their own slightly skewed sense of logic. Looking at the effects of Stress, Sadness, Jealousy, etc is something that many games don't tackle so I think it would be something at least worth trying.

YEAR 2 - BA2b - Multiple Dolls and Initial Asset Tests

With some extended discussion and deliberation I've managed to figure out how to efficiently model my blueprint to minimize the amount of code repetition. Essentially all the dolls are duplicates of eachother and they all have the same instruction EXCEPT each doll has a unique identifier that means that when they sinc their variables (every 5 seconds) with a global actor it saves them as individual variables within itself. eg. D1_currentRoom, D2_currentRoom, D3_CurrentRoom. Then when the dolls want to reference variables within other dolls they just have to check what the variable in the global actor is.
Anyway, this took a surprisingly long time to figure out and implement but I like it so far. It should make programming much quicker and therefor testing and making changes quicker.

Also, I made a super low-poly bed to see how it would look in game (since the camera is far out I told the team that they don't need to make particularly high-poly assets as a lot of detail would be lost).
This isn't my best effort but more of a test to see how low poly we could go whilst still looking good. It's safe to say that 13 polygons is too little.




I went slightly higher this time for some bedroom assets and concluded that about 100 polygons was about the minimum you could go without sacrificing quality but I'm letting the team make assets as high poly as they like as long as they're willing to UV map them.

However, given that ideally we need about 100 assets in the game I recommended that they keep the poly count as low as possible.

YEAR 2 - BA2b - Movement and Room Understanding

Currently I've managed allow the player to move a doll around the house by clicking and dragging as you can see in this gif.

I've placed trigger boxes in each of the rooms that the doll references to figure out which room it's in and it seems to work okay but the doll jumps around a lot when the player moves the cursor. I think this is because it essentially set the dolls Y and Z axis to whatever the trace from player to wall hits. ie. when there are bumps in the walls it causes the doll to 'jump' to different positions as it's constantly trying to the correct position. I might need to include some kind of minimum movement threshold or limit the dolls maximum movement speed.

I've also set homework assets for the team to create this week since we're going to need to populate the house soon and I need to program interactions between the dolls and the objects in the house.

One problem I knew this project would have from the beginning is repetition of code. UE4 makes it really awkward to access variables from within other assets and even for the most basic interactions to occur the dolls are going to need at least 5 different main variables each but this number will probably increase drastically. I don't want to have to copy and paste bits of code from one blueprint to another especially since I want the game to allow for more than 3 dolls in the house at once potentially.

YEAR 2 - BA2b - Design Document

The first thing I did once we decided on the idea was to write up a design document for the team to refer to and to make sure everyone understood the concept. As you can see, I included a development schedule and an overview before describing certain areas in detail.

I'll include a copy of the design document when I hand in.

YEAR 2 - BA2b - brainstorm

We all decided almost immediately that (3) was far too open and so any ideas that fell into this category were not right for the project. (1) seemed like a healthy challenge but any ideas we came up for it seemed too small for the size of the team and the length of the project. The two ideas that really stuck out to us were both in category (2):

[IDEA1] Cat Ship (working title) (if FTL was an RTS)
 - A side on 1v1 RTS set on pirate ships controlled by cats. The player must invest in various cat based weapons, defences and production as they go with the ultimate goal of destroying the opponents ship. The ship itself is stationary but the player can invest in different upgrades (the different rooms of the ship) and this determines what they will develop. Clicking on rooms in the opponents ship tells your weapons to focus that room. You can use this to stuns the growth of your opponents plans and/or earn you gold for more upgrades.

The game could include multiple unlockable costumes and ship skins with the potential to be monetized with optional micro-transactions.

[Good Points]
- Very marketable (everyone likes pirate cats)
- RTS is starting to gain popularity on ios (Clash of Clans) but has yet to fully engage the casual audience so it has the potential to fill a gap in the market.
- A good ratio of 2D to 3D with a healthy dose of design and programming (perfect for our team composition)

[Challenges/ Problems]
- The scope might be a bit small
- Similar theme/feel to a lot of other casual games (might blend in too much)

We also had plans for a (worms-like turn based version of the game)


[IDEA2] Doll House (subversive 'The Sims')
- A story telling game for lets players and fans of The Sims and subversive play (The idea originated from reading chapter 2 of Mary Flanagans book 'CRITICAL PLAY: Radical Games Design' and wondering what would happen if someone made a virtual doll house about subversive play)

A side view of a doll house with a 7 day/night cycle where the player has the ability to move dolls from room to room by clicking and dragging. the dolls each have their own randomly generated stats and desires and this determined how they might react to any given circumstance (taking into account what room they're in, who they're with, their mood, wants etc). The layout of the house may have some element of RNG too . It is up to the player to decide where to move the dolls but what the dolls get up to is of their own decision and the unexpected is to be expected. Over the course of 7 days in the house random events can occur including ghosts, mole infestations, zombie uprisings, squatters, plane crashes, alternate dimensions and more normal things like daily deliveries of packages. Whether the dolls end up happy, dead or something else is up to you (kind-of).

the idea is that if the player wants to they can try to keep these characters alive and learn about who they might be whilst surviving weird events and creating a new story each time OR they can subvert the play and try to get the characters into ridiculous situations where they are forced to murder/eat/attack/cheat on eachother or other entities in the house.

Also, after each playthrough the player can unlock new potential room types, character traits and objects.

The game could be monetized with expansions such as:
Medieval Edition  - torture dungeons, famine, witches, cults
Fantasy Edition - various fantasy races, dragons, questing

[Good Points]
- Very Marketable
- The kind of game that lets players would love to play given the huge amount of potential interactions and creativity they can bring to it.
- Never been done before (as far as I'm aware)
- High replay value
- Potentially cover real world issues and is quite shocking and weird. Should get lots of publicity on social media.
- Lots of fans of The Sims > No good Sims games released recently
- Good quantity of work to keep us busy for the whole 6 weeks
- Good ratio of work. The game should keep all 5 of us busy.
- Large scale but flexible. All we really need to make this good are the core systems and a few variables and interactions but it's almost infinitely scale-able and the more we do, the more open ended the game will feel.

[Challenges/Problems]
- Potentially boring players if they lose the feeling of being autonomous or nothing interesting happens
+ Possible fix would be to include achievements for various events the player can try to cause, lots of RNG, daily (ingame) events and packages with new objects the dolls can use
- Potentially very complicated programming and prone to bugs given the RNG and that it's not the kind of game I've ever made before.

YEAR 2 - BA2b - 1 Button Ruleset Clarification Classification

For the next 6 weeks myself, Connor, Tegen, Geena and Ben will be collaborating on a game with the theme '1 Button Game'. It's a rather vague mechanical theme rather than a contextual one so brainstorming was a little slow at first but it did give us the freedom to work on any pet projects we may have had in mind. Before the brainstorming session, myself and Connor discussed ways we might go about minimizing chaos (since last time we all worked together for the 4 day game jam the idea generation stage got fairly hectic). We concluded that meeting up in person this time would be beneficial, also I think we were more relaxed given the longer project length.

Before we met up I created a classification we could use to categorize our ideas and to outline the limits of our brief. This was to help organize our ideas and to more effectively analyze them.
The categories are:

(1) Strict - Literally 1 single button as the only input. Uses:

inputs - button press, button hold, button release

different contexts - eg. which part of the screen the character is at when the input is inputted.

Analogue input - how far down the button is pushed could determine of the character for example

(2) Mid - Allow non-button inputs too such as analogue sticks, mouse control and touch screen.

Possible custom controls like sliders, twists (like Bop-It)

Possibility for on rails shooter, point 'n' click, racing (where mouse_x = turn_rate) etc...

(3) Not-strict - Where the 'single button' refers to the 'action button' and other buttons can be used for other things.

(4) Other:
Subvert the theme - All button except for 1
physical buttons in the game that you can move around as a character
Single button with loads of different ways of interacting with it.

Continued in next post...

YEAR 2 - BA2b - Ambivolence Can Collaboration

For our 1 week collaboration project with the Graphic Design and Design for Publishing students we were given the task to re-purpose the object (Tin Can) with an emotion in mind (Ambivalence). The first thing we did was to discuss ideas for our object and a concept for a ballot box caught our attention. The tin cans would become containers of information and the public would place a ring pull in the can for the cause they felt the most strongly about. It was suggested that the question be something people are often ambivalent about and I suggested that the ballot be rigged to make a statement about how all the answers to the question are actually the same but reworded. I made us all a slack group and we used it to discuss ideas further and share files and research between one another.

The next day when it was pitched that rigging could be achieved through random chance via a hidden pachinko machine. The pins in the machine would be metaphors for everyday things that could sway your decision. The surprise is when the ball ends up in a can that you didn't expect and we reveal the influences that changed the outcome. A few of us started working on a playable mockup that would be shown on screen during our presentation. I did everything in UE4 (The general layout and programming), Matthew made the assets and Natalie made the 2D art.

By Thursday the mockup fully working but given that we still had 3 days we brainstormed some more ideas and Ross came up with the idea that the can could be a container of blank dice. You write outcomes on the dice and they make decisions for you to solve your ambivalence. Me and Matthew made another mockup using maya and UE4. I animated the can turning and the dice rolling out onto the game board. This was shown during our presentation.

A gif version of the animation we made

We made sure to include the audience where possible in our presentation where possible to make it more engaging and to test our product out. I think it went well. We got a good response to the presentation and we worked together as a team very well. I've kept in contact with some of the team members and we are planning on collaborating again at some point.

GamesDesign Playlist

Here's a link to my games design playlist on YouTube. I only save the best videos to this playlist but it should hopefully stand as evidence of the research into games design that I've been doing.

Games Design YouTube Playlist

YEAR 2 - BA2a - Evaluation

This is the term I've been waiting for. I have been looking forward to specializing in games design and I am enjoying it now I have. I certainly feel like this is the area I excel at as I have a strong background in researching games design methodologies and have a huge bank of games designers to refer to. I have been using GameMaker: Studio for a year and a half now so I have a fairly strong understanding of scripting and logic and this showed in how easily I was able to pick up UE4 and blueprinting. I am proud of some of the games I have been able to produce in this time and this is the first time I've ever collaborated on a game. I now understand how to use Slack and Discord to improve our productivity and I learned from the 1 week Game Jam how important the planing stages are to the outcome of the project. I also learned how important the communication of ideas is in a team.

I have kept my blog up to date throughout the project and used it to extensively analyze my own work. However, I was unable to shorten the writing much further than I already have without losing detail (since I have to explain logically how things work in order to explain exactly why it needs fixing and then various approaches about how to go about fixing it). Having said this, there are certainly posts in there that, with a more structured posting style would probably have lead me to summarize more.
I found the essay quite difficult to write because I kept wanting to analyze the game rather than talk about it's influences. I held back as much as possible and I was able to talk about a lot of it's mechanical influences as well as the reasoning the design choices (which were inspired by his previous games and by the design methodology he has built up over time). I also spoke about the thematic choices and referenced other games with a similar theme.

I had a lot of fun testing and iterating on the first specialism test and the design questions gave me a lot to think about. The second are test reminded me that I need to practice 3D more (although I'm happy with the in engine screenshots) and I'd like to get back into 2D art also. 
Generally I am very happy that I know a 3D engine now and I'm looking forward to experimenting with more game ideas. I feel more confident creating fleshed out worlds (thematically and in making the assets)  within my games now, which is something I often overlook.

Level Design Art Test

Our brief was to make a 1 - 2 minute level where any perk the player chooses at the start has the potential to get a highscore.
time = T
points = P
score = (200-T)+P

The scoring is completely linear. Therefor, I can make and test parts of the level separately and as long as they are balanced the the whole level should be balanced (as long as there are no ways to jump into or out of a section half way though). Because of this, I was able to test more efficiently, only playing a small part at a time and I could really push various routes to get the highest possible score.

Once all the sections were complete and balanced, I tested the level as a whole and my method held up. The whole level was balanced.

I tried to make the level as interesting as possible for all perks so, for the best scores, players will have to be creative with their routing.

I included 2 different routes for the double jump perk which are both equally balanced so the player has more choice with how they approach the level.

The best scores also require the player to pull off a variety of tricky maneuvers so players will feel a sense of improvement as they start to get a hang of them.

The top score with any perk is 191. I tested the level with my friends and as long as they cannot beat 191 with any perk, the level SHOULD be balanced. No one got lost or asked me where to go so I think the level is readable.

I wanted the level to be fun even for less skilled players so even if you miss a tricky jump, there's always an easy way around it. Because of this, the level also works as a race vs other players if the game was redesigned to include this.

I made a couple of modifications to the code to aid the testing of the level:
(I didn't change any core mechanics)

- The player can quickly restart a run by pressing 'R'. This was to make it as easy as possible to try again if any testers messed up a run whilst trying to get a top score.

- The gems make a sound when they're picked up. This was because some gems are quicker to collect if the player jumps backwards into them and in testing we found that sometimes it was ambiguous to whether you collected it or not. The sound lets players know that they got the gem without them having to keep track of the score too closely.

My level is a little bit on the short side (takes just over 1 minute for a first run) but I make up for that with interesting routing and ways of moving around the space, alternate routes and strong balancing. Each perk requires a different approach to running the level.

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.

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.

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.

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

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.

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. 

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

HERE

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

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.

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.

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

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

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. 

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.

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