Control Demo

I’ve touched up on the controls and they’re in a spot I like now, they all work in their current implementation. I’ve managed to do a few extra things with some of the controls like a wall jump, and a dash (although it is currently infinite, I have plans to change that). I can focus much more on the combat now, and hopefully have a full health and damage system by the end of the week. I can then focus on the level design and animations

Here is the link to the control demo:


The current controls:

Arrow Keys – Move

Space Bar – Jump

X – Shoot

Left Shift – Dash


Blueprints, Workflow and Schedules

I’ve spent a while working on the coding for my project, trying to get the basic framework out of the way – Character movement, controls, basic damage handling and collisions. However, I noticed that my understanding of the Unreal API, or lack thereof, makes doing this a little more difficult than I had anticipated. I could take some time to learn the API further, but this would cut in to my project time which I am already not up to pace with. Instead, I’ll be reverting to blueprints for the basic functionality of the game, and use C++ classes if there is something that needs to be implemented that is impossible or inefficient to do with blueprints. This will only be a very minor setback to me, as most of the time spent on my project was on working out the logic and methods behind the game functionality and figuring out how to make it interact and work, rather than the coding itself, which can be very easily applied to blueprints.

Another thing I am considering is to redirect my workflow and schedule to be more appropriate with my living situation and sleep schedule. As it stands, I live with 7 other family members with 2 computers and a laptop between us, of which only 1 computer is able to run Unreal Engine 4 smoothly enough to run my project on. As I tend to sleep during the afternoon after getting back from college, it is in my better interests to move my working schedule outside of college to be done during the night, when my family members are asleep and I have free access to the computer and am well rested. I’ll need to also make an effort to increase the number of hours I am working a week, as well as making sure the work I do is meaningful to the project and managing my time more efficiently.

Project Update

After some deliberation of my proposal and brief, I realised that it would be in my better interests to change the focus of my project, in this case I will be removing the interaction between top-down and changing it to a pure platformer level.

The main reason for this is that it reduces my workload – instead of essentially having to design 2 levels, I can focus solely on the platformer level. This allows me to create a much higher quality level, as the time that would have gone in to designing and building my top-down level can go in to improvements to the design and build of my platformer level. I also had a problem with the camera transition between the two perspectives; It was very difficult to get the timing and angles to a point where multiple transitions wouldn’t feel nauseating to watch.

This does cause a small setback, as there are a few things I have done for the transition and top-down aspect (such as blueprinting the camera change system), but the setback is small. Most of the work I have done has been for the platformer side of the game, so readjusting my schedule and plans shouldn’t be too difficult.

Level Building

Since my last update, I’ve managed to write the script to change the camera perspective between the two different gamemodes, designed the basics and intro for my level, and have begun to block it out in unreal 4, using the Side Scroller level as a base, as it already contains the character assets and one camera set up in the way I would like it, which makes things much easier for me.

The current design for my intro contains a few instances of moving geometry, which will have to be done through cinematics in Unreal Engine 4. I can use these to manipulate the level environment and have parts of it move, rotate and scale differently. This can allow me to put some forms of timing puzzles into the level, which I can combine with some obstacles to help make the level a little more challenging.

Here are the blueprints.

Here is an example of it working

Here is a video of a very simple moving platform

Further Ideas

I actually had these ideas a little earlier in the week, but hadn’t noted them down.

I had struggled a little with trying to find an objective for the platforming section of the game, and how it should interact with the top down aspect. That part was very clear to me, I wanted the top-down to be puzzle based. After talking to some friends, the idea that came to me that I was happy with was to make the platforming somewhat stealth based.

The platforming levels would have various obstacles, such as lasers, cameras, things that are to be avoided. Usually these would be on a set path which they follow strictly – until the player is spotted. At that point, the player has some time to escape, hide and reset their “threat”. If they fail to reset the threat, the game is over.

More plans

After some consideration of the workload involved in building a level (or multiple levels in this case), I have decided that the perspective shift will only happen in specific parts of the level, preset by myself. I have done this to avoid having to design the level around being able to switch freely, which would require me to make sure every aspect of the level is navigable and obstacles placed don’t get in the way of viewing the level in both perspectives, which would add a lot more time to my already difficult level design process.

Currently, My thoughts are that the ideas floating in my head are too much for me to build in this project, so a lot of them will not appear in my final project. I’ll need to make sure I write down the ideas initially and document which I choose to keep and which I choose to cut.

Ideas, Developments

Since my initial idea of “changing perspective” in a game, I’ve built up on the idea and tightened it to be more focused. The general idea I would like to explore is still the interaction between the two perspectives, specifically what I would like to achieve is to allow the gameplay to be shifted in the same level while still keeping the flow of the game and controls intact; The player shouldn’t feel as if they have to readjust the controls too much when the perspective shift happens, and the level should be designed in a way that allows the seamless shift without interrupting the current gameplay. The change should be in the gameplay style; I would like both parts to effectively be part of a larger puzzle, with the side scrolling element being focused more around movement and platforming, and possibly with some amount of combat, and the top-down being more focused on the logic and working out what needs to happen. As an example; if a level requires an order of buttons to be pressed in a certain order to get past a door at the end, the top-down aspect may consist of moving around objects, walking around on pressure pads, going through a sequence of doors in a certain order etc. to gain access or open paths, while the side scrolling aspect consists of moving across the level to those paths to unlock the door. While these should be the focus of the separate styles of gameplay, they should not be exclusive to them; the opposite gameplay style should still include apsects of the other, but to a lesser focus.

Certain details of the project will still need to be focused down further, such as specific mechanics and design, but these will be done based around my initial research.