The following are the updates that have happened over the past week:
Game Menus:
I discussed the look and feel of the menus with my team. A final version of the menus will be available later on in the week. Some minor edits have been made but I now need to go into RPG Maker to see the format of their menus so we can properly import them into RPG Maker.
Cloud Mapping:
Drew and I will be sitting down later on in the week to draft the rest of the story and finalize the cloud mapping. I shown the team my sketches so the team can get on mapping the game roughly in RPG maker.
Weekly Meeting Time:
Tuesdays meetings will go from 2:00 PM until 3:00 PM. Last week we met in the games room of the Library.
Next Weeks Objectives:
This weeks deliverables have fallen behind. For next week, I am hoping to have the map of the first, second, and third cloud finished. I also hope to have the menus finalized. I also hope to have the story for the first cloud to be completely finished. These details need to be finished in order for us to remain on schedule.
Tuesday, October 30, 2007
Week Eight Class Critiques
The following is feedback for the teams that presented in Week Eight:
ANTLION
Mechanics
It appears that your mechanics are very clear for the player. The purpose of the game is to prevent yourself from being hunted by the ever threatening ant lion. As an ant your only true defense is your cunning and your speed. This is a very simple, appropriate, and fun mechanic to implement. Many other games that meant for a more well rounded user use a similar approach, namely for racing games. It is important to keep this your fundamental mechanic and avoid creating power ups that would disrupt this, such as by creating an easy to attain weapon that would damage or even kill the ant lion.
Dynamics
To make the dynamics of the game the most interesting to the player, a sense of suspense should be created over minutes rather than hours. It seems that the game you are trying to create is one meant to last for short durations of simple game play and because of this, it is important to have a more intense sense of possible doom to the player as they are playing this game. My suggestion is to have an ant lion that is not completely seen to the player and have it so no matter how fast the players go, there is some way for the ant lion to disrupt or interfere with the players strategy. This will help meet the need for a challenge to the player while not making it impossible to meet or see the ant lion.
Aesthetics
To me, the types of fun that you are using for your game are challenge, discovery, and submission and with this comes several considerations for your game. To create the challenge of the game, you have decided to create a basically invincible opponent that stalks you over time and is always looming over your shoulder, which is a significant but important design choice. You have a small sense of discovery if you choose to implement some kind of power up system. This will allow players to interact within their ecosystem in different ways. Finally, based on the description that was given and as already touched upon in dynamics, this would make a very good short duration game. Because of this, the view, art, and special effects so match a sense of urgency with the ant needing to escape.
FINS OF FURY
Mechanics
You have two important mechanics to consider for this game: point and click combat and three dimensional movement. Make sure for your point and click combat that you may close detail to your close combat collision detection. Many games have run into trouble, like Superman 64, because it was too difficult to attack an enemy up close.
There are a few design considerations that you will have to make for your movement. Because you are planning on having this being a third person real time combat game, like Resident Evil 4, and because you are making this underwater, it does not make sense to me to give your players the ability to strafe from side to side (or at least as a tadpole). However, to maintain continuity and because players are use to being able to strafe in a first person and third person environment, are you going to give it to them anyways?
Dynamics
The biggest concern that I have about the dynamics of this game is making it too easy for the players to win because of the AI of the NPCs. I think that you can be really creative and you can define your opponents personalities and have it compare to some measure of your user (number of kills over duration of time for example). If you have three different mind sets for an opponent, such as easy, medium, and hard or passive, normal, and aggressive, you can have the game be easy at some times (when you need healing) and difficult during other times (when the player is killing things left, right and center).
Aesthetics
You have many types of fun for your game: Fantasy, Narrative, Challenge, Discovery, and Expression. With these many types of fun comes an expectation from the user. To be able to help support the sense of fantasy, have outrageous looking characters, both opponents and friendly NPCs. Have dangers that exist to tadpoles in the real world and within the magic circle your are trying to develop (for instance, have polluted zones deal damage to the tadpole over time). You can also make special quests that help immerse the player into the fantasy and the narrative more.
The game itself can only be challenging if the dynamics allow for it (refer to dynamics sections for suggestions). As far as Discovery and Expression, it was mentioned that the tadpole will upgrade itself by growing legs, arms, and a body. It would be really interesting if you could choose which part of your body you can add first, arms versus legs, because this will allow the player to customize their frog based on their playing style, power versus speed. This will also allow the player to explore the environment from two different perspectives allowing for two different modes of play, a slower but more high powered mode or a faster less powered mode.
MIZU
Mechanics
The main mechanic you are going to need to focus on is your cannon firing mechanic. By having the effect of it dynamic with the ability to charge you leave it open to the player as to how they should use it. Should they conserve water and to small individual shots or should they over kill with a single charged shot. Make sure that the power ups that you have help support the types of shots the player can do or how accurately they can do it.
A secondary mechanic you have is movement. Because you are having a 2D side scrolling game, your movement is fairly simple, up, down left and right. If you have power ups or another system of improving this can all add to the game.
Dynamics
I like how you are adding the negative feedback twist with the weapon. By having it so the player can not have the weapon readied at full power all the time forces the player to properly conserve their resources. Even though this does add an extra challenge to the game, be aware that it also makes the game forces the player to conform more to a more conservative playing style rather than a readied power playing style, like in Megaman.
I think it would be important to find a way to limit and enhance the players movement. Having a fast or slow player can make the difference between victory and defeat. Also, temporarily limiting or even disabling someones ability to jump changes the way a player interacts in their environment. This can add to the challenge to the game without having to scale some of the enemy NPCs.
Aesthetics
The strongest types of fun that you are appealing to are as follows: Challenge, Discovery, Expression, and Submission. I believe that you have all four of these well thought out. With challenge, you can limit the players ability by giving them curses them or enhancing them by giving them power ups. The players can find their best combinations of power ups and how they can most optimally interact in the environment, which appeals to the sense of discovery and expression. Submission is the only form of fun that I am unsure how you are going about. To me, like with team AntLion, if you manipulate the environment to help create a sense of urgency and making multiple and different power ups, you can make this a quick game that is enjoyable for multiple iterations, even after the player has completed the game.
TESTING 1... 2... 3
Mechanics
There are two fundamental game mechanics for this game: combat system and 2D movement. The combat system I am actually unsure how you are going about it. Is it single click combat (click onces to swipe a sword) or is it pattern combat (type in a pattern to get a combination of attacks). Both of which come with different benefits and problems. Single click will allow you to have simple combat but can have a problem with making the game challenging without compromising collision detection or the power of the players. Combo attacks allows for more aesthetics but makes the learning curve higher.
The second mechanic you have is 2D movement. Make sure that you have items that enhance this mechanic as well. I remember you saying that this is inspired by Dungeons and Dragons. Keep in mind they too have ways of both enhancing and disrupting movement with everything from potions of expeditious retreat to tangle foot bags.
Dynamics
The easiest way to help balance out the dynamics of the game are to give your opponents and the players access to similar abilities. For instance if the players have a way to stop enemy movement, then the enemies should have a way slow the players.
You had mentioned that you wanted to have a party based game but were considering making this a single player game. The best way to have the best of both worlds is to have the player select their character from your selection of characters and then have the computer select 3 other characters that will play with the character, similar to Guildwars. This will allow you to make the game more challenging to the player and still have the feel of dungeon crawling with a group.
Aesthetics
There are four types of fun that you are appealing to in this: Fantasy, Challenge, Discover, and Expression. To appeal to fantasy, going for the medieval look is good choice. It is easy to make stereotypes out of the genre, such as the wizard, fighter, thief, priest and what not. You already recognize that the game needs to have more balance both in enemy and player abilities.
The players are going to be looking for someway to enhance they character. By giving someway to internally enhancing their characters (skill trees or ability selection) and power ups. By having a diverse set of power ups and character enhancement players can enjoy playing the game in multiple iterations with different outcomes and strategies for each character, power ups, and ability selection.
ANTLION
Mechanics
It appears that your mechanics are very clear for the player. The purpose of the game is to prevent yourself from being hunted by the ever threatening ant lion. As an ant your only true defense is your cunning and your speed. This is a very simple, appropriate, and fun mechanic to implement. Many other games that meant for a more well rounded user use a similar approach, namely for racing games. It is important to keep this your fundamental mechanic and avoid creating power ups that would disrupt this, such as by creating an easy to attain weapon that would damage or even kill the ant lion.
Dynamics
To make the dynamics of the game the most interesting to the player, a sense of suspense should be created over minutes rather than hours. It seems that the game you are trying to create is one meant to last for short durations of simple game play and because of this, it is important to have a more intense sense of possible doom to the player as they are playing this game. My suggestion is to have an ant lion that is not completely seen to the player and have it so no matter how fast the players go, there is some way for the ant lion to disrupt or interfere with the players strategy. This will help meet the need for a challenge to the player while not making it impossible to meet or see the ant lion.
Aesthetics
To me, the types of fun that you are using for your game are challenge, discovery, and submission and with this comes several considerations for your game. To create the challenge of the game, you have decided to create a basically invincible opponent that stalks you over time and is always looming over your shoulder, which is a significant but important design choice. You have a small sense of discovery if you choose to implement some kind of power up system. This will allow players to interact within their ecosystem in different ways. Finally, based on the description that was given and as already touched upon in dynamics, this would make a very good short duration game. Because of this, the view, art, and special effects so match a sense of urgency with the ant needing to escape.
FINS OF FURY
Mechanics
You have two important mechanics to consider for this game: point and click combat and three dimensional movement. Make sure for your point and click combat that you may close detail to your close combat collision detection. Many games have run into trouble, like Superman 64, because it was too difficult to attack an enemy up close.
There are a few design considerations that you will have to make for your movement. Because you are planning on having this being a third person real time combat game, like Resident Evil 4, and because you are making this underwater, it does not make sense to me to give your players the ability to strafe from side to side (or at least as a tadpole). However, to maintain continuity and because players are use to being able to strafe in a first person and third person environment, are you going to give it to them anyways?
Dynamics
The biggest concern that I have about the dynamics of this game is making it too easy for the players to win because of the AI of the NPCs. I think that you can be really creative and you can define your opponents personalities and have it compare to some measure of your user (number of kills over duration of time for example). If you have three different mind sets for an opponent, such as easy, medium, and hard or passive, normal, and aggressive, you can have the game be easy at some times (when you need healing) and difficult during other times (when the player is killing things left, right and center).
Aesthetics
You have many types of fun for your game: Fantasy, Narrative, Challenge, Discovery, and Expression. With these many types of fun comes an expectation from the user. To be able to help support the sense of fantasy, have outrageous looking characters, both opponents and friendly NPCs. Have dangers that exist to tadpoles in the real world and within the magic circle your are trying to develop (for instance, have polluted zones deal damage to the tadpole over time). You can also make special quests that help immerse the player into the fantasy and the narrative more.
The game itself can only be challenging if the dynamics allow for it (refer to dynamics sections for suggestions). As far as Discovery and Expression, it was mentioned that the tadpole will upgrade itself by growing legs, arms, and a body. It would be really interesting if you could choose which part of your body you can add first, arms versus legs, because this will allow the player to customize their frog based on their playing style, power versus speed. This will also allow the player to explore the environment from two different perspectives allowing for two different modes of play, a slower but more high powered mode or a faster less powered mode.
MIZU
Mechanics
The main mechanic you are going to need to focus on is your cannon firing mechanic. By having the effect of it dynamic with the ability to charge you leave it open to the player as to how they should use it. Should they conserve water and to small individual shots or should they over kill with a single charged shot. Make sure that the power ups that you have help support the types of shots the player can do or how accurately they can do it.
A secondary mechanic you have is movement. Because you are having a 2D side scrolling game, your movement is fairly simple, up, down left and right. If you have power ups or another system of improving this can all add to the game.
Dynamics
I like how you are adding the negative feedback twist with the weapon. By having it so the player can not have the weapon readied at full power all the time forces the player to properly conserve their resources. Even though this does add an extra challenge to the game, be aware that it also makes the game forces the player to conform more to a more conservative playing style rather than a readied power playing style, like in Megaman.
I think it would be important to find a way to limit and enhance the players movement. Having a fast or slow player can make the difference between victory and defeat. Also, temporarily limiting or even disabling someones ability to jump changes the way a player interacts in their environment. This can add to the challenge to the game without having to scale some of the enemy NPCs.
Aesthetics
The strongest types of fun that you are appealing to are as follows: Challenge, Discovery, Expression, and Submission. I believe that you have all four of these well thought out. With challenge, you can limit the players ability by giving them curses them or enhancing them by giving them power ups. The players can find their best combinations of power ups and how they can most optimally interact in the environment, which appeals to the sense of discovery and expression. Submission is the only form of fun that I am unsure how you are going about. To me, like with team AntLion, if you manipulate the environment to help create a sense of urgency and making multiple and different power ups, you can make this a quick game that is enjoyable for multiple iterations, even after the player has completed the game.
TESTING 1... 2... 3
Mechanics
There are two fundamental game mechanics for this game: combat system and 2D movement. The combat system I am actually unsure how you are going about it. Is it single click combat (click onces to swipe a sword) or is it pattern combat (type in a pattern to get a combination of attacks). Both of which come with different benefits and problems. Single click will allow you to have simple combat but can have a problem with making the game challenging without compromising collision detection or the power of the players. Combo attacks allows for more aesthetics but makes the learning curve higher.
The second mechanic you have is 2D movement. Make sure that you have items that enhance this mechanic as well. I remember you saying that this is inspired by Dungeons and Dragons. Keep in mind they too have ways of both enhancing and disrupting movement with everything from potions of expeditious retreat to tangle foot bags.
Dynamics
The easiest way to help balance out the dynamics of the game are to give your opponents and the players access to similar abilities. For instance if the players have a way to stop enemy movement, then the enemies should have a way slow the players.
You had mentioned that you wanted to have a party based game but were considering making this a single player game. The best way to have the best of both worlds is to have the player select their character from your selection of characters and then have the computer select 3 other characters that will play with the character, similar to Guildwars. This will allow you to make the game more challenging to the player and still have the feel of dungeon crawling with a group.
Aesthetics
There are four types of fun that you are appealing to in this: Fantasy, Challenge, Discover, and Expression. To appeal to fantasy, going for the medieval look is good choice. It is easy to make stereotypes out of the genre, such as the wizard, fighter, thief, priest and what not. You already recognize that the game needs to have more balance both in enemy and player abilities.
The players are going to be looking for someway to enhance they character. By giving someway to internally enhancing their characters (skill trees or ability selection) and power ups. By having a diverse set of power ups and character enhancement players can enjoy playing the game in multiple iterations with different outcomes and strategies for each character, power ups, and ability selection.
Monday, October 22, 2007
Week Eight 3RD CLOUD Project Update
Much has happened over the past week.
Game Menus:
I have finished drafting up possible design options for the menus of 3rd CLOUD. I was thinking that as the player advances through the game, the menu look and feel should change. Here are the three design descriptions that I have come up with:
1st Cloud: The menu should look and feel light and happy. The farmers boy is going on a new and different experience and the menu should help support this. Because of this, the menu will look like rolling green empty hills. In the menu itself, a branch with leaves and berries are there to represent the growth of the character.
2nd Cloud: This menu should represent business as this is what the second cloud represents. The menus I believe should reflect the profession that the player picked. With this, I imagine the menus to be rolling blue hills with some development on them. Also, the branch with berries if replaced by symbols that represent the players profession (ie: swords and shields for the fighter).
3rd Cloud: The menu for the 3rd cloud is meant to represent the state of the cloud itself, which is full of death, decay and possibly demons. Because of this, The rolling hills will now be black with tombstones on them. The symbols of the characters profession will be replaced with a tombstone and a skull.
As far as navigation, I like how RPG Maker utilizes it's menus. Given that we have four weeks left for our project, I believe that the default menu navigation is fine.
Cloud Mapping:
I have created a basic map of all three clouds. They are still in a rough format and needs to be approved by the team. In our next meeting I am hoping to finalize the map of the first cloud.
Project Management:
Drew has requested that I become the project manager of 3rd CLOUD. He is a much better programmer than I and I am more proficient at documentation and thus our roles have been switched.
Weekly Meeting Time:
Tuesdays meetings will go from 2:00 PM until 3:00 PM. Last week we met in the games room of the Library.
Next Weeks Objectives:
For next week, I am hoping to have the map of the first, second, and third cloud finished. I also hope to have the menus finalized. I also hope to have the story for the first cloud to be completely finished.
Game Menus:
I have finished drafting up possible design options for the menus of 3rd CLOUD. I was thinking that as the player advances through the game, the menu look and feel should change. Here are the three design descriptions that I have come up with:
1st Cloud: The menu should look and feel light and happy. The farmers boy is going on a new and different experience and the menu should help support this. Because of this, the menu will look like rolling green empty hills. In the menu itself, a branch with leaves and berries are there to represent the growth of the character.
2nd Cloud: This menu should represent business as this is what the second cloud represents. The menus I believe should reflect the profession that the player picked. With this, I imagine the menus to be rolling blue hills with some development on them. Also, the branch with berries if replaced by symbols that represent the players profession (ie: swords and shields for the fighter).
3rd Cloud: The menu for the 3rd cloud is meant to represent the state of the cloud itself, which is full of death, decay and possibly demons. Because of this, The rolling hills will now be black with tombstones on them. The symbols of the characters profession will be replaced with a tombstone and a skull.
As far as navigation, I like how RPG Maker utilizes it's menus. Given that we have four weeks left for our project, I believe that the default menu navigation is fine.
Cloud Mapping:
I have created a basic map of all three clouds. They are still in a rough format and needs to be approved by the team. In our next meeting I am hoping to finalize the map of the first cloud.
Project Management:
Drew has requested that I become the project manager of 3rd CLOUD. He is a much better programmer than I and I am more proficient at documentation and thus our roles have been switched.
Weekly Meeting Time:
Tuesdays meetings will go from 2:00 PM until 3:00 PM. Last week we met in the games room of the Library.
Next Weeks Objectives:
For next week, I am hoping to have the map of the first, second, and third cloud finished. I also hope to have the menus finalized. I also hope to have the story for the first cloud to be completely finished.
Tuesday, October 16, 2007
Week Seven 3RD CLOUD Project Update
Much has happened over the past few weeks. 3RD CLOUD is now snowballing towards completion.
Paper Prototype Testing:
Drew and I were able to test the paper prototype on three individuals. We tried using the facilities supplied to us (use of a one way mirror, lots of open space); however, the one way mirror did not allow us to hear the user being tested. We also did not make use of the open space provided because our prototype was made in RPG maker and required a digital interface: my laptop.
If the digital prototype had failed, I had prepared a paper and pencil Role Playing Alternative using the Dungeons and Dragons 3.5 system. It would follow the same story, relatively the same combat system, and involve the same characters.
Paper Prototype Documentation:
I was in charge of documenting the experience of the user. I had the user fill out an eleven question survey about their experience with RPGs, their game experience in 3RD CLOUD and their thoughts and suggestions after they played our prototype.
The general consensus was that the game was not very intuitive on its own. Players were unsure where they should go and what to do unless myself or Drew began to guide them at some points. It was suggested that we have some kind of tutorial in the game but I think this is a great point for anyone in our team with graphical design experience to create a users manual.
Another problem we encountered was with interactivity. Players seemed to want to click everything that was around the room: coats, pictures, barrels, etc. They expected a result of some sorts even if a simple message popped up and said "this is a barrel." To solve this requires more programming than what we first expected but I am assured that the extra work would not be to strenuous.
Weekly Meeting Time:
We have finally hammered out a time in which to meet on a regular and scheduled basis for the team. We met last week on Tuesday at 2:00 PM until 4:00 PM. We found that this schedule worked for everyone in the team; however, I have meetings that start at 3:00 PM on Tuesdays. Because of this, Tuesdays meetings will go from 2:00 PM until 3:00 PM.
Next Weeks Objectives:
For next week, I am hoping to have a map of the first cloud completed along with the menu and player navigation through all the menus, both for combat and out of combat. I will also be doing any documentation that will be required over the next week.
Paper Prototype Testing:
Drew and I were able to test the paper prototype on three individuals. We tried using the facilities supplied to us (use of a one way mirror, lots of open space); however, the one way mirror did not allow us to hear the user being tested. We also did not make use of the open space provided because our prototype was made in RPG maker and required a digital interface: my laptop.
If the digital prototype had failed, I had prepared a paper and pencil Role Playing Alternative using the Dungeons and Dragons 3.5 system. It would follow the same story, relatively the same combat system, and involve the same characters.
Paper Prototype Documentation:
I was in charge of documenting the experience of the user. I had the user fill out an eleven question survey about their experience with RPGs, their game experience in 3RD CLOUD and their thoughts and suggestions after they played our prototype.
The general consensus was that the game was not very intuitive on its own. Players were unsure where they should go and what to do unless myself or Drew began to guide them at some points. It was suggested that we have some kind of tutorial in the game but I think this is a great point for anyone in our team with graphical design experience to create a users manual.
Another problem we encountered was with interactivity. Players seemed to want to click everything that was around the room: coats, pictures, barrels, etc. They expected a result of some sorts even if a simple message popped up and said "this is a barrel." To solve this requires more programming than what we first expected but I am assured that the extra work would not be to strenuous.
Weekly Meeting Time:
We have finally hammered out a time in which to meet on a regular and scheduled basis for the team. We met last week on Tuesday at 2:00 PM until 4:00 PM. We found that this schedule worked for everyone in the team; however, I have meetings that start at 3:00 PM on Tuesdays. Because of this, Tuesdays meetings will go from 2:00 PM until 3:00 PM.
Next Weeks Objectives:
For next week, I am hoping to have a map of the first cloud completed along with the menu and player navigation through all the menus, both for combat and out of combat. I will also be doing any documentation that will be required over the next week.
Tuesday, October 2, 2007
A New Challenge Approaches: THIRD CLOUD
My idea was not chosen as one of the top for game ideas in my section. Actually, it wasn’t even in the top six. That is alright. I decided that for the team I am going to belong to, I want to pick the one that had the best story to it. That is why I am involved with project Third Cloud.
It is an RPG similar to my own where an unlikely individual must band together with strangers to free the three clouds of evil. It takes place on a world suspended in the air on platforms entirely made of clouds. Each cloud has a social status, upper at the top cloud and lower on the bottom, and traveling between the clouds is restricted by each clouds Ruler.
A simple peasant is farming one day when he comes across a strange artifact that fell from the third cloud. He takes this artifact to the village shaman who stresses its importance but does not take it. He asks you to take it to the local Lord. On your way there, you are robbed by bandits who take the item away from you. When you reach the lord he urges you to get it back. And so it begins…
REAPER Game Vision
For more details about my ideas for the game, please refer to the content below.
Overview and Objective:
Reaper is an interactive RPG meant to immerse you into the shoes of a peasant who has to rise up, free the land of evil and rise up to meet his true destiny.
With this game, I am hoping to revive the RPGs of the mid 1990’s where heros are made from those whose destiny demand it.
User Description:
My prime target audience are the narrative driven RPG goers. Such individuals are usually fans of other RPGs such as Never Winter Nights and Baulder’s Gate and table top RPGs such as Dungeons and Dragons and GURPS. This game is also meant to minimalists (you are fighting as a peasant after all) and to those that are into the story more than into power gaming.
Prototype:
I was able to prototype my story. I had six users take a survey a while reading my story. The results were encouraging. The results are summarized in the previous post.
Features and Functionalities:
If it is possible, I want to make this game from the first person point of view, like in Half-life. I am hoping this will maximize my users immersive experience. The best engine for this that I can think of is the Halflife 2 engine. With the engine, it places us in the first person perspective and gives us a 3D environment to wander around in. When the player needs to rescue NPCs, Halflife 2 makes it easy for them to follow. Plus it makes it simpler to make a single or multiplayer application.
Justification:
The reason I want to use the Halflife 2 engine is for one reason only: immersion. I want the user to stop thinking about the real world and put themselves in the place of the heroic peasant. The perspective, graphics range and immersive experience of this story is perfect for the Halflife 2 engine.
User Testing:
The individuals I tested with my survey I have played Dungeons and Dragons with before. Some are power gamers, some are munchkins, but most of all, they all enjoy story. With these individuals, they told me they liked being able to do as they with in an adventure and did not like straightforward tactics (such as simply press A to attack). They also tend to be curious and like to explore around everywhere.
Short Comings:
There are several problems associated with Reaper. The first is that the narrative specific market is very niche oriented. It is usually the more hard core narrative goers that prefer this genre of game.
The story also had a few problems. As said before, only 50% of the users liked the story. The other half thought it was only decent.
One problem with the Halflife 2 engine is that I believe it is difficult to make sprites work in party with you. Because of this, the hero of Reaper may have to do his questing alone.
Finally, one of the biggest problems is in getting people to follow the story line without putting in huge game barriers (such as making them always walk on a single path). This not only restricts the market even more but it takes away from letting people be curious to explore the space they are in.
Expansion Ideas:
The most logical idea for expansion for this game is to make it a multiplayer game. After all, having one peasant is a hero is not nearly as cool as a village defending their town from an invasion.
If I can too, I want to expand on the story and character development. Even during the testing process, the story was rather vague and did need some work.
Other ideas I have had for expanding is fighting some kind of unique super boss or even when winning the game, there can be alternate endings.
Next Step:
The biggest step is to further develop the story or even redevelop the story so that it can be more immersive. Also, I will need to soon start on the prototype development process such as designing and building weapons, equipment, sound, scenes, and sprites. Finally after the demo is finished or even partially finished, I can do user testing.
Subscribe to:
Comments (Atom)
.jpg)