Monday, 27 March 2017

ISMA 5006 - Imagineering our feature title

Time to begin the exciting process of coming up with our game concept, this is always my most favourite part, where we get to throw down all of our wacky ideas into a cauldron.

Me and Amber usually approach the ideation process by starting with a combined pool of ideas, then going away and building off those in our own time. Then we come back to share them with each other again to compare and contrast our ideas and pick the best ones.

Basic idea generation, recording anything that remotely interests us. Slowly a concept began to form.
As expected, the ideas that emerged were mostly story-based but each of our ideas fit quite well with each other. A base concept set in a seaside town filled with mystery and conspiracy started to take shape. All sorts of concepts were explored, including gameplay focused around getting a pet dog to find clues and retrieve items as well as the idea of getting the main character to shut out outside sensory input and retreat into a bubble.

As more work is put into the core game design over the next few weeks I will begin to post more details of the narrative.

Worldbuilding and narrative design

I have always been fascinated in worlds which feature large amounts of detail, character and depth; that have their own sets of rules that everything abides by to create a truly immersive fictional setting. This is something which I always strive to push in my personal projects as I try to think from the largest themes to the smallest details, making sure everything is completely fleshed out. Even in a world that remains largely un-fantastical world-building can help in grounding a setting as well as giving writers a playground to use and create really interesting stories within, by using an established lore.

For this project as the ideas began to develop a lot of similarities became apparent to a long standing hobby project of mine called 'A World Below'. The seaside town setting combined with a deep and mysterious plot involving occasional moments of fantasy and conspiracy is something which A World Below is centred around, and it seemed to make a lot of sense to set this new game within the same world and possibly even the same seaside town.

However using A World Below presents quite a few challenges from a design perspective. The consideration is that the world would have to be designed more with an overall picture in mind; the top-down approach, this will lead to headaches though as the world would be have to be created with this game in mind along with any games set in the same space.

The other approach is the bottom to top approach in which the plot is created and everything including the world comes from that. This method has its merits too in that the location will reflect the drama of the characters a bit more but this has the possibility of leading to potential plot holes, inconsistencies in the world between parts of the same game or between different games in the same universe. 

Below is a list on how I compare the world-building methods with pros and cons of each method:

Top Down Approach

+Consistent World Design
+Easier to layer up history and background of town
+Characters come naturally from world design with naturally fleshed out backstories
+Massively rewarding when executed correctly
-Can lead to headaches with trying to plan a whole world whilst needing to plan out one game
-Can be very time consuming

Bottom To Top Approach

+Characters and story are fleshed out primarily
+Emphasis on what is actually needed
-World isn't as fleshed out, not as much room for expansion
-Can lead to plot holes and inconsistencies in the world
-Starting completely from bottom to top can miss overall structure of what the game is

I think the best approach is to use something in the middle, between these two methods:

  • Create broad strokes world and story together, keeping in mind areas which might not be immediately accessible. Build up/alter lore to make it fit better with story.
  • Plan out base blockout according to main story beats rather than the other way around, this ensures we aren't creating unnecessary locations and making the world too big
  • Refine gameplay and level gating to story details as they are refined, fleshing out world details.
  • Have game!

Sketchbook ideas and world creation

Below are a load of photos of some of the development sketches over the last couple of weeks and some of the processes we have been through, there is still a lot of work to do with refining the overall concept but here you an start to see the creation and iteration of a town environment and a base narrative structure.

We started with the weird approach of creating a basic world design that we can refine later as the story takes hold, this way we can use the world design to inspire new story elements. The layout sketches started from a satellite image of Aberystwyth which has become a heavy inspiration point for this project. Because these sketches are on tracing paper I can easily overlay designs to iterate; I used this quality to flip the map layout and began sketching on the other side, the flipped layout lending itself better to our design.

I created an iteration of the really small sketch, refining a little bit of the town layout, I then overlaid a grid so then I could create an enlarged version of this for further iteration.

