Phase 4: Game Project Proposal

Title:

(Working Title) Project Transhumanism

Overview:

Project Transhumanism is a 3D 3rd person melee combat game, where you play as a weaponised mutant human as you fight your way through the spaceship you were abducted in. Fight through the military force that stands in the way of you and the escape pod, defeating the leaders of the detachment to get the codes to unlock the locking mechanism on the escape pods. With your powers as a Sol Nova mutant, you fight with 3 different weapons, all made via your powers from your body, and can switch weapon forms on the fly.

Goals:

• Create an engaging, fast paced melee combat system, with AI that feel good to fight.
• Create good quality 3D models for use in a professional portfolio.
• To deliver on the feeling of player power through the combat system, making the player feel like they can take on anything in the game without making the player overpowered.

Target Market:

The target age range for this game is 16 – 35 (young adult), mainly aimed at people that want to relieve stress, have a more mechanically engaging experience, and enjoy the themes that are presented within the game, such as transhumanism. The core aim of the user experience is to utilise player empowerment to create enjoyment, and to relieve stress in a way that feels fun, engaging and natural to the player, and as such the game should orientate itself to be able to be played in both long and short periods, as the target audience will most likely have busy schedules.

User Experience:

The aim with the core experience is to deliver on the feeling of player empowerment via movement and attacks that feel strong. With many games, while the attack might do statistically large damage, but feels underwhelming to use. I aim to make the feedback from attacks feel strong, with a proper sense of movement, momentum and force. This means that the animations will be key to making the combat feel the best it can go.

Unique Selling Points:

• On the fly weapon transformations, each weapon featuring a different playstyle
• Fast paced combat not normally found in games with similar combat systems
• The feeling of player empowerment that is core to the experience of the game

Competing Products:

Warframe

The core of both Warframe and this project is very similar; players fight horde style enemies that individually are not very strong, but as a group make a challenge for players due to how complimentary the enemies are. The difference here, however, is the focus on a stronger, more feature complete melee combat system, and the enemies are designed for smaller groups, making each unit slightly stronger than the average Warframe unit.

Monster Hunter

The Monster Hunter series was the basis from which I designed the melee combat system, but one turn off point for many players is the speed of combat, with Monster Hunter having slower, more deliberate gameplay, and my game has been designed with a focus on turning the combat formula of Monster Hunter into a faster, more movement and momentum based experience, making the experience more visceral.

Doom (2016)

The core experience of both my project and Doom (2016) aim for the same feeling of player empowerment, speed and a focus on movement. However, the two are vastly different in their approach to achieving this; Doom (2016) is a 1st person shooter, and Project: Transhumanism is a 3rd person melee focused combat game. This makes them very different to play, and can coexist even with the similarity in the aim of the experience.

Mechanics:

Here’s a list of the mechanics that have been designed so far. Bosses will need some more work in order to properly pull off well.

Player

• Camera will be a freely rotating 3rd person camera, that can be locked on to specific enemies if needed by the player. The button for locking on when using a controller will be pressing down the right stick, with the right stick as rotation.
• Player movement will be orientated around what direction the camera is facing (left on the left stick is left on screen, no matter what direction that is in world space terms), with sprint being left trigger and movement on left stick.
• Attacking will be in combos, using Y and B on Xbox controllers (PlayStation equivalents if I have the time for PS4 controller support). Weapon transformation will be the Left Trigger and Bumper, with it cycling between the 3 forms of the weapon. If transforming mid combo, the transformation will be a transformation attack instead, allowing players to combo between the different forms. Right Bumper is the guard break attack that ends the combo but deals good damage if it succeeds.
• Health will regenerate out of combat at a relatively slow pace, to increase tension, but in combat pressing the Right Trigger will allow the player to do an attack that steals health from the target. If used in isolation it has a longer wind up time, taking more health, but if the player uses the move mid combo, it is faster and doesn’t leave them exposed to other foes. Visually, the weapon will appear to eat the target, with the parts of the weapon warping out of shape and splitting apart, forming a maw that then eats the target. This mechanic will be visually similar to the one in the God Eater series, but will be more important in the moment to moment gameplay, and will serve a role like glory kills in DOOM (2016).
• The player can block incoming damage with the X button (and PlayStation equivalents if, as stated before, I get the time to map them). This block only lasts a set amount of time, and said time is shortened when enemies hit the player with the guard up.
• Dodging is also in the game, mapped to the A button, and allows the player to reposition in the middle of combat. Combined with the innate momentum that some combos allow for, this makes combat much more movement based than position based games such as Monster Hunter. Another element to dodging is that if the player dodges into a wall, the player character will use the wall to push off from and dodge even further, which can be a good gap closer move.
• There will be a minimap that the player will have at all times, but an expanded map can be brought up with the select/share button that allows the player to get a better sense as to where any objectives or targets will be. Enemies will only appear if visible to the player character, and if they make noise offscreen (although only as a ping that will remain for a few seconds).
• When hit, the border of the screen will briefly flash either red or white, depending on what looks good. Might also have a directional version to indicate where damage is coming from.

Enemy (normal encounter)

