What do we need to make to get to our value props?
PLAYER CHARACTER
- Design - The main character is Toci, resurrected Aztec Goddess. This requires animation.
- Movement/Aiming - Toci will move in four directions and aim following the mouse. This requires programming.
- Attacking -Toci has two attack slots, mapped to left and right mouse buttons. This requires programming.
-- Weapons - There are four weapons with four methods of attack which can be assigned to attack slots. This requires programming and animation.
-- Powers - Additionally, there are four powers that can be assigned to attack slots. These require programming and animation.
ENEMIES
- Design - The Spanish need animations for movement in four directions, and individual attack and death animations. This requires animation.
-Movement/Aiming - Enemies move and aim in four directions. This requires programming.
-AI -This will require a great deal of programming.
--group
--individual
ENVIRONMENT
- GUI - There are three GUIs, main, inventory, and temple. These require programming and animation.
- Tenochtitlan - This is the level, which are art tiles, colliders, and layout. This requires programming, design, and animation.
Sunday, March 8, 2015
Sunday, March 1, 2015
s0r: A Text Adventure
The Sprint 0 Round-up! Our goal for Sprint 0 was to complete four things:
Design, I thought, was sufficient. Stats were estimated, abilities pitched, all with relative competence, but without the framework of a play-tested game, the fine tuning of mechanics remains a chore. If anything, designers were under utilized, or at least with little to do.
Programming was quickly done. The base tasks proved little challenge, but I fear the real test will be the AI. Of course, this fear is unfounded because I know nothing about the AI script, but I do believe it is integral to the fun of this game, and as such should be worried over.
Truly, the greatest misstep was in art, as we only have 4 artists. This isn't so much an issue of the team, but rather a shortcoming of the idea* which wanted to utilize an aesthetic style as a key value proposition.
In regards to the trinity of specialization, I suspect that the programming side of the equation only grows heavier with the progression of the process, with design worked hardest in the beginning and the artist in the middle. Whether there is validity in the sentiment is secondary, though, to my need to correct my antiquated-Waterfall thought-structure. Programmers are no longer a group, neither designers nor artists. Once our base pipeline is tested, we are feature teams: coalitions of the...willing, I guess. We have individual features to address in all three facets - programming, design, and art - and dealing with only the feature in scope. The base upon which those features are added was concluded with Sprint 0 in accordance with the ideal that the product is always finished, and only continues to get more finished with iterative sprints.
*And most certainly not the idiot who thought it up and promoted it.
- Enemy Types
- Enemies Surround Player
- Damage Received/Dealt
- Enemy Scaling
Design, I thought, was sufficient. Stats were estimated, abilities pitched, all with relative competence, but without the framework of a play-tested game, the fine tuning of mechanics remains a chore. If anything, designers were under utilized, or at least with little to do.
Programming was quickly done. The base tasks proved little challenge, but I fear the real test will be the AI. Of course, this fear is unfounded because I know nothing about the AI script, but I do believe it is integral to the fun of this game, and as such should be worried over.
Truly, the greatest misstep was in art, as we only have 4 artists. This isn't so much an issue of the team, but rather a shortcoming of the idea* which wanted to utilize an aesthetic style as a key value proposition.
In regards to the trinity of specialization, I suspect that the programming side of the equation only grows heavier with the progression of the process, with design worked hardest in the beginning and the artist in the middle. Whether there is validity in the sentiment is secondary, though, to my need to correct my antiquated-Waterfall thought-structure. Programmers are no longer a group, neither designers nor artists. Once our base pipeline is tested, we are feature teams: coalitions of the...willing, I guess. We have individual features to address in all three facets - programming, design, and art - and dealing with only the feature in scope. The base upon which those features are added was concluded with Sprint 0 in accordance with the ideal that the product is always finished, and only continues to get more finished with iterative sprints.
*And most certainly not the idiot who thought it up and promoted it.
Value Props and the People Who Love Them
What is most important about the game? My guesses-
1. Historical setting. I can imagine people enjoying the Aztecs for one(/two) reasons. The most obvious is that they know something about the Aztec, and could appreciate seeing this knowledge in the game. The second is the negative of the first: they know nothing about the Aztecs, and thus take pleasure in the foreign-ness of the surroundings.
Survey says:
A plurality of people (44%) rated this of mid-level importance, with the next largest category (41%) feeling it of only slightly less importance than the first. So apparently the setting is important, but not completely a deal-breaker.
2. AI. I think something that will set this game apart is the group AI mechanics. Hack and slash is fun, but I think it'd be more fun if you were fighting a sea of enemies, where the crowd behaves in certain ways but individuals also display qualities.
Anyone else?
A majority of people definitely want varying enemy types; that's clear. As for their overall organization, the only clear message is that the enemy should not scatter. I don't think there's enough data to make any kind of inference regarding player preference to troop formation. My guess is that this is something that needs to be played by the customer. Surveys, as lovely as they are, just aren't conveying the experience of the quirks of our program, and generalized data is wonderful, but user interaction should now be the goal.
3. Inventory. This is a game about hitting things: the fun is most likely in the variety of ways there are to hit things. Thus, our job is as a nozzle, controlling the flow of of fun and agency to the user; too much at once and the player is overwhelmed and quits, too little they quit out of boredom. This is where our inventory, and to an extent our skill tree and mana mechanic come in.
53% of respondents chose to agree with the 'obvious' inventory answer, but I think the small sample size is enough to draw any conclusion irrelevant. 68%, and a more palpable 686 votes, support our direction regarding the use of the temple GUI housing the skill tree. I'm not prepared to interpret feedback on the mana cooldown.
1. Historical setting. I can imagine people enjoying the Aztecs for one(/two) reasons. The most obvious is that they know something about the Aztec, and could appreciate seeing this knowledge in the game. The second is the negative of the first: they know nothing about the Aztecs, and thus take pleasure in the foreign-ness of the surroundings.
Survey says:
2. AI. I think something that will set this game apart is the group AI mechanics. Hack and slash is fun, but I think it'd be more fun if you were fighting a sea of enemies, where the crowd behaves in certain ways but individuals also display qualities.
Anyone else?
A majority of people definitely want varying enemy types; that's clear. As for their overall organization, the only clear message is that the enemy should not scatter. I don't think there's enough data to make any kind of inference regarding player preference to troop formation. My guess is that this is something that needs to be played by the customer. Surveys, as lovely as they are, just aren't conveying the experience of the quirks of our program, and generalized data is wonderful, but user interaction should now be the goal.
3. Inventory. This is a game about hitting things: the fun is most likely in the variety of ways there are to hit things. Thus, our job is as a nozzle, controlling the flow of of fun and agency to the user; too much at once and the player is overwhelmed and quits, too little they quit out of boredom. This is where our inventory, and to an extent our skill tree and mana mechanic come in.
53% of respondents chose to agree with the 'obvious' inventory answer, but I think the small sample size is enough to draw any conclusion irrelevant. 68%, and a more palpable 686 votes, support our direction regarding the use of the temple GUI housing the skill tree. I'm not prepared to interpret feedback on the mana cooldown.
Subscribe to:
Posts (Atom)