The enlarged version allowed for a better scale representation of the world and an opportunity to select places for landmarks as the story is built.

In my sketchbook, I created a loose sketch of the town with a key to label potential places, a lot of this will probably get discarded in the final story and iteration of the world, but this is just to get down a rough draft of stuff we might want to include. I also created a sketch of a potential network of underground tunnels which will feature as part of the story.

Below are sketches and ideas of gameplay ideas and verbs that the player can perform with the game: these are essentially actions the player can do within the game, access to these are gated through the game and this controls the game's pacing.

Current state of our whiteboard: We had a whiteboard from before with all of our different ideas and we then created this layout from filtering them down and iterating upon our leftover concepts. Here we have put sticky notes under certain headers, some of the ideas cross pollinating. As this becomes more solid we begin to record the key concepts in a high concept document which contains all the gameplay, world and story information as well as any art direction notes.

Next week we should have the high concept nailed down, afterwards work will begin on fleshing out the overall narrative, which will inform the overall level design and mechanics of the game.


Monday, 13 March 2017

ISMA 5006 - Start of a new project

After a long period of creating various prototypes, experimenting with Unreal Engine and working on my design skills the time has finally come to begin work on mine and Amber's new game. 

What that game is yet... we don't know, but we have some ideas floating about. Our time up until May serves as the pre-production period for this game, with production lasting through to September and beyond if the development required it. (Most likely will be longer going by our estimates.)

This new project we hope will be our first feature title that we can release commercially. In order to try and secure this plan we have applied our business to the Deutsche Bank Award for Creative Enterprises in a hope to gain £10000 to buy needed equipment and get marketing materials as well as receiving 12 months worth of business assistance and advice. If we are shortlisted we will have to pitch our project and indie studio business to a large group of people in a bid to win the final award. This will be extremely beneficial to us getting the kickstart we need as an Indie studio.

On the subject of kick-starts though me and Amber are currently looking into launching a Kickstarter campaign for our new project sometime into production around May-June time, hoping that we can gain the support we need to allow us to work full time as well having the possibility to bring additional talent on board. Currently we are still refining our overall business plans; when the game starts to take shape a bit more we will have a more concrete idea of the direction we will go in in regards to organising the campaign or perhaps taking an alternate route. 

The Game

After gaining a lot more experience with some of the more complicated parts of the engine I now feel like I am ready to continue and can begin applying some of the knowledge I have picked up in the last few months. Animation, AI and game feel are some of the areas I have been looking into and in the last project (The Third Person Shooter) I felt I was able to marry the three of those subjects together. I have been refining the third person character blueprint a little more since, making it potentially usable for this project.

This has lead to a natural progression of ideas somehow, wanting to go back and revisit some of the non-violent confrontation but this time using some mechanics I have developed like aiming and camera switching more effectively and in a different context. An idea that Amber suggested was having the camera aiming and rotating to face interesting things could be interesting, this has also been done in some Zelda games where the player can signal to faraway characters however more work would be done to make it even more interesting. Continuing this concept I have been developing an idea that involves a character piloting a hot air balloon and interacting with various characters and landmarks that the player will come across in the sky, but a lot of work would need to be done to get this feeling right and perfect as a majority of the work would be on making the balloon itself feel as good as possible and feel quite floaty.

The next stage involves exhausting this idea among others in order to come up with a large mind map of potential ideas that me and Amber can cut away at gradually until we have a concept we like, this would allow us to get a stronger game concept on the whole.

Next week I will cover our brainstorming and some of our pre-production process.


Sunday, 12 March 2017

Game Prototyping 5005 - Third person character work

For this last prototype I wanted to do try something a little more simple which involve less design and more focus on diving deeper technically into the engine to and achieving something more polished. For this prototype I wanted to focus on creating a third person controller that feels very nice to play as, allowing me to experiment with animation, camera work and weapons/damage systems. This idea came from the fact that it seemed a majority of mine and Amber's game ideas revolve around the idea of creating a third person game, so making the actual movement and game feel of walking and looking around in third person seemed like a logical step in order to make our final game really interesting. This was also partially driven by the fact that I wish to create an RPG system at some point in the future so creating a flexible character system seemed like a good way to develop a base for it, by implementing a damage system and also by beginning to understand more complicated areas like Animation blueprints.

To keep the process as a simple as possible I followed a tutorial series on creating a third person shooter, which I then customised with my own alterations. Focusing on a more simple design allowed me to refine the game feel, which is incredibly important for making a game feel engaging.

I am going to cover the entirety of my process on this project in this post, summarising each of the things I have worked on. Below though is list of the key parts though in regard to creating a proper third person character controller.

  • Work on developing a switching camera that zooms in to player shoulder when pressing the Aim button, with smoothly transitioning FOV and Post Process.
  • A Player controller that record information on camera direction as well as including a system for switching the states of the player HUD.
  • A shooting mechanic that uses the camera forward vector to get the hit point, a new aim direction is calculated from the Muzzle point on the players weapon.
  • A weapon base class that spawns onto the player at the start of the game based on a array of default weapons, this can be later expanded on with an inventory system.
  • Used default particles, sounds, camera shake and basic UI overlays to add to the 'Game Feel' to make it feel a lot more fun to shoot the gun and blast enemies. Without this the game prototype would feel a little stale.
  • Used physical animation for the first time, which allows actual interaction of skeletal meshes with the environment
  • Added basic enemies with set health, AI following and death states when enough health is lost.
  • Created an actor spawner with a forcefield effect on the blueprint, this is set to spawn enemies every so often unless a limit is reached on the amount of enemies in the scene.
  • Added variable walk speeds to the AI monsters, with a 5% chance of the spawner creating an extremely fast enemy that will sprint at you and make you jump!
  • Added player health and a HP bar in the bottom corner, that reacts to hits.
  • Created a post process 'player getting hit' effect which flashes a red vignette when the player is taking repeated damage.
  • Added a player score card that increases by one every time the player wipes out an enemy. 
  • Added in '+1' UI elements that display over the top of the enemies when they are killed, which include a subtle fading animation.

Saturday, 11 March 2017

Cable firing 2 - Battery Activation

I continued my development process this week by working on a mechanic where the cables can share power from one object to another, this is done through various switches in the cable actor itself that trigger on when it attaches to an object, transferring states between the connected objects.

Below I have attached screengrabs of some of the blueprint functionality I have been working on:

Cable Blueprint

This is a close up of the functionality that allows the cable to check and update the states of anything it is connected to.

This is part of the blueprint for the battery actor, which enables a state IsPowered? on a cable actor if it overlaps. 

When the cable is powered it then will power any connecting objects, in the screengrab from the Powerable Object BP above the object looks for anything that overlaps that has IsPowered? = True, if so it enables it's powered on state and fires a trigger event which activate any object I like in the scene by binding with an event dispatcher in in the level blueprint.

I made it activate a moving platform that only starts moving when I have powered on the object. This moving platform can be manipulated using construction script so I can define the beginning and end point.

Technical Reflection

This project I feel was incredibly beneficial to my progress by allowing me to experiment with some weird gameplay and have a bit more fun with the creation process. It allowed to me to try some new things in UE4 like physics constraints and I learnt a bit more about the correct way to get different blueprints to interact using interfaces, a subject I am quickly learning.

I am also trying to follow a good project framework and I used this project to get used to separating each part of the functionality into different graphs, functions as well as keeping the blueprint classes organised into their correct uses (For example, putting inputs and HUD controls in the player controller as opposed to the player character.)

Design Reflection and development as a game idea

This concept I believe can evolve in to a much more interesting game idea, with the cables acting as a great catalyst for concepting mechanics. The cables can serve a multitude of purposes, with the powerable objects mechanic allowing for a great deal of flexibility. The battery could power a huge number of different objects.

