Last week of this semester update

So the past couple of weeks have been relatively light in terms of workload.  The team discussed some potential changes to our level progression but we decided to postpone the work until next semester and specifically, after all the presentations.  After all, we didn't want to show off a potentially broken build.  Most of my work focused mainly on more work with the main menu.   The trap store in particular has been redesigned once again.  Previously, we planned for a character system and the players chose the character they want in addition to a list of purchaseable traps associated with the character.  However, we've decided to throw away the character system and so, the screen space is solely used by the trap store.  The major change is instead of a button for each trap which encompasses the trap name, the trap icon, the trap cost, the trap description, we simply have a button which shows the icon, the name, and the amount the user has of a particular type of trap.  A space is allocated on the left hand side which will show the trap cost, the trap description, and an in game image of the trap when the user hovers over the trap button.  This helped make the ui feel less cluttered since the screen is no longer filled with paragraphs of text constantly.

The next thing I also put in was a simple hint system that cycles during the loading screen to help out players.
I made a string table in Unity's editor so Troy and I can manually update the text fields without the need of going into code to change everything.  The file is saved out into a xml and loaded back in on startup.

Update before thanks giving.

Since IGF submission, we haven't done much in terms of development for Dodos.  We met with engineers from the Air Force a couple weeks back and this past week, we attended the prototype presentation for the other cohort.  I did make some adjustments to our camera controls again after Troy, Charlie and I talked about making the left button perform all camera controls.  The problem arose when we tried to pan while we had a trap selected and placing a trap and panning are mapped to the same button.  So instead, we decided to imitate Starcraft's camera control.  To pan, you now move the mouse towards the edge of the screen you want to scroll towards.  This upcoming week, there're a few bugs I plan to fix.

Progress after fallbreak + IGF

So for the past few weeks I've been polishing the game up and readying it for IGF submission.
I've been mostly working on UI and adding new art to it as I receive them.  I redid the end game summary screens to work with EZGui and the new UI layout.  I remade our camera controls to make the game easier to play.  Holding right click and moving the mouse or pressing down on the arrow keys now allows the player to pan around, and the mouse wheel and the plus/minus keys allow you to zoom in and out.  Another thing I added was an animation script that allows the trap to play an animation when a dodo collides with it.
IGF submission is Monday and so I don't have any set tasks but we're at the state of "Get whatever we can into the game."

Update time! Revising features.

This past week we showed the progress of our game and decided to change some of our current mechanics after some discussion with Roger.  There will now be a meta game based around currency and so levels will take money to unlock.  The trap system will also be modified to deal with input output so that aiming and chaining traps to create combos will be easier.

The past week I've been finalizing the profile system and will continue to change the system to deal with the new meta game.  The profile system needs to keep track of the levels that are unlocked and I will need to create the UI to handle that.  I need to edit the level information to store the cost of unlocking a level as well.

9/17 Update.

Hey guys.  It's been several weeks since the start of fall semester and I've been quite busy.  For the past few weeks, I've been working on a pretty big feature addition into our game.  The overall theme of the feature is customization.  The first major addition is a game store.  For each level, we give you an initial set of traps to get you started.  During the game however, you can use the points you have accumulated to purchase additional traps.  Because the score acts as a currency system, whatever is left over is transferred to your overall profile.  This brings me to the next feature I implemented.  The game loads up a profile data file for the player and it keeps track of the total score accumulated, levels that a player has beaten, and the characters he has unlocked.  The profile is saved out into a binary data and is read back in at the start of the game.  The levels unlocked information is also vital to the traps in our game.  Traps are unlocked as you beat certain levels so we can slowly ease the player into our game.  Presenting the player with so many traps all at once causes too steep of a learning curve.
To help facilitate this major feature, I've created two tools to help the designer improve their productivity.  The first tool I created is the GlobalItemsDefinition tool.  This tool bundles up all the important information into a single gui window so they're easily changeable.  For example, the designer could simply add a new trap to the global list by clicking on the "Add" button and change the name of the trap in a textfield.  There are information for store prices, the level at which a player unlocks the trap, and even the models of the trap is adjustable in this tool.  Instead of looking for prefabs and going through code everywhere, the designer simply drag and drop the model they want onto the prefab location in the tool and the tool will automatically set up the connection.  All of this information is then saved onto an xml file and read in when a game begins.
The second tool is a level specific editor which will allow the designer to select the starting traps for each particular level.  They are also able to alter the number of a certain trap type a player gets.  This information is also saved to an xml file and read in when a level needs that information.  These two tools help consolidate several different systems that all uses traps such as the inventory, store, and the state manager.
Currently, I am working on the outside game store that will allow the user to purchase traps before the game starts but at a higher cost.

Ai dilemma and sprint 3

So initially we were going for an implementation where additional King Dodos would be created once a group of dodos branches off. However, after talking with Kamron over the weekend and then with Troy and Bob during class, we've decided to do a single King Dodo implementation instead. Due to the short development time we have until alpha, we are going to move multiple King Dodos into the beta if need be.

For this next sprint, I am creating the single King dodo implementation as well as an EMP "forget" trap which causes the king dodo to forget everything it has learned. I will also be reworking the inventory system a little bit after discussions of traps. We observed that each trap is more of a category as opposed to a single trap. For example, a projectile trap category would contain a cannon trap and a cannon + trigger trap. Both are accessible as a dropdown tab after selecting the category of trap. So I will need to alter my code and add an additional layer of complexity to my inventory system

Sprint 2

