GDW Final Submission

So with the conclusion of this semester, we pretty much have the game more or less where we wanted it to be. To break things down with the design document in summary, ENDLESS (our game's title) is a top down shooter that involves having players survive 'endless' waves of robots that are trying to take over the world.

With the start of our design process we thought of trying to keep things simple as we had decided to start completely from scratch since the game we tried to piece together in the first semester didn't work out too well for the result. This time around, we thought that without too many limitations to what we could do with designing a new game for the semester, the idea of a top down shooter seemed to fit the description the best.

Originally, we had planned out all of the necessary designs within the first month with concepts of what the characters may look like, what the level layout should be, as well as having a paper prototype that would be a miniature guide in terms of where we wanted to go with this and what abilities that the player characters would each be able to perform. This ended up needing a lot of tweeking in the design as to cut down on certain things or change the abilities of each characters. This was mainly done to the engineer class mainly due to being unsure as to whether the original idea of letting them place turrets would be overpowered, or to give them a shield or the ability to control an enemy unit.

So with the paper prototype done, it involved quite a bit of play testing and tweeking as we went along to determine how balanced the game would be. We figured that the players would only be able to move about 3

spaces any which way, so long as it wasn't into a blocked path. Enemies would continually spawn at the end of each player turn at locations on the grid determined by rolling dice. This included colour coded enemies to determine the type of enemy (speed, tank, power, which have their own methods of movement as well as numerical values

associated with HP) that would keep the game entertaining for those playing it. To keep things balanced, die rolls are used to keep it as a game of chance as well as involving some form of strategy depending on the number of players playing at a time. Players will be able to have 1 turn each consisting of movement as well as attacking which can be done in any order in their respective turns. When an enemy dies, the players will

gain points represented as 'kill counts'.

As far as the in game tech side of things go, more or less the game functions the same way except that the AI enemies will target the players and are not limited to the movement they make or too large or a range restriction when the enemy attacks the player. The player is assisted by other characters as well which will aid the playe

r in surviving longer in the game. Although the game doesn't technically end, enemies will get stronger each wave as well as more enemies will spawn. At the result of the ending of the game, the idea is that it provides a sense of

a high score that they achieve through the game to allow for some competitiveness. Strategy still becomes a factor in terms of survival in the game, hence the need to provide limitations such as cooldowns of skill use, certain rates of fire for their weapons and any area of effect skills.

Although there wasn't much testing done with the paper prototype, based off of the demoing of the board game, the idea seemed to hit it off somewhat well in terms for those who were into complex board games, although this

is the case some issues that were noticed was that the medic is the key player in the game. Players who've tried this out did manage to survive longer with keeping the medic player alive, however due t

o the result of the idea that the player will eventually lose, none of the play testers there believed that the paper prototype was overpowered for enemies which came as a surprise. On the digital version of our game, not much testing was done with this either, most people found it interesting aesthetically due to the models for the

environment. Most found the game to be pretty challenging so it's probably something that might need to be a bit more balanced out in terms of ease of play-ability with the difficulty of the game's default being set too high.

With the group Slightly Toasted, these are the following team members who worked with the development of the game throughout the semester:

Curtis Hanna - A 4th year student who is currently taking the game design 2 course who worked with creating a game paper prototype and designing the board game for ENDLESS

Kevin Astilla - 3rd year student who is the team's lead modeler and artist involved in concept art and modeling the player characters

Patrick Kwok - 3rd year student as lead programmer for the team in charge of setting up base coding and game play for use

Victor To - A 3rd year student who worked with being an assistant modeler, animator, minor programmer with getting the characters rigged, the modeling of enemy mobs and network coding for the team

Winson Ng - A 3rd year student who is the team's assistant programmer and modeler working with networking and rigging of the medic character

Tuo Xiao (Stone) - level designer, artist and modeler

HUDDY HUD HUD

these are the final results for the heads-up display (hud) for the game endless.
first well talk about the in game hud.

