Week 13 - Final Week

Final Week

 The semester is over and this week is wrapping up the final edition of the Code. This week is all about polishing and finishing up any loose ends.

 This Week's responsibility lies within the Wave Announcement - a system that was formerly based on a "Print String" for troubleshooting purposes.

 To create the Wave Announcement, the easiest method (and least messiest) I assumed was just to create a new Widget with text boxes that got the Wave Number and printed it with the pre-existing Wave System.

The First Hiccup of sorts was getting the Wave Number (see above). Since the Wave Number count was saved in the Open Level Blueprints, it isn't easily obtained by the GUI (as Unreal doesn't allow you to "Cast to Open Level BluePrints", As such, to rectify it, the ThirdPersonCharacter gained a Wave Counter (which isn't good programming practice usually, but we were in a rush so...).

This new Player Character Wave Counter was able to pass the Wave Number to the textbox thus allowing it to show.

The next problem was that the only way to delete Widget (or Widgets) as we found was the "Remove All Widget" node. It would remove all remove all current Widgets which includes any pre-existing HUDs. Since time was of the essence - it was decided it would be faster to just recreate the HUD.

 With that, the last bits was compiled and the program worked well - overall, everyone had last bits of tinkering to do (albeit mostly minor issues which was good). There was a little problem with version control (When I sent my Unreal File over, Mickey managed to constantly crash it - so it had to be redone on his version step-by-step).

Because of the rush with the Final Presentation on Friday, we couldn't really experiment with the different methods (or google search different ones). While this was happening, the designers were busy working on the Game Design Document - so all I had to do was put together my Portfolio which was all the coding done this semester.

Week 12

Finalizing the Game

Summoner's Rift - League of Legends

 This week, the most important job had to be finished (also presumably one of the harder parts to code) - The Wave System Implementation!!

 While it was touched on during the previous weeks (as a Core Mechanic), it was never actually fully implemented and left as a String based system that didn't really affect game-play (it was like a game of its own).

 Blocks of Code were commented as "Insert Minion Spawn here" were never actually finished and the entire Wave System was left quite raw. So obviously the first thing that was attempted was to hook up exactly the way the blocks of code were commented -- put minion spawn here etc. etc.

 But unfortunately... that didn't exactly work...

This was because Julian's Minion Spawning Scripts happened on event ticks - meaning that every frame that the game runs, the game checks if the number of a minion spawned equalled its max wave - if not summon another one.

I had my "raw" Wave coding under a Custom Event that was called once instead of every frame. This Custom Event would've summoned X Minions were X is the Wave Length rather than spawning it one by one as in Julian's code.

It also so happens that due to the way Custom Event works in Unreal, I also could not connect it to the Event Tick Node. This meant that I had to completely redo the current Wave System to accommodate.

That had a fairly easy solve which was to imitate Julian's code and move the Wave Checker into the Event Tick - so every frame of the game, the game checks if every monster has been killed, if so - increment the wave and reset the variables.

But there the second problem arose... How to count the Dead Enemies.

The first way was of course, a series of simple steps

1. Set an Integer called Enemies Killed
2. In the Enemy AI, make it so when an enemy is killed, increase the integer
3. If the Integer matches, start next wave

 But... coding never is so nice. To obtain the when an enemy is killed, you would have to cast to the Level Blueprints (an almost infamous problem at this point). With Unreal being quite strict on not allowing you to cast to the Level Blueprint (preferring you to use a much more painful Event Dispatchers which are complicated and frankly never work...), we had to forego this method.

The alternative was to put the Enemies Killed Integer in the Enemy AI Script and then collect it (calling it) at every tick in the Level Blueprints. This was met with several issues again...

1. Flawed Logic - since every enemy is its own being, it doesn't share its variable. So every individual enemy will have 0 enemies killed, and when they die, it increases to 1. That doesn't mean that every enemy has their count increased... just that individual monster. 
2. Casting to Ironshell AI -- Casting is used to obtain a variable from another script (in this case one of the Minion's AI). Unfortunately... Due to the way it spawns as a Pawn, there was no Object we could find to link with it and we could never call it.

The Solution

 It actually came to me while playing League of Legends. Every player had CS or "Creep Score" which indicates the amount of monsters killed in that game. Since I knew for sure that casting to the Player is possible (and the go-to method for all coding in Unreal), I ended up creating an Enemies Killed variable in the PLAYER'S script. 

 This acted as a "Creep Score" of sorts and every time the Number of Enemies Spawned equalled the Enemies Dead -- Start next wave, reset all the variables.

 While definitely NOT the hardest Code I had to do this semester, it was one that required a bit of thinking to figure out how to piece it together. As quite an important part of the game - a ton of play-testing to make sure it worked correctly was done. Minions had to spawn correctly, Wave had to increment, there had to be a Delay between the Waves... It all had to come together.

Fortunately. It did.

Week 11

Death Do Us Part!

Marvel Punisher

 This week - I got assigned to handle the Death Conditions - which means dying from Turrets, Minions, Environment Effects or just jumping off ledges. It's pretty good as it is a busy week from other subjects.

 So the first thing I did was to figure out the different ways people are resetting the Game State (so when you "Gamve Over!" you had something to fall back on.

 I found that most people utilized an "Open Level" Node which pretty much loads up another map. The main concern I had (before testing it and also why I googled for more ways before trying it) was that Opening a Level was used for a player entering new Levels as well (such as Level 1 -> Level 2) which meant variables could be saved such as Gold.

But... after testing - this was found to be a near non-issue so I decided to press forward with it. And as to provide player feedback - a very basic GUI was designed for the Game Over Screen.

 It was super simple - if you died - press the Restart Game button to... Restart the Game! Nothing much to say.

 So, the only coding left was when the player died... At first I thought this HAD to be handled in the Level Blueprint -- if a player reach 0 health, change the game state. But as I began coding it - I quickly figured out a faster and perhaps more efficient way of coding it.

 It was an EXTREMELY simple -- if the Character itself is destroyed (not it's health equalled to 0), create the Widget. After all, if the Character is destroyed, the player can't do anything EXCEPT click on the widget.

This of course, needed me to do a little more tinkering in other scripts (making sure that when enemies attack the player, if the player had 0 health, destroy him instead etc.). But the Script compiled and functioned as planned.

However, when the Enemies killed me, I could only observe as they continued to drone on mindlessly towards the Nexus and I remembered an old game I played. It's Game Over Screen significantly slowed down time as the minions continued moving in the background. It made it feel like the enemies was slowly stampeding on your corpse and I thought it was a fantastic idea.

With that, Time Dilation was added, it made the game progress in an extremely slow pace which meant that the Game State was not truly halted (which didn't matter since the Character was dead).

The only thing I didn't manage to hook up doing the Game Over State was the Environmental Effect "Acid Rain" which Mickey was working on this Week. Aside from that - this week was more of a relaxed week with quick rapid coding (which I was quite thankful for).

Week 10

Waves... Waves... And More Waves!!!

Picture from League of Legends

This week, a fairly important aspect was given to me which was implementing a Wave System. This is one of the Core Mechanics of our Game and had to be tied up this week. As such, I was in charge of getting the Wave system itself while Julian had to handle the Minion Spawn.

 Based on the Skype Discussions, 2 options were thrown up for the Wave System.

1. Waves Increment (Minions spawn) after all pre-existing Minions have been killed
2. Waves Spawn after a certain set time - this imposes a penalty if the player doesn't kill all the minions in time.

Weighing the Pros and Cons of each option -- the team decided on the first option. This matches the style of more traditional Tower Defences. This allows a more relaxed pacing of the game instead of needing to constantly worrying when the next wave would spawn.

 With the Wave System "style" being chosen - Code has began to be processed. Unfortunately, after starting the basic "At the Start of the Game", I remembered that the Spawn Minions coding has not yet been implemented (thereby cannot be used).

 As such, a "substitute" set of codes was used which involved setting an integer called "Number Of Minions Available". In addition, a String shows up which presents to the user as a "proof" that X minions have spawned. This allows troubleshooting for future methods that will be implemented in the Wave System.

 This Code System should be replaced with the "Spawn Minions" code upon completion and was commented as such for other programmer's awareness upon implementation.

So, it's time for the actual Wave Implementation...

Like the design we agreed on, we check if there are any enemies still alive before initiating the Wave Incrementation system. As a Custom Event, the plan is to attach this to whenever a minion is killed (in other words, if a minion is killed - run this event).

If there are no enemies still alive - run a String announcing the Wave's end, increment the wave and respawn the enemies. Again... with the Spawn Minions being inexistant, this Implementation was all code-based.

Unfortunately, since the "actual" minion spawn hasn't been coded (which has been a fairly major issue when creating this code). Another method is needed to be made to reduce the integer created earlier (Number of Minions Spawn) to test if when the Number of Minion Spawn reaches 0, the wave system is activated.

Another more simple event based on a key-press ("V") was formed. All it did was "kill a minion" and reduce the Number of Minion Alive integer. Following this, it calls the custom event above (that is the actual Wave Implementation). 

This worked perfectly and while it wasn't the Wave System we all dreamt of - it's definitely a step in the right direction and that we had some idea where we want to go.

Week 9

Turret Fixes Galore!

Image from Halo

 With last week being... quite the disappointment in terms of production and this week being the first week of putting everything together - We had to work extremely quickly to get things functioning. Tons of Googling and Placing Towers YouTubing were done across the weekend to get the Tower Script working.

 I drew a lot of inspiration and code ideas from the "Unreal Engine 4 Simple RTS Building Placement" Video by pally qle.

 While the video's code didn't fit our needs exactly, I had to play around with the code to allow it to fit our needs a lot more... Thus coming up with the following code:

 This code was brought to the Programmer's Meet (where everything comes together and all bugs are fixed) where we decided to add various bits to the Spawn Towers bit based on Julian's code (Player value implementation).

The following code was added to the bottom of the Build Turret Code which was worked on by all 3 Programmers. This uses Julian's code which implements the player's Gold and checks if the player has enough gold to build the turret in the first place.

Overall, we've got the Player setup quite well this week - They can move around, build turrets, shoot and has values for Gold and Health.

Week 8

Build Them Up, Break Them Down!

Image from Star Wars

 This week was the first real week of coding!! The first job for us to do - we have to get the Character set up and ready to go! 

 With Unreal Engine automatically handling the Character's Movement Scripts - we split up the remaining Character-related things such as Character Shooting Scripts, Turret Scripts etc.

 In my case, I was in charge of the Tower Placement Script. This is one of the harder portions of the script (especially since I'm using a new Engine which I'm not particularly familiar with). As such, the first thing I did was tons of research.

The path began with following Surface Tension Studios' Tower Defense Tutorials especially the one titled "Placing Towers". Unfortunately, it was the only video in the series that was mute (due to an error on the poster's end). This made it very time-consuming to follow the coding and try and figure out what the coder was doing.

 In the end, even with all that effort - The method used was simply overly complicated and it couldn't be used... However, on the way, a lot of knowledge about coding in Unreal was obtained through sheer trial and error.

 Since next week, would be the first week all the Programmers are coming together to put their pieces together, a lot more work would have to be done to figure out how to get the code working.

Post-Desk Critique Thoughts (Week VI)

Post-Desk Critique

   Tighten Up Before Viability Presentation

This Desk Critique went slightly better than last week... The general consensus was for the group to do more Art and a Blow-by-Blow to understand our game better.

We've begun to use a Trello Board to record what needed to be finished/accomplished. With the Presentation coming up - we have a good feeling we can nail what is required to be done.

Post-Meeting Motivations (Week V)

Post-Meeting Post
   Motivations

 A rather short post, but after the meeting - we needed to shape up our player motivations (evidenced by our poorly defined Target Audience). The team agreed that we'll come in to play Dungeon Defenders II to gain motivations for our Tower Defense Game.

These Motivations were summarized as....

1. Customization (Immersive Gameplay)
   Making a Character feel more individual allows a person to have a “Connection” to the Character (Immersion), make the Character feel more “them”, to roleplay. Even upgrading weapons and utility makes their Character resemble the player more -- supports their “playstyle”
   Related Player Motivations: Creativity; Immersion; Mastery
   
2. Dominance
   The ability to defeat large amount of enemies quickly; grants the feeling of dominance and superiority. Increases moral of the player, making them feel good. Despite being able to easily mow down enemies; due to the sheer volume of the enemies; some make it through and the turrets alone are not enough. As such, this allows the player to feel dominant but not to the point where the game is too easy. Thus the player likes this aspect as it allows them to feel accomplished and powerful yet not feeling like it’s simple.
   Related Player Motivations: Action; Achievement; Mastery
   
3. Achievement (Strategy-Based)
   Surviving a wave, thus enabling a break signifies that a player has held out successfully. This is enforced by certain levels displaying a splash screen of a new enemy reinforcing that the player is “too good” for the previous level and is promoted. Thus Players feel like they got “promoted” and they progressed further in the game. This shows that their playstyle (no matter how dumb it may have been; or they think have been) to have worked for that level and being rewarded for it.
   Related Player Motivation: Achievement; Creativity; Mastery
   
4. Achievement II (Character-Based)
   Levelling a Character/making them stronger is rewarding for most players. The heroes used in combat gains EXP making the player feel rewarded and have incentive to “master” a character. This links to the immersion of the Character (above) as they are more invested in the character. For Achievement players, they enjoy the stronger characters as it will enable them to accomplish their goal to achieving X.
   Related Player Motivation: Immersion; Mastery; Achievement
   
5. Social Aspect
   Working with people to achieve things in the game such as finishing a difficult level or working together to lag people with fun troll spinning training Dummies. Teamwork allows people to work together to achieve a common goal which is enjoyable as people join in to see a “project” come to a fruition. (Completionist/Achievement)
   Related Player motivation: Social; Achievement
   
6. Different Styles of Gameplay Some Characters are considered “Builder” Characters as such are only there to build and abuse their unique towers before switching to “Combat” Characters. This allows a player to utilize the “best of both worlds” and enjoy both/different playstyles Related Player Motivation: Creativity; Mastery

Working on Feedback (Week IV)

Working on the Feedback Given
  Week IV

 After the Presentation where Ace Gaming sought the Green Light, a lot of feedback has been received to help the game's overall design.

 To help solidify the game's identity and the game as a whole, the team decided to build a Game Design Document. This will enable us to clearly identify the different portions of the game in detail - Character, Turrets, Map Design etc.

 Numerous Skype Discussions were done which concluded in the Prototype to really show the diversity in environments and Character pools. As such, an Egyptian-themed Pharoah in a Jungle Themed Level seemed as the most efficient method of proceeding.

 Following this, we decided to focus and concentrate on the Player Experience including the various Motivations, Emotions and Rewards that the players will have receive.

 These Player Motivations will be a big part of what makes the game enjoyable or not - and it was heavily discussed overall. 

 The Emotions were fairly agreed upon to be very in-line with the Powerful and Emotional Quadrants of Gamasutra's Emotional Circle

 Following this - we have a pretty solid idea of what we want the game to achieve, and its a matter of tying all the ideas and concepts together in the Game Design Document. The team will discuss the Character Skills and the Towers decided upon tomorrow as well as general Level Design which will finish up the Game Design Document before the Desk Critique

Week with the Voyagers (Week III)

Voyagers

 Decided to join Ace Gaming - Voyagers (Formerly Depth; Depth of Insanity)

 A 3rd-Person Tower Defense with a Hero added (similar to League of Legends). It's been a rather busy week after the feedback obtained from Week 2 from the Tutors and Colleagues-alike.

 The general consensus on the game was that:

• We weren't clear on our set path/goal - i.e It could be this... or that
• We didn't apply Theory to our Designs

 This was proven correct as the team later discussed everybody not being on the same page in term of the game's design. As such; multiple Skype and in-person meetings was planned upon (almost a meeting every day of the week).

Things that were the focus of these few meetings were to really nail down what the designs were and how/why we came to those conclusions. In particular, I took a look at the various Game Theories to bring up to the meetings to help solidify our ideas and the eventual presentations.

The Game Theory we looked at included: 

• Player Experience - This was the main factor in choosing between First and Third Person Perspective;
• Gameplay & Core Mechanics - Mainly Challenges (Types of Challenges); Rewards, Balancing Effects, Decision-making etc.
• Player Types
• Narrative 

 With the Game Theory, the team solidified the Design soundly and created a Proposal (with aid from the Notes on Blackbeard) that should be very well received on Friday!