For this second week, I've finished restructuring the majority of the backend to centralize things a bit. This includes having a dodo manager systems that allocates all the dodos initially so we don't have to allocated dodos during run time. This also makes life easier for the garbage collection because all the dodos will be deleted after the game not mid game. In addition to memory optimizations, the manager also contains a list of squads. These squads will be used for the branching of dodos and the idea of a king dodo leading the following dodos to safety. A major concern we had was figuring out how to simulate the dodo's ability to forget, the API only gave us the ability to add penalty cost to a particular region and we were afraid to change variables directly because we don't know if any other variables or processes are dependent on it. Luckily, I have found a way to backup the state of the entire grid at a certain point in time and can easily revert back to it as well. This ended up solving two problems, the EMP "dumb" blast we wanted to implement as well as dodos unlearning when the king dodos die. Unfortunately, there are several technical problems hindering our implementation. The most significant one is determining what it means to be a new branch and when is it appropriate to have a new king dodo leading it?

I was quite happy about was the inventory system that I finished. I've exposed numerous variables out to the designers and was very happy to see Eric easily adjusting the inventory to fit his particular need.

Sprint 1 Thesis Project

For this first week, I will be handling some of the backend systems such as a scoring mechanism, timer and inventory system. The difficulty of these tasks is not from implementing the logic for them but figuring out the best way to create methods, the parameters associated with them as well as the amount of flexibility we want to give to designers. Usually these aren't difficult things to deal with but since I have absolutely no idea how other systems are being built and how much functionality we actually need later on, I've tried to make methods take in as many parameters as possible and only kept a minimal amount of member variables. An example of this would be the scoring system. There are several factors that contribute to a score: Time, Dodos kill count, and combos. Because I know absolutely nothing about where the rest of the systems are, a method that would calculate the score base on time would taken in the time elapsed and the maximum game time allowed to apply its algorithm appropriately. There are also several properties within the scoring system I've made available. These mostly contain multiplier values or score values that a designer can alter during play sessions that are used by the scoring methods to calculate points.

One issue I have with Derek Higgs(Engineer) is his hate for inheritance. I have no idea why but when we talked about implementing trap types, I suggested creating base classes for the three types of traps: kill traps, directional traps, environmental traps. He quickly disagreed and told me to stop using inheritance. My problem with never using inheritance is that there are basic functions that each one of these traps should implement. For example, by making an abstract kill trap class and forcing all inherited classes to implement a function called Kill, the readability of each file improve dramatically. There are about 6 kill traps in total and imagine if there are 6 differently named functions doing the exact same thing! This would make going through code so difficult especially for someone who has not touched the code and is trying to help debug something. In the worse case, there may be 6 differently named functions that actually does the same thing but the programmer has to spend an additional hour just to figure out what the traps are doing and where it is doing the "killing". But forcing all the kill traps to inherit from this base class, it standardizes things and when someone has to look at the kill code, they can go immediately into the kill method without reading through the entire code file. I think I'll will have to talk with Kameron about this some more but this can potentially be a large problem down the road especially when we try to debug things and/or we are trying to change a functionality of a trap.

sprint 0!

So for this pre sprint, I've been looking at other ai pathing engines. Specifically, I looked at Angry Ants, Simple path, and Rain one. Because the ai pathing is the most important component of the game, we wanted to explore and see if other engines might be more advantageous. In the end, there are pros and cons to all of them.

First, besides Angry Ants, the other engines have no trial versions(was not able to find it) and will cost us money to just test it. Second, Angry Ants and Rain one does not provide the source code to their engine and gives us a dll instead. This makes these two engines not worth looking into because we want the capability to alter their code to make our game work. Third, we have already figured out how to access and edit node costs in the current engine to affect the behavior of the Dodos. This pretty much means we know our current engine can handle what we want it to do.

Even though we haven't given a 100% approval stamp to the current engine, I think once our entire group meets again in a couple weeks, we'll be starting the game using what the prototype used.

Finishing Prototype

So on wednesday we made our presentation and the professors are deciding on which 2 games to use for the year long project. Before I forget, I would like to mention my past 2 weeks of contribution to our prototype. I added several gui elements indicating the attack range of turret (displayed as a red transparent circle underneath the towers), and a health bar for each of the turret(displayed right below the turret). I also helped make a couple levels and one in particular was used by Charlie for the presentation to show the various tactics to beat the level. In this case, drawing a straight line from start to the end goal was cause the enemy turrets to completely destroy your units. If instead you drew circles around the turret to create a swarm effect, you minimize your loss and enables you to complete the level.

Progress

So for the past week, I added an end goal state where the user must get a certain number of units to this end state. By reaching the minimum amount of robots for that stage, you pass the stage and can advance to the next level. However, the point is to get as many of your robots to the goal so any additional robots will help increase your score for the level.

Another thing I did was to implement a resource system as well as different types of robots and their behaviors in the gui system. The player will have the option to choose between different types of robots with different stats such as a more mobile robot with less health point. There is also a gui element that allows you to pick the type of behavior you want the robot to have. If you feel like getting rid of a turrent, you can simply spawn robots with the aggressive behavior and they will attack any turrets within their range.

I have also increased the amount of spawns per factory and added options to increase the amount of spawns and gave the robots a variance in their speed for a more swarm like feel to the robots.

Lastly, I've added health bars to the turrets so the user has some kind of feeback to how much damage the turrets have taken.

Flux Disposition prototype!

For the next month, I'll be working with Derek Higgs, Charles Mimnaugh, and Dave Gilder on a game called Flux Disposition. This is a tower defense type game but not really. The idea is that the user will have control of the mobs as opposed to the towers and the goal is to get a certain amount of your robots pass these turret towers.

For this prototype, we will be using Unity3D and C#. I am currently working on a factory object. Essentially, these factory objects each have a path system which the robots that the factory is creating will follow. We have decided to allow the user to draw a line on the screen to represent a path.