• The design for the enemy faction mechanics are based around the way that Warframe’s factions are designed; the individual unit AI is rather simple, but each type of unit have a role within the group that makes combat revolve around taking out the important targets first, and those that pose the greatest threat (for example, there are units that soak up all damage to other enemies within a large radius, but are weak to direct attacks. Players have to deal with these first, so that they can take out the other units in the group). Within my game, there’s going to be 5 different types; Ranged, Melee, Heavy, Mage & Stun (Formerly, there was also the Command Unit).
• The Ranged Unit will serve as the standard marine type enemy that tries to stay at range and use ranged attacks to kill the player. Unlike in most games (such as Warframe), however, these will do a fair bit of damage and come in groups, putting emphasis on using the player’s fast movement options such as dodging and the innate movement of attacks in order to get closer to them, forcing them to reposition.
• The Stun Unit is a melee unit that uses the same model as the Ranged unit, but carries a stun baton and acts as a easier melee unit that divides up attention. Not nearly as strong as the dedicated Melee Unit, the Stun Unit is more of a fodder unit than a serious threat, but can serve to distract players from the Ranged Units in the area.
• The Melee Unit will aggressively and quickly move into close quarters, trying to flank the player, then reposition out of the player’s attack range. They serve to harass the player, and attempt to make the player make hasty decisions that might lead to the player dying. They pose a much more serious threat to the player, as they are swift combatants with decent damage, meaning they serve as the first proper challenge for the player.
• The Heavy Unit serves as a tank, soaking up a lot of damage with their shield while dealing a decent amount of sustained damage over time. They can and will deal lots of damage if left alone, but dealing with them can take time, so creates the dilemma of focusing on the heavy and getting attacked by other units, or risking taking lots of damage from the Heavy. To counter their high defence and damage output, they are slow, and can be taken out without risk via hit and run tactics.
• The Mage Unit is the glass cannon of the enemy faction. They have attacks that do the most damage but are slower to cast, and can reposition fairly quickly if needs be, making them one of the most important targets for players. However, they sit towards the back, behind all but the Command units in an encounter (Command Unit has been cut due to obsolescence, so they sit at the back), meaning players have to fight their way to them, giving them time to attack the player.
• (This was an idea that got scrapped, but I liked the concept so left it for posterity. In a more feature complete version of the game with more time to develop the unit types, the command would serve a role, but with the time I have to develop the game I don’t have time to make mechanics for them that feel good and correct) The Command Unit type is the support unit, buffing nearby units in various ways while giving debuffs to players. They can heal units, but don’t do much damage, meaning it depends on how a fight goes as to the priority players should give to Command units.

Enemy (bosses)

As stated before, more work needs to be done for the bosses.

• The game will feature several bosses that will each have a theme to both the arena they are fought in and to their movesets. They will be the goal for the player; to escape the ship the player is on, all of the bosses must be beaten.
• One boss will be gunslinger themed.
• One boss will be a swordsman.

Narrative:
The game is set in the 28th century, and humanity has taken to the stars. Many mutations have emerged due to various incidents (solar radiation exposure, experiments etc.), and cybernetic enhancements and magic have become commonplace. The game itself is set aboard a spaceship, which is part of a secret government body known as ORACLE, whom are experiments to make a weaponised mutation that can be controlled for use in wars. The player character has been experimented on, and turned into a type of mutant known as a “Sol Nova”. However, during the experiments the crew were exposed, and died off. A clean-up force has been sent; an elite military force that has orders to kill any survivors and get rid of all the evidence. To escape the vessel, the player will have to take out the leaders of the force, in order to get the codes to release the lockdown on the ship, and escape in an escape pod.

More information found in the World Design blog post.

Visual Style:

The visual style of the game will be in the same vein of Warframe, with designs done based on the moodboards created, some of which are sampled below. The models will have their textures made in the Substance suite of programs, and normal details will be made from the high poly model and/or painted normal detail in Substance. The models will be made high poly first, then retopologised to create the low poly model that will be used in game. Please see the visuals blog post for more information.

Semester 2 Plan:

For the second semester, I will be creating the core experience of the game, not the entire game, due to the time constraints. It’ll take a lot of work to get all of the work needed for even this scaled down version of the project, but it “should” be possible to get finished within the time available.

Feature List:

• Main character, textured and animated.
• Player 3 Weapons, with animation sets for each. Weapons are sword, lance and hammer.
• At least the Ranged and Stun enemies, textured and animated.
• At least one room, textured.
• Props to populate the room, textured.
• All player mechanics, barring minimap and enemy tracking if time is more limited.
• AI for any enemies modelled.
• Any required effects and lighting, sourced off the asset store.

Schedule:

In order to properly execute on my planned FMP, I will need to plan out what I will be doing each week.

The plan for my workload each week will be to create one environment piece such as a room or corridor per week, one prop (weapons, environmental props etc.) per weekday, and one character over a two week period. This is so that I can create enough assets to flesh out the FMP with, and with the Easter break being right after the 6th character (which would be all of the normal Enemies and the Player Character) I can then spend the Easter break finishing up any assets that haven’t been finished up until that point. This is a high intensity schedule, but I believe it to be achievable and worth the effort. For coding, I plan to work all studio hours on coding the FMP, as I am less productive with modelling in the studios, whereas I can ask James about coding issues. The aim for the first few weeks will be to code the minimum viable product, which will be the player character, the ranged unit and the stun unit with all of the core mechanics needed for the combat system. From there, I will develop the remaining enemy units as they are made, and any other mechanics that I can add quickly.

After the Easter break, I will be evaluating my remaining time left, and if it will be possible to create one or several bosses. This process will happen sooner if I am up to date with my assets ready for the Easter break, but I do think that some issues with the models or animation will need to be resolved, and the bosses are not required for the base experience, and as such will not be focused on if I feel that the time would be spent better on something more productive, like polishing the mechanics.

I will regularly test my game as I add mechanics, but will begin more formal playtests once the minimum viable product has been coded, if not completed. From there, I will playtest each new addition to the enemy roster, and test the new level layout as I make new rooms and such. I will also do additional tests to make sure that environments are not too cluttered that they become hard to fight within. I may also code in a small tutorial, if I have time, to introduce the player to the mechanics and the combat system. This would need a fair bit of testing, and would be made after the Easter break if I have the time to do it.

For the weeks leading up to Easter, my work per 2 week period would look something like this: