Gameplay Programmer
Team: Brave Rabbit Games
​
My Dev. Time: 4 months
​
Genre: 3D Platformer
​
Technology:
-
Unreal Engine 4 (UE4)
-
Blueprint
-
C++
-
-
Perforce
-
Photoshop
​
Platform: PC
​
My Role: Programmer
Department breakdown
Table of Contents
Game Summary
Players take on the role of Ash, a mysterious druid-like creature navigating through a surreal, organic environment. When the player begins the game, the world is dark, as if in night, with little plant life. A ray of Sunlight spawns Ash from a floating island of earth. In the distance, the player sees a tree that guides Ash through the levels. The player uses Ash's wind-based interact ability to grow both gameplay and non-gameplay-related foliage found throughout the environment. The goal of each area is for Ash to activate touchstones, which in turn activate large rings that focus sunlight toward walls of miasma, clearing the way for Ash to move forward. The player's overall goal is to illuminate the tree in the center of the game world, and become a new spark of life for the tree. With each touchstone activated, the sky moves closer to the time of dawn and more organic life saturates the environment. When Ash reaches the center of the tree with the Sunlight, they fuse together with the tree, disperse the darkness, and fully restore the world to life.
​
I worked on the Camera primarily, as well as various gameplay elements, and also setting up the animation states for Ash. The camera is a third person dynamic camera. The gameplay elements include the game mode itself, a couple platform variants, and some gameplay elements that went unimplemented in the game.
Personal Contributions
Third Person Dynamic Camera
Summarized Bullet Points:
-
Intended goals of Dawn's camera:
-
Insure the camera does not get into a place that it should not be (Clipping into Ash or the environment)
-
Does not hinder the player's preferred actions
-
That aid the player in being able to see what they might need to see.
-
-
Very challenging to set up correctly:
-
Lots of Edge/Special cases that have to be handled to make one full proof.
-
Can require lots of revisions.
-
What works as a camera for one game may not work for another.
-
​
The concept of a camera is technically a well explored space, but it does not make creating a highly polished one any easier. Reason being is there are lots of special cases and edge cases to handle. Thus what may work for one game's camera may not work for another's.
In Dawn's case, the third person dynamic camera's intended goals are:
-
Insure the camera does not get into a place that it should not be (Clipping into Ash or the environment)
-
Does not hinder the player's preferred actions.
-
That aid the player in being able to see what they might need to see.
The camera is by no means perfect, but it was pretty solid by the end of the project. The player would need to be actively seeking the edge cases where the camera breaks in order to encounter them. When working with the camera, expect the programmer put on the task to pretty much never get taken off of the camera as their primary priority.
This image is an explanation for how the camera moves about the player.
This image is an explanation for how the Fixed Camera mode works.
This image is an explanation for how the camera handles dealing with multiple obstacles that are close together (and not being bumpy upon the player moving the camera up along them).
This image is an explanation for how the camera moves about the player.
User Interface Contributions
Summarized Bullet Points:
-
​In general, the menus were a product of all the programmers working on it together or in sequence.
-
Got the transference of data (settings) to transfer from the menus to the game, as well as be updated from the pause menu as well.
-
Was in charge of getting most of the support for controllers plugged into the menus. (this was before the last edits to the appearance of the menus)
-
Getting most of the functionallity up and running was pretty straight forward, except for when dealing with UE4's Combo Boxes (Aka, drop down menus).
-
The combo boxes basically would close upon using any of the directional input from the controller, and automatically select that next option.
-
The next programmer to work on it after me, removed the combo boxes entirely, thus solving the problem in that way.
-
-
What I learned:
-
Do not try to do both user interface and camera work at the same time; they are very beefy fields to deal with.
-
​
I handled getting the data and settings from the menus to transfer from the menus into the game mode, and also be readily updated upon leaving the pause menu. Before the last revision to the appearance of the menus, I was also in charge of getting the User Interface to function with the controllers. I got most of the functionality plugged in to work with the controller. For the most part this was straight forward, except will dealing with UE4's combo boxes (aka, their drop down menus). Upon using any of the directional inputs from the controller, the combo box would instantly close, and automatically select the next value.
We tried to dig into altering the combo box's slate from C++, but there was not enough time to handle it.
The eventual solution was to have the combo boxes removed entirely from the menus.
This is the options menu as it now presently appears in the game.
This is the language selection menu as it presently appears in the game.
This is the options menu as it now presently appears in the game.
Contribution in Prototyping
Dawn had a point where the gameplay was uncertain, thus we had various flash hacks in order to prototype various potential gameplay elements. Most of these went unused or were removed from the game.
What I contributed to these:
-
Various camera modifications (a handful were removed due to ability to possess other objects being removed)
-
Generally these were test cases for how to move the camera to another possessed object
-
Concepts resurfaced in Fixed Camera Mode to an extent.
-
-
-
Miasma Turret
-
Generally just spat out balls of Miasma that were intended to shove the player around.
-
Did not get added as idea of Miasma as an antagonist got cut entirely.
-
-
-
Mobile Obstacle with Children Support
-
We had a base object that already handled moving objects around, idea with this was to make the Level Designers lives easier, and give the object built in support for adding child objects to be moved.
-
UE4's present way to plug in child actor objects in a node set up was less than optimal.
-
This was removed cause the Level Designers decided they did not need a lot of rotating platforms nor a lot of moving platforms.
-
-
What Went Well
-
Despite team confusion at start, stayed focused and worked hard to create as high quality code and tools as quickly as possible.
-
Participated in all team flash hacks in order to help make self as available as possible for any needed camera edits. Flash hack created assets not always used, but helped team see what they actually wanted from the camera as well as other gameplay elements.
-
Collaborative effort between programmers was very strong towards the end.
Challenges
-
Did not know what the gameplay was going to be for about half the project; game idea was picked for the aesthetics. Led to lots of assets being created and cut rapidly.
-
Number of features needed for Camera was underestimated. Led to lots of revisions of the camera.
-
Communication pipelines were not always as strong as they could be; led to wanted pieces and features slipping through the cracks.
What I Learned
-
Camera is a well known area of work, but it is also a very complex one. If work on Camera again, expect to do it for the whole of the project due to how many features and how much balancing is needed.
-
Find out everything you need to know about a subject before you start on it, specifically what other people on the team want from it. Certain subjects, such as the camera, has different expectations of it per person.
-
Communication channels may not always be the best, so take an active effort to walk over and speak with everyone involved directly.