1. this space in the hud shows the current status of your AI/online team mate in the game. it shows the current health and the level/rank. it also states what type of class the team mate is based on the logo. if the logo is a cross hair then the team mate is an assault and if it is a first aid cross then it is a medic.
2. shows the timer of the game. since the game is more on survival we thought that a timer will be a nice idea in the hud. it also motivated the player to keep playing the game because the player sees the progress of his record.

3. radar shows where the enemies are right now. the radar is steady, means that the radar does not rotate. the radar always points to north.

4. this space states the life of the the players character. and under it is the logo for what rank the character is. we used the ranking logos that were used in the military.

5. finally this spaces tells the player the ammo he/she currently have. it also tells how many special action that the player has.


this is the game over hud. the background is not really dark but more like the environment of the game turns dark then this pictures fades in. the score is shown and below it the time on how long the player survived is shown. the only buttons that can be clicked is the restart buttons and the quit game button.

the main menu was too big to be uploaded so i just had the buttons as the sample
in looking at the buttons, we plan to show a sci-fi theme in the menu. the menu is more like a cube. one of the our colleagues mentioned that the idea is similar to the game cube options menu. even though its not an original were still going to keep it because it looks cool.

GDW Status Update

Since everyone seems to be forgetting about the blog all the time I will do the post this week and give an update on the various areas of the game and where we stand right now. (And also because I haven't done a post on the team blog for a while now :P )

Art: All of the art assets are done now. The artists are working on polishing them so that they look better. The artists are still discussing whether or not to add another level into the game due to the time constraints. It would ruin the game if the player were to be in a beautiful world in one level and then in the next level the level looks like poop.

Sounds: The sounds are approximately 90% done. Hopefully we can finish recording the sounds by the middle of the week and have them edited and ready to go by the end of the week. The other sounds that we have recorded previously have all been edited so they are ready to go. We are however, still discussing whether or not we should throw in a few variations of each sound so that the player does not get tired of hearing the same sound again and again.

Business: The requirements for finance have been taken care of a few weeks ago and it is only a matter of submitting it this week. Nothing special.

Networking: Networking is probably the area that is most behind right now. All of the basics have been taken care of and it is a matter of applying it to the game and testing to make sure that the dead reckoning works.

Programming: The game has been programmed for the most part and a lot of the stuff is already in place. Now that the assets are starting to become available we have loaded them into the game and in the process of adding the other required components and testing to make sure it works. One problem we have right now is the lag due to the number of enemies in the game. We are going to try to make the game multi threaded so that it will run a lot smoother. Hopefully we can have this ready by the time the game con rolls around.

Prototype3 + GDW

So with the new prototype assignment to create a game based on some details off the website link. We decided to go with the idea of the Action survival horror genre that includes bowling as a mechanic. We thought that with the idea here it would allow for more time to get a game to be a bit more polished. How we decided to plan for designing this type of game based on the specs given was that we would stick with a theme that most people would be familiar with for a survival horror game. That would end up being the traditional zombie apocalypse idea that most people are fond of. By the element of having to include bowling as a mechanic to the game, we also thought that it would most likely have to contain some elements that people would also associate bowling with, hence we considered of shooting bowling balls as well as having numbered lanes incorporated with it.

How we planned it out to work was so that there would be a total of 6 bowling lanes. Zombies will spawn on one of the 6 lanes based on the number rolled on a die. The player will be placed on the opposite side where they too, will also need to roll a die to determine which lane they will be shooting the bowling ball through. This was a means to allow for more of a game of chance to keep things more balanced with the game so that none of the sides would be too overpowered.

After the player shoots the bowling ball down the lane, if there are zombies in that lane number that’s been rolled, the first zombie closest to the player in that row will be removed. If in the case the lane is empty, nothing happens and the player’s turn ends.

Following the player’s turn ending, each of the zombies on the field will move 1 step forward, and will have another zombie spawn on the field in the back most row decided by a die roll once again. The game will continue on until the zombies make it all the way to the other end of the field.

After planning all of these things out, we decided to try and test out the idea on a small scale paper prototype to see how long and how well the game will work. Surprisingly it ended up more or less pretty balanced on both ends due to the chances involved in rolling a die. Although the player in a sense is destined to lose in the end, we found that it’s probably more than enough to try and get the player to keep playing since the game more or less ended up lasting for a good 10 minutes or so on paper.

Although there might not be too high of a replay value for the design in general, it more or less seems that it may be something that could be of interest to some players in terms of simplicity and things they may be familiar with. The idea was so that players wouldn’t be too overwhelmed with what they can or can’t do but it might be too restrictive as the only control they have is a die roll.

For the GDW side of things, it's looking like we're near the final push for the current game, more or less all the assets needed are in for use such as enemy models, the level and textures so far. A good chunk of the coding is roughly 90-95% done as well.

GDW - Progress Update

So far with the past few weeks, we more or less finalized most of the designs we needed to have in place for the coming weeks. In terms of models, we're at about 60-70% completion in terms of having all the models built (so far enemy models are done as we've decided to limit the maximum number of enemies we should have to allow for more time with other requirements as well as the level). What remains from the art/modeling side of things is the texture mapping and rigging phase in order for all of our model assets to be completed. In terms of the requirements that are set out, the networking aspect has been implemented into our current base and seems to be working, it will be a matter of getting the actual functions needed to update the info sent and received by the client and server for the player and enemy positions as well as dead reckoning.

