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.

Board Game Night!

Our first version of the board game was completed this week so we took some time during our meeting to try out the board game version of 'Endless'. Here are some pictures:

The initial set up

This is what happens when you don't plan out your strategy early on

Basically the chess pieces are the players, and every turn they get 3 moves + the option to attack or use their special ability (assuming the cool down period is not active). The poker pieces are the robots. Each color represents a different type of enemy (some can move 3 spaces instead of 2, some have extra health, some deal extra damage).

As with all initial versions of games, there are problems, and these will eventually be worked out. Some of the stuff we are discussing for the board game include:
- Increasing HP for the 4 characters
- Should the medic be given the revive ability?
- Should the medic fully restore the HP of a team member or a set amount of HP when they use the heal ability?
- Should KO'd players really be allowed to play as part of the robots once they die?

In the one we played, all the characters had low HP and no revive ability. On top of that, once somebody died, they would play for the robot team (now, every turn, instead of 4 robots spawning, there are 8 because of the 2nd player, or 12 because of the 3rd player).

In other news, the team is making good progress in the GDW game. One important part of developing the game later on will be balancing. The recent homework assignment we got was a good boost as it helped us design a game mechanic and everybody in the group did something different.

Here you can see a screenshot from one of the prototypes. Here, the numbers were tweaked for the attack damage, speed, and enemy's health. This will come in handy later on for figuring out the cost / benefit for some of the weapons in order to make sure none of them are too over or under powered. We are storing these in a chart in a document so that we can easily access them later on.

Another mechanic that was designed was the spawning of the enemies. The prototype had simple objects spawning, but it was good for testing the spawn rate and making sure they don't spawn too fast or too slow.

As you can see, the benefit of that assignment was great and this will definitely help in allowing us to tweak the game while we are working to get something up and running. This way, when the game is finally up and running, we can just throw the numbers into the game and don't need to waste time balancing it.

For these next few weeks there will probably be a bigger shift to creating the assets and programming the game. This is not to say that we will drop designing the game but rather just work on that as time permits. We are hoping to have another version of the board game done by next week as well as have more balancing and cost/benefit figured out.

Design Changes

This time around for our 3^rd meeting, we went back to discuss some details about our game’s level setup as well as some of the characters we planned to have in the game. With our level set up we decided that the use of turrets would be a bit too over powered allowing for enemy kills to be too easy. After trying to figure out alternatives to keep the turrets, in the end we decided that scrapping it would be the best idea and to make the level a bit more complex to make up for it. The rest of the level details more or less will stay the same.

On the playable characters side of things, since we are building a new game from scratch, we decided that 4 players might be a bit too much considering the remaining time we have left to have a working prototype by the end of the semester. So with this in mind, we had to decide on 2 characters that we should scrap from our design as well. The first being the engineer as there were a lot of complications with how unbalanced it would get due to the type of weapon they would have. We originally planned to have the engineer place turrets but would not have any means of attacking with any other weapons however we were question whether it would have been a good idea since it may bore the player as it wouldn’t be too interactive if they were playing as that character. The second option was to let the engineer carry a sub-machine gun and remove the ability to place turrets but with skills such as being able to “seize control” of 1 enemy unit until it dies (this can only be used when the player doesn’t already have control over an enemy unit as well as having a cooldown timer on the skill). This in the end also seemed a bit overpowered in some opinions shared as well as even with the character having a physical weapon. Thus we ended up getting rid of this character from the design as well as one other.

A playable character that is guaranteed to be in the game however would be the Assault. It seems to have been the best choice to keep mainly due to the idea that it would be much more easily balanced in terms of attack speed, weapon damage and health points for this character.

So at this point, we are more or less good to go with getting most of the work started.

A Fruitful meeting

During our second meeting, we did more decision-making on the game. This blog post will not discuss those decisions, but will discuss the game design aspects.

In the top-down shooter game, endless hordes of enemies will attack the player and his team until they die. There will be no winning state in the. We named our game “Endless” since there is an infinite number of enemies that attack the squad.

In terms of graphics, members took two different sides during our meeting. One side wanted a fast paced Halo-arcade-like game while the other side wanted a cartoony shooter game. In the end, we settled on an anime style, as it represents sort of a middle ground for the sides, having both realistic and cartoon elements.

As for the game itself, there are 4 characters: the medic, assault, sniper, and engineer. Their characteristics are discussed below:

