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