Final Submission & Synopsis
Final Submission & Synopsis
Hey Guys,
So with my final semester coming to a close, I thought it best to reflect on my overall progress and assess the success of this iteration, and the project as a whole. Along with discussing any bumps found on the way and the path I took about correcting any plausible error (which you will find located in the video playlist below).
To see the update changes made and with the addition of commentary, I will also provide a link to my You-Tube playlist below:
Going back to my initial post, my primary focus for my MA study was to hone in on my programming etiquette in order to create functional systems that will not hinder the players progression, a key factor that I have found through this study always affects the players engagement with a platform (such as ARK, which still has a high development curve and high retention rate of players but also harbours a lot of in game bugs, to which I discuss further here - ARK - REVIEW).
From this basis, I devised to create a multitude of assets in order to assist in the players experience, which after these studies I have summarised into the key elements below (all of which I now consider to be the quintessential parts in keeping our users engaged, along with some examples that I have applied to this project):
- Various UI elements (Player Statistics - HEALTH/AMMO, Transitional Systems - LOADING SCREEN/LEVEL SELECT, Interactive Responses - SUBTITLES/KEYCARD).
- Universal Interactable Objects (that stem from similar ARCHETYPE parents (COLLECTABLE, INTERACTABLE) in order to minimize system errors, with the addition of having editable variables gaining the ability to re-work an instance in editor, which also assists in the minimalisation of the constant need to cast in independent entities; such as - COLOUR TYPE, COLLECTABLE TYPE, AMOUNT TO GIVE PLAYER).
- Engaging & Understandable Traversable Spaces (Notable Scenes - LEVEL CELLS/AREAS, Bespoke Objects - AMMO & HEALTH REGEN, House-Style/Repeatable Objects - LIGHTS/EXPLOSIVES).
- Simple AI (with enough brain power, to move at its own accord and choose whether or not to attack the player; again with editable variables in order to change the gameplay strength in editor, such as - HEALTH, DAMAGE, PATROL RADIUS).
Although with a collection of various mechanics, creating engaging and immersive gameplay will fall a little flat if it's left without some sort of aesthetic, in order for our design to become understood universally. For example, in my final iteration above you will see that I have one particular asset that is used in excess than any other, this being the little IMP (those guys below).
Now although I have created one singular archetype, with the aid of my scripting, I was able to maximise the potential of this one entity by opening up certain variables within it, as previously mentioned. This being the very reason why we see a variety of these little scamps within this project, such as the big figure's (Jim, Tim, Simon & Stan) all of which had increased stats and size, in order to create the idea of a harder enemy; unlike the glitch or respawn imps that have lesser health and attack power, although in large numbers do become a harsh threat (they are all essentially the same entity just with the addition of having editable stats in order to affect the gameplay required). With this method, it becomes much easier to manipulate your required gameplay by simply, editing a couple of numbers whilst in editor, opposed to diving in and out.
By also applying some automation within your game, be it in the form of animations (simple rotation/relocation/scaling or keyframe) you are also assisting to create a "living" project, which should reflect familiar actions on how we interact with our world from day to day; therefore communicating to our user that our project has a familiar set of rules to the normal life rules embedded within us, which should make the first instance of engagement being based entirely around user familiarity. This thought came about from my research into John Romero (below), where he states in the video (33:50) that the monsters where made to hate and fight each other, in order to simulate that sense of realism due to the nature of the entity.
This same workflow was then applied to every instance that I made in order to dynamically change the overall level flow as an when it should be, and ultimately how engaging the project could be, as I had the perfect setup to change the gameplay at a whim.
Yet in order to attain the desired effect for this DOOM like level, I had to experiment heavily with BSP due to the original design also being made predominantly out of BSP - more info here: Romero Research Part 1, and also using Basic Shapes - which assisted in fleshing out heavily repeated instances (Crates, Pipes, Pillars) to keep the geometry count down, all of which are provided as standard with the UE4 engine, both of which have been used in order to create the entire level that you see before you. In addition, it is worth noting that you can manipulate BSP within the editor to create simple, yet bespoke geometry, and then have the added ability to turn it into a static mesh, which is the method I applied to the lights of the level (a key factor because having a high geometry count, affects the overall lighting build process of the level, in addition to adding holes into the geometry, which are only corrected after a light build).
From these core principles of art and design within the game design industry, we are also required to utilise various user interface, minor or major (from hardcore FPS games - Halo/Destiny, or miniature games such as Paper Mario) in order to present the suggestion of response to the user. Be it in the form of miscellaneous special effects (SOUND/VISUAL), our user will always expect some sort of response from our game, a particular instance you can find commonplace within my project is the subtitle widget; although a simple one, I was able to dynamically change the content of the subtitle at every point necessary (similar to editing stats on the AI), but more importantly, I considered a visual aid with the correct content will always be received in the same manner from user to user, unlike a sound or special effect which is up-to interpretation (unless paired with a visual clue in order to create a house-style and pattern that the user can quickly identify).
The final topic worth discussing when it comes to engagement that I have found through these studies, originates with the ideal control scheme. Within my research I have listed various control patterns for games, and if it isn't a sequel, most control schemes do vary from platform to platform (CONTROL REVIEWS); so coming up with and testing the feel of a control scheme was vital in creating the ideal experience.
Unfortunately finding images to support the control scheme was a challenge, especially when needing them to have a house-style to stay consistent with our themes; but after much searching I did find the perfect free pack (Link Below), which upon utilising and adding additional effects (Highlighted/Not-Active) the player will have a clear visual map which has to at least be shown upon initialisation and then be stored somewhere they can find at their leisure (Help Menu).
Below you can see my final iteration of the control scheme along with a link to the PSD file if you wish to use within your own projects.
Unfortunately finding images to support the control scheme was a challenge, especially when needing them to have a house-style to stay consistent with our themes; but after much searching I did find the perfect free pack (Link Below), which upon utilising and adding additional effects (Highlighted/Not-Active) the player will have a clear visual map which has to at least be shown upon initialisation and then be stored somewhere they can find at their leisure (Help Menu).
Below you can see my final iteration of the control scheme along with a link to the PSD file if you wish to use within your own projects.
Comments
Post a Comment