Medic: The medic has the ability to heal other players. The disadvantage is that the medic will have low health and less powerful weapons (Pistols).

Assault: The assault unit is the well-rounded unit. He is able to take a lot of damage as well as cause a sustainable amount of damage to the enemy units with assault rifles and machine guns. The assault unit will be the tank in the game.

Sniper: The sniper will have the ability to wield powerful rifles with amazing aim which can fire penetrating bullets which will pass through multiple enemies until it hits a wall or leaves the battlefield boundaries. Though, even with such a powerful weapon, it has a disadvantage. Sniper rifles will have the longest shooting delay between bullet fires.

Engineer: The engineer has the ability to setup turrets or defence mechanisms to help his teammates. If the engineer levels up, the turrets will level up as well. However, if the engineer dies, then the turrets will lose its functionality. The engineer will be able to wield weapons of average power (Maybe Submachine guns).

Since this is the plan for each character it could change in the future if it is approperate.

“Endless” like most other games, will have an in game currency. The name has not yet been decided on but for the purpose of this blog post we will call them gold. As a group we decided on how the player should receive gold in the game. We thought that we should give out gold for every enemy kill that the player does. The group also decided whether the gold should be a fixed amount for each different enemy or randomized between a minimum and a maximum value for each monster. The group chose the randomize method. We also considered whether the player should only receive gold from what he/she killed. But we thought that it would not be fair since each character doesn’t have the same strength and in single player the AI could kill-steal the monsters and the money would go nowhere. So we decided that gold in the game will be shared as a team. When the wave of enemies is defeated, the player has the chance to manage the expenditure of weapons for the entire team. In co-op, the money will be divided into the number of players. We decided to split the gold evenly as it would splitting it other ways would be unfair to the medic, who theoretically, should have the least kills. Gold is also rewarded when the player finishes each level. We are still contemplating whether the amount of gold should be time based or not (probably will with a base amount of gold rewarded on top of that).

The game would be angled (not completely 90 degrees from the ground) a bit less than 90 degrees so there would be a bit of a perspective feel to it.

Lastly, we talked about weapons. We thought of two structures for our game’s weapon progression. First structure involves making each weapon for its class similar but with little benefits as the price significantly advances for the more realistic feal. For example,

Weapon A is similar to Weapon B for the same price but Weapon A has a bit lower accuracy and a bit higher shoot speed than Weapon B. Weapon E (skipping a few) is higher priced than Weapon A and B but is better than both of them and is similar to Weapons D and F.

The second structure is where each weapon upgrades until it reaches its full potential, there’s no need for the player to compare weapons for curtain prices like the first structure, it always gets better the more expensive it is (like in many Japanese RPG games where the price = power of the weapons). The group realized that there is more of a game dynamics on the first weapon progression theory. If we used the weapon upgrade theory, the player will just keep killing enemies to earn money in order to upgrade to the ultimate weapon. But the first theory suggests the player to think of tactics and weapons that will suit the player’s way of playing the game. In the end we leant towards the first structure for realism and flexibility which would involve more strategy for the players.

New Whiteboard!

Hey everybody,

After using our getto cork-board and paper as our board during meetings we realized we needed a whiteboard so we went over to Walmart and grabbed ourselves a whiteboard!

We also bought some grocerys since we were down there :)

New Year, New Game and a New Team

Happy New Year everybody!

It's a new year and after the disaster we've had last semester we've made many changes. To start off, here are the changes we've made:

- We've removed the slackers in the group. Simply put, it's just not fair to the rest of the team that does do work.We started out as a group of 7 but we are now only a group of 4.

- We've changed our team name. The original team name was 'Got Rice?' and we have renamed to 'Slightly Toasted'. This will be the group blog used throughout the semester (possibly longer) and the individual blogs will remain the same.

- The last and biggest change we've made is the game. After re-forming the smaller group, nobody was interested in working on the old game anymore and agreed on completely re-doing the entire game, working on something that everybody will enjoy so that hopefully everyone will put in all the effort they can to make this a good game.

How is this going so far? The team is off to a good start and working hard at properly planning the game before any of the development starts. Here are some pictures from our first meeting:

The Meeting Board

A Close Up Of The Board

Picture Of The Meeting

We seem to be off to a good start so hopefully we will all keep this up and have a great game by the end of the semester.