Concerning the cable actor itself, I feel like more work would have to be done with the cable component itself (the part which attaches the balls which get thrown) as it responds to physics in the scene in very horrible ways. The cable for example doesn't catch permanently on surfaces, bounces too much and the mass of the cable makes it fly around the map uncontrollably. The only way I think this could be fixed is through some really intense C++ coding with the physics engine, an area I'm nowhere near knowledgeable in. So if this prototype was made into a full game more intensive work would have to be done in this area, a programmer might have to be brought on board to assist with the physics work of the cable actor and the cables requirements in different situations.


Monday, 13 February 2017

Game Prototyping 5005 - Prototype 1 - Dancy Monster Things With Big Heads

After last week I have had a fair few issues trying to finish the puzzle like I wanted. My puzzle idea was to use the monster NPCs as platforms for the player to jump upon and cross gaps. In combination with the summoning mechanic, the player would be able to move the monsters to the location they want in order to cross over to new areas.

Core Mechanics

Below I have listed all the main mechanics with a little GIF of each to demonstrate how they work.

Input - Movement
Basic Third Person Character Movement with running, jumping and sprinting.

Input - Dance Interaction
Three of the gamepad face buttons (Left, Top, Right) mapped to different dance commands, represented in prototype using scaling and colour change.

Input - Call Monsters
Left Shoulder button will call any befriended monsters that have been selected in Sweep Mode

AI - Point to Point path following
NPCs are linked to a set of target points, which they move between. When one point is reached they move to the next one referenced in the overlapping target point, if linked correctly the NPC can walk following a circuit of target points that loop.

AI - Monster Spot
If an NPC spots another NPC they will walk towards each other and demonstrate the dance routine needed to befriend them in order to give a hint to the player. After they have performed the routine to each other they will return to their path.

(No GIF for this as I couldn't get it working again.)

AI - Player Spot
If the player is spotted then the monster will stop in it's tracks and become responsive to dance moves, once performed correctly the Monster will become 'Befriended' allowing them be selected in using sweep mode and them to be called.

Input - Sweep Mode
I managed to get a sweeping mechanic working that allows the player to highlight NPCs and select them for movement if they have been befriended using a dance. While in Sweep Mode (triggered by holding down up on the D-Pad) the player's camera freezes and the player can control a selection sphere that will select NPCs while the left shoulder button is held down.

Concepting some puzzles

Before I move on Mike suggested that I go through and detail some basic puzzles or at least some ways this concept could expand if it was a full game. This intention behind this is to see if the mechanic has creative possibilities beyond just a basic prototype. So below I have listed some random ideas of the potential ways the gameplay in this prototype can expand.

  • More specific abilities for the NPCs - some function as platforms, some can be lethal. Gameplay could be expanded where you have to deal with certain NPCs at certain times and get them into certain locations where they could then be usable as a way for the player to get over an environmental obstacle.
  • Zone separation, NPCs tied to certain areas that can only walk within those bounds, allows for complex puzzles that involve lining up NPCs within each different area correctly in order to gain access to a new area. Two stage puzzles could involve different NPCs separated by a fence, the player can get them to activate switches on each side, which then moves the fence, allowing both the NPCs to trigger a weight switch on one side.
  • More varied interactions, more naturalistic AI that react differently to each other. Giving the player more hints on how to interact with them properly.

Next week I will be starting a new prototype, focusing on creating a fun 'toy' to play about with, with less emphasis on creating a mechanic with a puzzle already in mind. This was advice gained from Mike, who also pointed out that this should help with being able to create a more interesting concept. Hopefully it should be fun!


Monday, 6 February 2017

Mike Pickton Meeting 7 - Making things more interesting

This week I shown Mike Pickton what I have been doing in the last week. I have been trying to create a simple game mechanic using AI inside of Unreal Engine 4.

The idea is to create a system where the player can approach roaming NPCs and interact with them using a dance mechanic where the player has to input the correct dance moves that the NPC responds to. The player can identify which commands to use by observing the NPCs walking around in the environment and respond accordingly.

I had some issues trying to work out the AI system inside UE4. I used a system called a Behaviour Tree, in which I could tie together a load of different tasks I have created in different orders, allowing me to customise behaviour.

Behaviour tree with my custom tasks which can be reusable for future projects.
After showing the demo to Mike he mentioned that the mechanic works well but I needed to actually implement it into a puzzle involving the NPC 'Monsters' Whether that involves them having some sort of special ability in order to solve a puzzle or perhaps something else.

Task for next week

For next week I should have implemented the mechanic into a workable puzzle that I can then playthrough, hopefully fixing the problem which I have had before where the NPCs don't react to each other, demonstrating the commands the player has to use. A puzzle is needed to actually show the idea as a potential game, and see if the mechanic can be interesting in context.


Tuesday, 24 January 2017

Mike Pickton 6 - Game Design-y things

This week me and Mike discussed my ideation process for focusing my game projects. So far I have spent my time researching, gathering reference material and recording any thought processes into a brainstorming flowchart.

My flowchart created for ideation purposes.

After talking with Mike he suggested some ideas and areas I could look into as an extension of what I already had. I had potential story themes, settings and mechanics under a different branch each but after feedback Mike encouraged me to crossover the branches and just separate them by related ideas, as opposed to sectioning off areas like mechanics in order to allow ideas to cross pollinate and create connections.

Another idea is to subcategorize mechanics into different areas if needed, and think about them in different terms as opposed to general 'gameplay' Most of the ideas I am exploring is within the area of a third person rpg-style game so that is something to work within, using that I can separate the different parts of that into subcategories:

  • hazards
  • environment/exploration
  • adversarial? - Any mechanics that involve the player confronting an enemy, doesn't have to involve violence.
  • progression - this could include a levelling system, upgrades like weapons or more general ideas of game progression that can lend themselves to story problems

The main point though that came up while talking was that I would need to document my process a lot more when it comes to actually planning out the game concepts, how they are made and any thoughts that go into the design process. This should include any key decision making; like for example whether I start developing a game from a mechanic or if I start developing from a narrative standpoint. I should be comparing the methods and explain my reasoning behind my creative decisions.

Game Design?

One thing I seem to have missed so far in my learning contract (essentially my self written brief for the year) is including work that I may have to do into the game design aspect of my research. This area will be quite a big part of my work and essentially covers all the ideation process and critical thinking I would have to do in order to create the game prototypes I want to. Mike recommended that after seeing some of my research work into game design that I include it into my learning contract, otherwise my current work can't really be marked.


Monday, 9 January 2017

Mike Pickton Meeting 5

This was quite a small meeting this week being the first one back from christmas where not a lot went on. The only other work I have had to do involved writing an essay for MA purposes, so me and Mike didn't have a lot to talk about this week!

We did cover some things however, the main point being that when it comes to practical work I should be creating videos or GIFs to showcase my progress for those that can't play the game. So that is something I will work on doing from now on, keeping all the clips on my Youtube channel and showing any interesting developments. This might encourage me eventually to be a lot more vocal about my work and processes, maybe adding voice tracks with descriptions at some point if required. (Might be more suitable during the development of our final game where I can create videos in more of a behind the scenes format.)

Creating little progress videos is definitely something I would like to get into the habit of doing, and it makes my work easier to look at and mark so that's an even better reason to do it.

Objectives for next week

Well next week I intend to start getting into creating things, but how I will actually go about the process of that isn't clear to me yet. I do plan to start gathering up resources and begin researching from online and using books to gather some inspiration and hopefully by the next meeting I should be able to discuss with Mike some of my creative thoughts I'm having; including any suggestions he might have for improving my ideation process.