I'm behind a few days, but that is for good reason. Alpha is approaching (10 days and counting! Yikes!) and there is so much to do. With the restriction that every system must be in place, we are, obviously, getting every system in place, and that is taking a lot of time and commitment! From a collection system to a UI, my team has really stepped up to get a lot done this sprint. I started off the sprint helping Adam to get the corner-wall shimmy maneuver working, as well as helping Mavin with the limbo state transition the player enters when jumping off of walls (a limbo state is a state where the player has no movement, either for a set amount of time, or until he/she hits the ground, grabs a ledge, etc.)
Post helping the team, I finished the problems we were having getting the game to work on the Xbox. Which reminds me: sadly, you still get a wall of text this week rather than the promised video. That will come next week, but my progress this week isn't quite ready to be shown in a video.
After fixing the xbox deployment, I set out to integrate multiplayer. First, I set up a screen system to allow us to have a lobby screen, a matchmaking screen, a game search screen, and, of course, the game screen. The player starts off, is forced to sign in if not signed in (currently only noticeable on pc, but once the game is launched this will be important too) then they can choose to host a game (local or live) or search for a game (local or live.) This all works rather well. Once in the lobby, the players signal they are ready and the game starts. A lot of this code framework came from step 4 of the xna Microsoft tutorial found here. However, I built my own network controller class that helps manage the creation of the different types of networks, and different actions the user can perform. Additionally I added a player class that helps keep the players Character entity paired up with actions such as transmitting the data to the other sessions.
I'm not entirely done with the last part, but it's getting pretty close. Once I'm done with the basics of multiplayer, I will be working on the abilities to the end of the sprint. The final sprint will be helping the team finish their respective tasks, and working on controls. The controls have gotten wonky, and need much love before I'll be happy to call it Alpha.
Monday, November 26, 2012
Thursday, November 15, 2012
Developers Log. Development Date 30 - AI Refactoring, Abilities, and Pair Programming
I learned the value of pair programming this week, at least i learned a new value to pair programming. I worked with Ron, who is the lead for out AI, and we did a lot of pair programming. When we first started to have some of our programmers work on AI, I mentioned the approach I felt would be best for implementing the AI character; however, I wasn't working on AI at all and so they ended up taking it a different direction. I think that even though I originally showed everyone the code and the way it was structured, the programmers didn't fully understand the strengths of the entities and components, and some might have even felt intimidated by the code base. But doing some pair programming helps to align everyone to the same vision of the game and the engine. I hope to do more of this to help instill more confidence in all of the programmers in going out into uncharted territories and build new systems needed for the game.
Having worked with Ron we ended up pretty much where I had originally envisioned the AI systems, being that there is a base Character entity that is used for both the player and NPCs. This Character object then has different components for handling movement, state changing, ability control, etc. The player has a PlayerInputController and the AI has an AiInputController that the movement state machine uses to move the player around. This may or may not be the ideal way to do this, as I'm no expert on AI, but I felt this would be a good approach as harnesses our movement state machine which was in place for the player with no code duplication. The AI will now not be able to move when he is knocked off his feet by the player, without the AI code needing to know that. Each AI state (the AI also uses states to manage which task is at hand, such as patrolling, chasing the player, searching for the player, capturing the player, etc.) The AI can just continually "press" the thumbstick the direction he needs to go to get to his target, and if his movement state is affected by some external force, it won't break the game. His movement wont override the forces, as the movement is completely separate in a different component.
Aside from the refactioring I also finished setting up the AbilityController allowing abilities to easily be mapped to different buttons. When the button is pressed, the controller will spawn a new entity for the ability. Each ability will have it's own components (if needed) if it is a projectile, a mine, or an AOE. By being an entity the ability can exist for just a moment to apply the effect and disappear, or it can persist for however long.
Currently I am working on some new movement states for putting the player in Limbo. I intend to work with Mavin on this as it will help him manage player jumps off of walls and such. There are times when the player needs to lose control of movement, and these limbo states will accomplish that. This will enable us to allow the player to move exactly how he wants, even in the air, -most of the time.- If, however, the player is thrown into the air by another player/guard, or jumps off of a wall, we may want to restrict or remove his/her control all together. These limbo states can then serve to manage the control restrictions, while still transitioning the player to a new state (perhaps a SittingOnGroundLimboState, when landing after being thrown, which requires the player's avatar to stand up before he can start running again.)
On a different note, I'm hoping to start doing video blogs in the future, that should help kill the Great Wall of Text that appears on all of my posts. :)
Having worked with Ron we ended up pretty much where I had originally envisioned the AI systems, being that there is a base Character entity that is used for both the player and NPCs. This Character object then has different components for handling movement, state changing, ability control, etc. The player has a PlayerInputController and the AI has an AiInputController that the movement state machine uses to move the player around. This may or may not be the ideal way to do this, as I'm no expert on AI, but I felt this would be a good approach as harnesses our movement state machine which was in place for the player with no code duplication. The AI will now not be able to move when he is knocked off his feet by the player, without the AI code needing to know that. Each AI state (the AI also uses states to manage which task is at hand, such as patrolling, chasing the player, searching for the player, capturing the player, etc.) The AI can just continually "press" the thumbstick the direction he needs to go to get to his target, and if his movement state is affected by some external force, it won't break the game. His movement wont override the forces, as the movement is completely separate in a different component.
Aside from the refactioring I also finished setting up the AbilityController allowing abilities to easily be mapped to different buttons. When the button is pressed, the controller will spawn a new entity for the ability. Each ability will have it's own components (if needed) if it is a projectile, a mine, or an AOE. By being an entity the ability can exist for just a moment to apply the effect and disappear, or it can persist for however long.
Currently I am working on some new movement states for putting the player in Limbo. I intend to work with Mavin on this as it will help him manage player jumps off of walls and such. There are times when the player needs to lose control of movement, and these limbo states will accomplish that. This will enable us to allow the player to move exactly how he wants, even in the air, -most of the time.- If, however, the player is thrown into the air by another player/guard, or jumps off of a wall, we may want to restrict or remove his/her control all together. These limbo states can then serve to manage the control restrictions, while still transitioning the player to a new state (perhaps a SittingOnGroundLimboState, when landing after being thrown, which requires the player's avatar to stand up before he can start running again.)
On a different note, I'm hoping to start doing video blogs in the future, that should help kill the Great Wall of Text that appears on all of my posts. :)
Tuesday, November 6, 2012
Developers Log. Development Date 21 - Abilities and Combat
This week I had to do some of the awkward parts of being team lead, namely having a discussion with a team member about their time management in regards to the class work. Overall I feel it went rather well, we were both able to express some concerns and gain a better understanding of each other. It was a good experience.
Within the realm of programming I have been working on a combat system. We have decided to have an ability based combat, rather than a Ninja Gaiden style of hack and slash style using a physical weapon. We still lack a concrete vision for the controls for the combat- so I leaned on Ross, our design lead, a lot this week to help find the direction in which to implement the system.
Currently we have an AbilityController component that spawns an Ability Entity. This allows each ability to have multiple components. Using an Entity allows the spell to either follow the player, or be projected out.
I've only integrated just one ability so far. It's a gravity pulse that, when triggered, finds all of the non allied characters around the player in X radius and flings them in the direction between them and the player, but with a much larger force, so that they go flying past the player. This simulates the player drawing gravity in towards him/her with great force for a split second. It's quite fun to blast two guards on either side of you and watch them fly past each other in the air.
I had to make some changes to the AI that Ron has been working on, as he wasn't using the physics body component, and was absolutely setting the position each update. This prevented me from being able to throw the characters, since they would just instantly revert their position and no longer have any forces applied to them.
Moving forward I will be creating a character class that will serve to be a player, citizen, guard, etc. Simply adding different components, such as an input component or ai component, will make all of the difference for what the character is.
Subscribe to:
Posts (Atom)