As for the sound that we plan to have in there, we plan to start recording sound effects this week to get that out of the way, though we’ll be required to come up with a list of sound effects that will be needed so that we have a better idea of what still needs to be recorded/generated.

For the programming side, we more or less have the base of what we need for game play in terms of bullets/projectiles, enemy and player AI and path finding. So we should be able to get everything up and going with having an actual prototype soon.

What currently remains to be done so fare are completing the rigging of player character models, texture mapping the assets on the modeling/art side, for the programming, it’s a means of creating and testing the functions for dead reckoning and getting those working/tweeked for use.

Board Game Balancing

Short update this week, just about the board game prototype and the changes made to it. The biggest change is to the turn based structure: we are making it so that all the players take their turn at the same time. This will make it a closer imitation to the real time video game version, and allows some more strategies.

There is an obvious dominant strategy to our game as it stands now. That strategy is to race to the middle of the board, where there is a corner that enemies can only come at the players from 2 directions. One of the directions can be blocked up using the Engineer's special ability, and the other direction can be covered fairly effectively by the Assault, Sniper and Engineer shooting enemies. This also makes it so that the Medic spends their every turn healing the player who needs it most.

To help make playing the Medic more fun, we were also thinking of changing the Medic's special so that it heals a set number of hp, instead of full recovery, and allowing the Medic to shoot that turn as well.

And lastly, the blue enemies are useless. The way the game is made, is that Red's do 2 damage, Green's move 4 tiles and have 10 hp, and Blue's have 30 hp (where a hypothetical blank enemy would have 1 attack, 2 movement, 20 hp, and 2 range). This makes them have only one use, and that is as a shield for the Engineer to capture and block off that entrance. Maybe giving the Blue's longer range on their attacks would make them more dangerous. The proposed change to Blue's is to give them the base hp but 4 range on their attacks, this would force players to leave their corner to attack them, adding another element of risk and choice to the game.

a slightly toasted update

With everybody in the group busy pulling all nighters trying to finish the piles of assignments, the group has only made a little progress in the game over this past week. Here are some of the things our group has been working on:

Our programmer has worked on coding the enemy movement as well as finding target using A*. Other members are working on finishing up the board game prototype, making some game bits and typing up the rules before we meet up and play the game again. Other members are working as fast as they can to finish up the character models so that we can start the rigging process.

For game design, we are looking into things such as how can we create design patterns that will keep the players engaged in our game. We are discussing other things such as how we can design/implement the multiplayer system in order to keep everybody engaged so that nobody gets left behind whether they play a single or multiplayer game. We are also spending some time discussing the aesthetics of the game and how we can make it more visually appealing to players.

Since we have a networking assignment due, hopefully we will soon have basic chat functionality working in the game, which will be a good start for programming the networking portion of this game. Other than that, the group is hoping to have the board game prototype finished, the models finished and rigging process started, the chat function working, and the sounds recording started by the end of this month. Hopefully finishing all this by the end of February will help keep the group on track to finishing this game on time.