Section 2:
Pre-Production & Planning
CONCEPT:
I've already deduced the type of game that I wish to make; not just the genre, but the general idea behind it too. This vastly reduces the amount of work that I need to perform for this section. Even so, there is still a lot of work ahead of me.
OVERVIEW AND GAMEPLAY:
Just like my previous projects, I think that producing a fully-fledged short game in the time that I have is completely unfeasible. Not only that, but due to the event limits in the free edition of Construct 2, I doubt that I would be able to produce a fully-fledged product even if I had time on my side.
Despite its simplicity, my previous project 'Ijiraq' proved to be poorly planned and too ambitious of a game for me to fully realise the concept that I had. The marriage of an unfeasible scope, messy planning and the duress of an imminent deadline resulted in a cobbled-together proof of concept rather than a proper game. I hope to avoid this outcome for my final major project by thoroughly planning out assets, gameplay progression, and the like.
Unlike Ijiraq, which was intended to be a full short game, I have decided that my final major project should take the form of a standalone level. A big part of this decision is motivated by the time constraints I face- I simply do not have enough time to create a full game. However, an even more important factor in this decision comes back to planning and ambition. My aims for Ijiraq were too grand, too unfocused; I was thinking vaguely instead of concretely. I believe that by laser-focusing on a single level instead of tackling an entire game, it forces me to stop thinking in vague concepts and instead come up with concrete gameplay ideas.
I believe there are two directions in which I can take this single level:
* An endless score-attack level, akin to LUFTRAUSERS
* A linear, objective-based, progressing level akin to ACE COMBAT 7.
There are upsides and downsides to both forms of level design.
The score attack design is the easiest of the two designs to implement. The goal is simply to survive for as long as possible, fighting progressively stronger waves of enemies to achieve a higher score. As such, I don't need to expend much effort or use many events developing the core gameplay loop. To put it shortly, the benefit of this design is that it is economic. The problem with this design, however, is the very same simplicity that makes it easy to develop. As seen in LUFTRAUSERS, the gameplay loop is repetitive, and the extent to which it changes is steadily throwing more and more enemies at you until you get swamped and die. Unless the game has an alternative progression system, such as unlocking new characters or weapons, the game relies solely on how fun the raw gameplay is. If that gameplay isn't the most engaging thing in the world, it's very possible that the player will just get bored and play something else.
In comparison, the objective-based progression design is far more complicated to implement. This is because I would have to program a variety of conditions to progress the level, such as what phase of the level is currently active and what conditions cause it to move to the next, which would also eat into the amount of events that I have at my disposal. However, providing the player with a series of objectives to complete not only gives them a tangible goal to work towards, but it also provides a framework for game progression and the introduction of new mechanics. This allows me to develop gameplay that is more varied and structured than the score attack design.
Ultimately, I have decided to go down the latter route and create an objective-based, linear level. I confess, a big part of why I gravitated to this design instead of a score attack mode is because of my own pride. It's easy to create an endless survival mode- effortless, even -and I want to prove that I am capable of producing a complete product of high quality. Taking the easy way out by creating a game that technically doesn't even have an ending would be letting myself down.
On 11/03/2023, I had sketched some initial concept art for my game, as seen above.
For this concept art, I have used the real life F-16 'Fighting Falcon' (left) and Sukhoi Su-37 'Terminator' (right) aircrafts as placeholders. In doing so, I realised just how bad I am at actually drawing jets. The F-16 looks fine, but the Su-37 doesn't have wings and the proportions are completely off This is fine as far as concept art is concerned, but I ought to study how to accurately draw jets when it comes time for producing the actual sprites for the game. Or, at the very least, I should learn the key features of jets and how to exaggerate them; I'm not striving to recreate reality with this game, after all.
The biggest problem that this concept art elucidated was the camera. A problem that I had with LUFTRAUSER was that due to the limited screen-size, enemies such as boats and ships would attack the player beyond their range of vision, making fighting back nigh-impossible without getting closer. Though beyond-visual-range combat is a thing in real life, it would not be fun whatsoever in this game, not with a screen this small. Although, if refined, it could make a fun gimmick for a boss encounter. I'll have to keep that in mind.
Still, with the limited amount of events that I have to play with, I don't want to add too much and end up being unable to finish the game.
The concept art also raises an issue with the HUD, as I will have to dedicate a chunk of the screen to house it in. This isn't so bad in a 3D flight game; in a 2D game, however, this heavily obstructs the player's view and could even lead to them getting killed.
[GRAPHICAL STYLE:]
As with my previous projects, I will be developing the sprites for my game in the online web-based pixel art software Piskel. Just like why I'm sticking with Construct 2 for this project, a big part of why I am using Piskel is because of my familiarity with the tool. Unlike software such as GIMP and Paint.net, Piskel allows for the creation of entire animation sets, and the frame-by-frame view and 'Onion Skin' tool (overlaying the previous/following frame over the current frame, allowing the user to cross-reference for consistent sprite design) provide great precision in performing this task.
Unlike my previous two projects, however, my choice in pixel-art graphics is not an attempt to replicate the retro graphics seen on consoles such as the ZX Spectrum. During my previous project, I tried to adhere to the ZX Spectrum's limited colour palette; I was restricted to strong block colours, resulting in a vibrant graphical style, and could not make use of shading, which caused said graphics to be flat and harsh on the eyes as a consequence.
Pictured: Borderlands 2 (2012) [7]
Cel-shading is a computer rendering technique most commonly seen used in animation and video games, named after the celluloid film on which animation was made. As its namesake suggests, the aim of Cel-shading is to achieve a 2D look, akin to an animated film or comic book, on a 3D model; objects are shaded with block colours in lieu of the smooth gradient most 3D modelling uses. [8]
Pictured above, Gearbox's first-person looter-shooter series Borderlands is one of the most famous series to make use of the Cel-shaded art style, although the method used to achieve this style deviates from the usual method utilised. [7] The series is famous for its wacky and over-the-top humour, and focus on high-octane combat involving billions of increasingly bizarre weapons. The art style further reinforces the surreal and zany atmosphere of the game and makes the game recognisable at a glance.
I am developing a 2D video game, so it goes without saying that I won't actually be using Cel-shading, but I am drawn towards the aesthetic nonetheless. The style is bold and oozing with charm, the use of strong outlines and vibrant block colours striking. In that aspect, it's not unlike the graphical style of LUFTRAUSERS, which I previously praised. If I were to implement this art style in my own game, it would go a distance to tell the audience that this game is a fun, fast-paced arcade experience, instead of a slow and methodical realistic war game.
[MECHANICS:]
On the 17th of March, I drew up a piece of concept art for the level that I wanted to create for my game. The concept behind the level itself was to incorporate a mix of air-to-air and air-to-ground combat. The scene depicted in my concept art is an assault on a castle; the player would fly across the sea, contending with a variety of airborne threats, before arriving at the fortress, where the the level would switch to an intense air-to-ground engagement.
This concept is heavily inspired by the level 'BASTION' from Ace Combat Zero: The Belkan War, in which the player is tasked with navigating a mountain range to destroy an ancient castle that has been retrofitted with powerful anti-air weaponry to stop the allied forces from invading the enemy homeland. [11] The ground-attack missions in the Ace Combat games are some of my favourites in the series because of their grand sense of scale (ranging from reinforced military bases to entire cities) and difficulty.
However, for reasons disclosed in the 'Enemies' section later in this workbook, this concept would not see the light of day.
Missiles:
Missile concept art, produced on 15/03/2023.
Illustrated plane in a simplified style akin to LUFTRAUSERS for the sake of time.
As mentioned during my analysis of ACE COMBAT 7's gameplay, I was highly disappointed by how easy missiles were to evade.
A big part of why standard missiles were so easy to defeat was due to their tracking. In game, a majority of missiles tracked the player depending on where they were instead of where they were headed. A select few special weapons available to the player, such as radar-guided SAAMs and fire-and-forget QAAMs, had proportional guidance capabilities, but no enemy in the game had access to such weaponry. As a result, most threats could be evaded by turning for a few seconds.
Thus, for my game, I wanted to incorporate missiles that utilised proportional guidance in order to give the player a greater challenge. It isn't a hard element to implement, either; the Turret behaviour comes with a setting that causes the Turret to track its target dependent on where it is heading instead of its current location.
However, an issue arose when I considered how the player is actually supposed to dodge these missiles in the first place. Chaff and flares are used to disrupt the missile's guidance from behind, but the player has no way to contend with the threat if it's approaching from the front. They can't outpace the missile because it's faster than they are; they can't outmanoeuvre the missile because it's more mobile than they are and are programmed to head the player off at the pass; and I can't simply tune down the missile's mobility to accommodate this because that would defeat the point of even having proportional guidance in the first place.
As I was wracking my brain trying to come up with a solution for this, I thought back to a game I had previous played: VTOL VR, a virtual reality game which puts the player in charge of piloting a military aircraft. As a realistic military flight simulator, missiles in this game use proportional navigation, and I was terrible at evading them. A few times, in desperation, I tried to shoot down incoming missiles with my guns, to no avail.
That was when I realised the answer to my problem: allow the player to shoot down missiles with their guns! Not only does this provide a solution to evading oncoming missiles, but I also believe that it's an incredibly satisfying and adrenalizing solution. It captures the same Top Gun, 80's action film vibe of 'doing things just crazy enough to work and coming out on top' that both ACE COMBAT 7 and LUFTRAUSERS captured. This led to the production of the concept art pictured above.
As seen in the concept art, I was also debating on including both heat-seeking and radar-guided missiles, with the easily misled yet highly mobile heat-seeking missile being the most common threat and the hyper-focused radar-guided missile being the rarer and more dangerous threat. However, I have decided against the inclusion of heat-seeking missiles. Heat-seeking missiles, as implied by the name, navigate based off of the greatest heat source they can detect. This means that, to create a heat-seeking missile, I would have had to develop an entire heat and heat detection system. This would be such an intricate and complicated system to implement, which would lead to a lot of time spent on bug-fixing and playtesting; a needlessly complicated system created to achieve an incredibly simple goal.
As depicted in the initial concept art, player missiles will be guided by a lock-on system. I believe I can implement this system by using the Line-of-Sight behaviour. Upon requesting a lock, the system will pick a target within the Line-of-Sight and paint them. If the enemy is still locked on, still within the Line-of-Sight, and a missile is launched, the enemy will be assigned as the missile's target in accordance with its Turret behaviour.
Enemies:
There are two categories of enemies that I wanted to develop for my game: airborne enemies and ground enemies.
Airborne enemies, however, proved to be an extremely tough nut to crack. There are two reasons why I struggled with them:
* Design philosophy. As referenced during my research on LUFTRAUSERS, I believe that each enemy should serve a purpose. The purpose of ground enemies is area denial; they force the player to navigate the airspace in unique ways to avoid the anti-aircraft fire, and from SAMS and AA guns to flak cannons, there is a variety of ways in which they can achieve this aim. This variety of enemies turns air-to-ground encounters into games of threat prioritization, and there is a lot of feedback in slowly stripping a heavily-fortified location of all its offensive capabilities.
I am struggling to come up with what unique element of gameplay that airborne enemies add. However, the fact that airborne enemies are intelligent enemies could be unique enough to set them apart from the ground enemies. They don't play off of the ground enemies, per se, but they do provide an interesting shake-up in the gameplay loop.
* Implementation. Owing to their nature as stationary targets designed to choke the airspace, ground targets do not need to have advanced AI. At their most basic, they would simply be a container consisting of a base and a turret with the Turret behaviour assigned. There is far more nuance required, however, for the AI of airborne enemies. This is because, unlike all the enemies in my previous games, they aren't brainless enemies.
Let's take an enemy jet, for instance. There are two behaviours that I would have to implement: an 'attack' behaviour, where the enemy would pursue the player and fire at them with missiles and/or ballistic weaponry; and a 'defence' behaviour, where the enemy would manoeuvre to defeat the player's own weaponry. Not only would I need to code and playtest both of these behaviours, but I would then have to implement a way for the enemy jet to switch between both of these behaviours in the midst of combat.
I don't want to completely disregard airborne enemies. However, considering this information, I cannot afford to create a variety of such complicated AI in both the interests of time and event conservation. Therefore, the number of airborne enemies will be drastically culled in comparison to the ground units.
In response to this issue, I had come up with the 'Chopper' enemy. The purpose of the Chopper was to serve as a regular airborne enemy in lieu of enemy jets, contrasting their high manoeuvrability with unmatched firepower at the cost of slow movement and neutered evasive capabilities. What this meant was that I was able to incorporate enemies capable of airborne combat, filling in the niche, without having to spend an exorbitant amount of time playtesting in thanks to their simplicity. The inclusion of Choppers also foreshadows the use of the rarer enemy jets.
Unlike enemy jets, given its inability to pitch, the Chopper is restricted to firing along the X-axis. Instead, the Chopper must rise approximately to the player's level in order to engage them. Therefore, the Chopper requires a way to both constantly acquire the player's Y-axis and move towards it. There is a behaviour in Construct 2 known as Pathfinding, which allows an entity to acquire a path to an asset and move along the path to reach said asset.
On 22/03/2023, I opened Construct 2 in order to test my theory. I created two sprites, one pink and one yellow, and gave the yellow sprite the Pathfinding behaviour. Sure enough, when telling Sprite2 to find a path, I was able to manually input X and Y coordinates for Sprite2 to move towards. The only issue that I faced was the fact that I needed to input an X value as well as a Y. Sadly, as far as I know, there is no way of inputting a null value for the coordinates.
Instead, I tried setting the X coordinate to Sprite2's own X coordinate. However, this resulted in Sprite2 moving in a slight diagonal direction; viewing the process through the Debug Layout feature revealed that this was because the angle of motion was not at 270 when Sprite2 began moving, even with diagonal movement disabled. However, as I stated, this movement is only slight. Is it worth it to stress out and scramble looking for alternative solutions when this works just fine as is? I don't think so.
I also attempted to replicate the drifting behaviour of a helicopter by adding a horizontal Sine to Sprite2. As it would be constantly moving around, I assigned Sprite2 an instance variable which was set to its X coordinates on creation. Instead of moving to its own X variable, Sprite2 would then instead move to this instance variable. However, with the Sine behaviour applies, Sprite2 would constantly stop and start as it moved along its path. Therefore, this feature would be scrapped. At the very least, I knew that I could implement the Chopper enemy as I had envisioned them.
Ground enemy concept art, produced 16/03/23 - 21/03/23.
Because of the changes I have made to enemy balance, the 50/50 split between air-to-air combat and air-to-ground combat depicted in the level concept art will be unfeasible. I could include it still, but half of the level consisting solely of two enemies doesn't sound like a fun and engaging experience. I still, however, am keen on the idea of the castle assault depicted in the concept art. Even if it doesn't take the form of a castle per se, I like the idea of a pseudo boss-fight in the form of a heavily armed location.
This alternate level idea, although keeping the framework of the original concept (a long approach to a heavily fortified location), I changed the environment from the sea and cliffside to the countryside in order to fit with the heavy focus on air-to-ground engagements.
I had also decided to incorporate the enemy planes, which I had finally named "Interceptors" based on their roles in this version of the level, as a boss fight at the end of the level once the base is fully destroyed. Defeating the Interceptor aircraft will result in the completion of the level.
Therefore, the level will be split up into three segments: the approach to the enemy base, consisting of small enemy outposts with minimal defences; the enemy base itself, armed to the teeth with anti-air weaponry; and a surprise boss fight to test the player's skills and cap off the level in an exciting way. Though the gameplay loop itself remains the same throughout the level,
Character Design:
The final element of pre-production that I had to work on was the player character and their own capabilities. This includes aspects such as alternate weapon choices and the flight controls.
On 15/3/23, I also decided to sketch out a concept for the player character's jet.
The shape of the jet is at once inspired by the F-16 'Fighting Falcon', from which I took the bubble canopy and tubular shape, which gives the aircraft a friendlier aura; and the fictional GAF-1 'Varcolac' experimental aircraft from the game Ace Combat: Joint Assault, from which I derived the long and sleek shape. However, I'm not particularly happy with the final result of the development process, seen bottom-right; it reminds me too much of the GAF-1, particularly the undulating shape of the engines. I'm okay with taking inspiration from the aircraft, but be it accidental or intentional, I don't want to rip-off the aircraft one-to-one. The initial sketch (top-left) takes obvious design cues from the aircraft, but the simpler, rocket-like shape gives my design its own identity. Well, I dislike the initial tail stabilizers, but that can be worked on.
As seen in the pieces of concept art dating from the 21st onwards, the curved and pointy wings of the player jet were replaced by a folded-wing design. This was actually an accident that occurred whilst I was drawing the player jet during the enemy concept art, but I really like the angular, almost alien effect that it has on the aircraft. It further serves to bolster that futuristic aesthetic. The single-engine configuration of the original design was also brought back.
The GAF-1 'Varcolac', as seen in Ace Combat: Joint Assault. [9]
Flight System:
As mentioned during the Research section of my workbook, I was heavily inspired by the control scheme of LUFTRAUSERS.
However, I didn't want to copy the control scheme one-for-one; its plagiarism for one, and for two, I felt that the arcade style that it brought to the table wasn't extremely fitting for the type of game I wanted to create. I wanted to balance that arcade style with elements of realism, such as drifting, stalling and speed-dependent aircraft handling.
As I did with the Chopper (perhaps I am simply becoming restless after spending so much time working on pre-production), I booted up Construct 2 and performed a short test just to see if my idea was feasible. For the sake of these early tests, in the interest of time, I gave the player the appearance of a yellow cube as a placeholder sprite. Placeholder sprites are important, as in early development, this allows developers to quickly represent the asset for the sake of gameplay tests before developing proper sprites at a later point.
The first method of implementing this flight system was through the use of the Car behaviour applied to a sprite, a behaviour which I had previously toyed with during the Kobayashi Maru Tank Game that we had done at the very beginning of our course. I had also applied the Physics behaviour to said sprite, as this would add gravity to the sprite.
However, the instant that I would begin moving, the gravity would lose its hold over the sprite. The moment that the sprite slowed to a standstill, gravity would kick in once more and the sprite would plummet. I was unable to figure out how this happened, even after analysing the event through the Debug Layout. I initially assumed that, due to the pull of gravity being halted by the change in acceleration, that gravity was simply a downwards acceleration. However, it turns out that the angle of motion is not affected throughout this process.
[Perhaps the technical explanations should be moved to the development section once I begin working on it?]
Therefore, I had to do away with the Physics behaviour. Whilst researching this issue online, I came across a forum where someone had a similar issue. The common consensus was that using the Physics behaviour strictly for gravity use was overkill; it was suggested that the author of the forum use the 'Platformer' behaviour instead. I assigned the Platformer to behaviour, set the 'Standard Controls' setting to false (essentially meaning that the controls for the Platformer sprite were disabled unless I simulated them through events); and lo and behold, the latent gravity applied with the Platformer behaviour was functional even as the sprite began to move.
However, from there, I ran into a problem with the Car behaviour that I used for the sprite's movement. There is a setting called 'Drift Recover', described within Construct 2 as 'the rate the angle of motion catches up with the object angle.' The lower the drift recovery value, the longer it takes for the angle of motion to catch up with the object angle, therefore creating the effect of drift.
However, for my intents and purposes, the drift recovery of the Car behaviour does not work. Setting drift recovery to 0 does prevent the angle of motion from catching up with the object angle; it does not, however, prevent the angle of motion from being moved. Upon turning 90 degrees in one direction or the other, the rotating sprite will drag the angle of motion with it, at which point the angle of motion will begin to turn normally.
Therefore, I had to opt for a different form of control. I replaced the Car behaviour with the 'Custom Movement' behaviour which, as the name suggests, allows you to program your own controls. One of the actions that this behaviour allows the user to perform is to accelerate a sprite in a certain direction. I set it to accelerate my sprite in the angle of 'Sprite.Angle'. This achieved a drifting effect, and the motion of the sprite was not affected by turning. The only way that the motion of the sprite was affected was by accelerating in another direction. When viewing this behaviour through the debugger, unlike the Car behaviour, it does not make note of the angle of motion, so I sadly cannot state what these controls to different than the Car behaviour.
[Perhaps the technical explanations should be moved to the development section once I begin working on it?]
Special Weapons:
An element that I want to include from the Ace Combat series is the use of multiple weapons- two primaries, standard missiles and a special weapon, and guns. At the moment, I don't think I have the time to develop a variety of planes for the player to use. So, for the time being, I will instead look at developing alternative weaponry for the player's sole aircraft. If I complete development with a lot of time and free events on my hand, perhaps I will take a look at the inclusion of alternate planes. For now, however, I will stick with special weaponry.
Before this point, I had envisioned a range of air-to-air and air-to-ground special weapons to choose from. Depending on which part of the mission you deemed would be harder, taking out the ground units or the air units, you would take special weapons suited to those engagements. It would be a trade-off, in a sense. However, due to the heavy cutback on aerial units in my game, I will instead have to tailor the special weapons strictly to air-to-ground engagements. There's no point in running an entire mission with essentially no special weaponry just for the final fight, after all.
The first idea for a special weapon that I had was an unguided bomb. It would be launched from the aircraft in an arc, affected by gravity, and explode upon hitting the ground or an object. Unlike the explosions that I had created for my very first project, 'Blue Wall', I didn't want my explosions to cause contact damage. Contact damage means extremely precise hitboxes, which would make for a very inaccurate weapon should the explosion be too small. However, causing the explosion to grow massive could lead to the entirely opposite problem of hitting too many enemies, on top of generally being an eyesore. Instead, I wanted to create a radius around the explosion; when an object enters this radius, it will be registered as hit, and the necessary events will follow.
There is an expression within Construct 2 known as 'Distance()', which uses the X and Y variables of two objects to calculate the distance between them. However, I was unable to understand how this worked in the first place, let alone how to calculate a radius using it, so I did not pursue this line of logic. Instead, I came up with a pseudo-radius using the Line of Sight behaviour with a 360-degrees cone of view which will damage enemies upon entering it.
Construct 2 comes with a variety of premade examples of various behaviours.
I modified the Line-of-Sight example to visually demonstrate the radius effect I described above.
Any pig beyond the Line-of-Sight becomes transparent; pigs within the Line-of-Sight become opaque.
The sole issue with the bomb as a special weapon is the fact that they are unguided. Unlike the missiles, which are guided by a lock-on system, effective use of the bomb falls down to guesswork. ACE COMBAT 7 uses a segmented, holographic line to depict the trajectory of the bomb in flight. I am unsure as to how I would implement this, however.
The second idea that I had for a special weapon in my game was a long range, air-to-ground missile. This missile would be fast and be able to target the enemy from an extremely long distance away. Unlike the bomb, which is designed to cause heavy and widespread damage at the cost of requiring you to get close, this long-ranged missile is designed with the neutralization of key targets in mind. It has far less destructive power than the bomb, but it allows the player to engage particularly dangerous units from a safe distance and take them down in order to move in for an attack.
However, to achieve an increased lock-on range means that I would have to increase the Line-of-Sight of the player's aircraft, as it is the Line-of-Sight that determines whether missiles are allowed to lock onto a target.
(22/03/2023): While thinking of ways to implement the Interceptor AI, I began to research the 'Array' asset, which is capable of storing information in a grid.
This video, created by YouTube channel 'Jerementor', guides the viewer on how to create a basic weapons select system using the Array. However, what caught my eye was the fact that they did not make use of several assets for each weapon. Instead, they utilised an all-encompassing object (OBJ_GUN) which contained the animations of all the weapons and used the Array to store weapon values along the X axis. They had programmed it so that the X value of the array was determined by a global variable, and that the animation of OBJ_GUN was determined by the X value of the array. This meant that upon changing the global variable, the retrieved X value would also change, and the weapon animation with it. [10]
This is a ground-breaking trick for me. Instead of having to design separate aircraft from the ground up, taking up lots of time and events to implement, I can use a single object for every plane with altered stats and animations depending on a global variable. I am unsure yet as to whether I will need to use an Array to achieve this effect. If I have enough time left over once finishing the prototype of the game, I will attempt to implement a second aircraft.
Miscellaneous Concept Art:
Prototype menu concept art, produced 24/03/23.
Flat colour background; minimal detail. Designed to be economic, can expand on later.
An idea struck me in the head as I was sketching out the concept. I chose the Interceptor jet as a placeholder for a secondary aircraft, but then I thought: "why not allow the player to use it?"
There are two reasons behind this. The first reason is that it is economical; instead of spending more time developing an aircraft from the ground up with its own gimmicks, I can use an aircraft that already exists in the game. The second reason behind this is that it adds replay value, a reward for beating the game.
References:
[7] 'Borderlands 2 Review'; Tom Francis, PC Gamer. September 18th, 2014. https://www.pcgamer.com/borderlands-2-review/
[8] 'Cel Shading - A Comprehensive Expert Guide'; Adobe. https://www.adobe.com/uk/creativecloud/animation/discover/cel-shading.html
[10] 'Construct 2: How to use Basic Arrays for Weapon Select! | Jerementor'; Jerementor, YouTube. March 17th, 2016. https://www.youtube.com/watch?v=Us6aTgpreQ4
[11] 'Ace Combat ZERO | Mission 7 | Bastion | Mercenary Style' Ace Combat Fan, YouTube. 3rd September, 2015. https://www.youtube.com/watch?v=QqQ1P66fvJQ
MOODBOARD:
MY THOUGHTS:
I do have my grievances with the pre-production process. Often times, it also felt like my ideas would come out of nowhere. For example, the idea for the flak cannon weapon was just something that came to me- it isn't something that can be traced back to an origin point, unless we consider the design theory behind enemy types as the origin point. I also found it incredibly time-consuming and stressful to explain my thought process behind every single gameplay idea, no matter how big or small. For example, changing the level of the game from a clifftop castle assault to an airbase raid. I explained why I changed the environment, but why did I change it to what I did? Why an airbase, and why is it in the countryside? Accustoming myself to the intense level of detail required to produce a satisfactory document has been a process that has taken a lot of time to achieve.
However, these grievances aside, I can see that I have made great strides to improve my planning process since my previous project, and in that I take great pride. Every idea that I have thought of, I have taken apart and analysed; I have considered my intent and the feasibility of said ideas, and I have altered/built from said ideas should I have seen fault in them. In taking the time to painstakingly detail every decision I have made, excruciating and exhausting as it may be, I have both laid a solid foundation for the development of my game and provided proof of my processes to the reviewing bodies in one fell swoop.