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.