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.
Monday, October 29, 2012
Developers Log. Development Date 13 - Components and Entities
The project is moving along nicely. Lots of game defining this past week. Locking down the goals of the game is really important, and we have had great strides in that department. Additionally we have been tossing out names for the team/business and are now voting on them. Exciting times!
The rabbit hole I journeyed down this past week, and then clambered back up once I reached the bottom, was a code restructure for a component driven entity system. I wanted to get this done so that the team could begin work on some AI systems and allow the creation of different NPCs with different components.
I decided to keep the entity system pretty basic and ride the coat tails of the components already a part of the XNA framework. This required me to simply have an abstract entity class that handled adding, removing, and checking for components while restricting them to be a GameComponent. Here is the basics of an Entity:
Outside of that, I moved onto refining controls. The in air controls are much more smooth. The velocity is captured upon entering the in-air state. Each update it progresses from its movement to the desired movement (the max move speed multiplied by the input vector.) This allows the player to jump while standing, and achieve full move speed in the air, but it takes longer than it would on the ground. Additionally, the player can let go of the thumbstick mid air and after a very brief delay come to a stop. It feels much better this way, and I am pretty satisfied with the results.
After having in air controls working, I was able to move onto wall jumps. This was previously problematic as the in air controls would either remove all velocity, or do weird things to it (depending on which version I was using.) Once the controls were working, everything else was cake.
Lastly I did a cleanups of removing friction from walls, fixing the timestep in the physics engine to stop the player from passing through walls at high velocity.
I intend to move forward adding some time between rotation (as it is currently instantaneous.) While we want it to be near instantaneous, there needs some time for animations to make everything look smooth and believable-- but still fast and agile as only a true ninja can move. That will carry me through the sprint after which I will be working on the combat system framework so that we can start to get that ball rolling!
The rabbit hole I journeyed down this past week, and then clambered back up once I reached the bottom, was a code restructure for a component driven entity system. I wanted to get this done so that the team could begin work on some AI systems and allow the creation of different NPCs with different components.
I decided to keep the entity system pretty basic and ride the coat tails of the components already a part of the XNA framework. This required me to simply have an abstract entity class that handled adding, removing, and checking for components while restricting them to be a GameComponent. Here is the basics of an Entity:
Dictionary<Type, GameComponent> components;
public Entity() {
components = new Dictionary<Type, GameComponent>();
}
public bool HasComponent<T>() where T : GameComponent {
return components.ContainsKey(typeof(T));
}
public T GetComponent<T>() where T : GameComponent {
if (HasComponent<T>())
return components[typeof(T)] as T;
return null;
}
public T AddComponent<T>(T component) where T : GameComponent {
components.Add(typeof(T), component);
return component;
}
public void RemoveComponent<T>() where T : GameComponent {
if (HasComponent<T>())
components.Remove(typeof(T));
}
Outside of that, I moved onto refining controls. The in air controls are much more smooth. The velocity is captured upon entering the in-air state. Each update it progresses from its movement to the desired movement (the max move speed multiplied by the input vector.) This allows the player to jump while standing, and achieve full move speed in the air, but it takes longer than it would on the ground. Additionally, the player can let go of the thumbstick mid air and after a very brief delay come to a stop. It feels much better this way, and I am pretty satisfied with the results.
After having in air controls working, I was able to move onto wall jumps. This was previously problematic as the in air controls would either remove all velocity, or do weird things to it (depending on which version I was using.) Once the controls were working, everything else was cake.
Lastly I did a cleanups of removing friction from walls, fixing the timestep in the physics engine to stop the player from passing through walls at high velocity.
I intend to move forward adding some time between rotation (as it is currently instantaneous.) While we want it to be near instantaneous, there needs some time for animations to make everything look smooth and believable-- but still fast and agile as only a true ninja can move. That will carry me through the sprint after which I will be working on the combat system framework so that we can start to get that ball rolling!
Tuesday, October 16, 2012
Developers Log. Development Date 2 - State machine
Despite the exciting news of Ninja Royale being selected (!) I opted to enjoy my fall break and stay away from the blog. That doesn't mean, however, that I didn't stay away from coding, as I had much to get ready before letting the group run wild with the code. I wanted to make sure what we were keeping was in a solid state and would be a good and reliable architecture for us moving forward.
This past week I worked on completely removing all of the abilities we had, and converting them to states, with a state machine. Each state has a animation that is playing and a movement controller. States are responsible for animating the player, and changing states (from being in the air, to on the ground, to running up a wall, to hanging, to climbing, etc.) Movement controllers however are responsible for movement, obviously. We currently have 5 movement controllers: OnGround, InAir, Hanging, HorizontalWallRun, and VerticalWallRun. I'm sure we will add a few more, but that is those are the core movement controllers, and each state uses just one, depending on the state, obviously.
The biggest concern right now is "What is the game?" We got shut down pretty hard for making a multiplayer game. That doesn't mean we won't have multiplayer in the end, but that can't be the game, or the focus. Right now I'm leaning towards a single player/co-op experience. The thing that scares me about that is story, I'm terrible at creating a story. Luckily I have a group of ten other individuals who will be able to be the creative driving force for that. Once we narrow down what the game is we want to create, we will really be able to start deciding what is most important to get done first, set modular mile stones and start pumping out a game!
This past week I worked on completely removing all of the abilities we had, and converting them to states, with a state machine. Each state has a animation that is playing and a movement controller. States are responsible for animating the player, and changing states (from being in the air, to on the ground, to running up a wall, to hanging, to climbing, etc.) Movement controllers however are responsible for movement, obviously. We currently have 5 movement controllers: OnGround, InAir, Hanging, HorizontalWallRun, and VerticalWallRun. I'm sure we will add a few more, but that is those are the core movement controllers, and each state uses just one, depending on the state, obviously.
The biggest concern right now is "What is the game?" We got shut down pretty hard for making a multiplayer game. That doesn't mean we won't have multiplayer in the end, but that can't be the game, or the focus. Right now I'm leaning towards a single player/co-op experience. The thing that scares me about that is story, I'm terrible at creating a story. Luckily I have a group of ten other individuals who will be able to be the creative driving force for that. Once we narrow down what the game is we want to create, we will really be able to start deciding what is most important to get done first, set modular mile stones and start pumping out a game!
Monday, October 1, 2012
Developers Log. Prototype Date 28 - Final Prototype Date
Today is the last day to work on the prototype. This weekend I fixed multiplayer, and it's awesome. There is a short clip of it working in our video we will be showing in the presentation. I also fixed the animations glitches we were seeing. Lastly I added the ability to run up a wall, and either flip off (to dodge an incoming attack) or grab a ledge-- it's pretty sexy.
We had a big discussion friday night/saturday morning about the gameplay, and ended up in a really great place, I feel. This was a big milestone, as we hadn't really set out to define the game rules, just the mechanics. After a lot of discussion we found something that we all would love to play.
I'm not sure if this will be read before the game is picked, but I must admit that I understand the ambition this project carries. It will no doubt require a lot of work from everyone involved to make it awesome, but I think it is absolutely do-able. I would very much enjoy working on this for the next year with dedicated and talented students who also desire to make an amazing game. Most of my team has worked their tails off these past few weeks to make the best prototype we could in the short time we had, and we are pretty happy with where the prototype is. It shows off Avatars working in a 3D environment, using custom animations, with multiple players, parkouring around. So much for 28 days with just four guys! Give us a full team and a year and this will be a polished, beautiful game that will give us great experience and a fantastic portfolio piece!
And with that, I guess I will see you on the other side.*
* Other side refers to the time in which the 3 games have been chosen and I have been assigned to the game I will work on for the next year. [Hopefully still Ninja Royale!] :)
We had a big discussion friday night/saturday morning about the gameplay, and ended up in a really great place, I feel. This was a big milestone, as we hadn't really set out to define the game rules, just the mechanics. After a lot of discussion we found something that we all would love to play.
I'm not sure if this will be read before the game is picked, but I must admit that I understand the ambition this project carries. It will no doubt require a lot of work from everyone involved to make it awesome, but I think it is absolutely do-able. I would very much enjoy working on this for the next year with dedicated and talented students who also desire to make an amazing game. Most of my team has worked their tails off these past few weeks to make the best prototype we could in the short time we had, and we are pretty happy with where the prototype is. It shows off Avatars working in a 3D environment, using custom animations, with multiple players, parkouring around. So much for 28 days with just four guys! Give us a full team and a year and this will be a polished, beautiful game that will give us great experience and a fantastic portfolio piece!
And with that, I guess I will see you on the other side.*
* Other side refers to the time in which the 3 games have been chosen and I have been assigned to the game I will work on for the next year. [Hopefully still Ninja Royale!] :)
Thursday, September 27, 2012
Developers Log. Prototype Date 24 - Game Demo Day - The Dry Run
Today we demo everything, that means we had to get everything to a "that will have to do" state. The game is coming along and is looking pretty good. We made a few strides with streamlining the way we get animations in, so that is good. The wall climb logic is mostly done (well, as done as it will get for the pitch this Tuesday.) The wall run is pretty much done too, but the wall jump needs some loving.
I still want to work with air controls, I have spent no time with them, so they behave just as they do when the player is on the ground, and it doesn't feel right to me at all.
I've started sketching out an actual state machine. It's something I probably wont have time to get in by Tuesday, but it's definitely the model we will want to follow for the game if it is picked (and I sincerely hope it will be.) We have so many animations and transations and movement controllers that it will get out of control without states passing around to each other like a perfectly build machine. It will be very sexy.
One of the most disappointing bugs to be discovered last night was that somewhere over the past few days a bug was introduced that kills multiplayer. The game closes on the xbox, which in turn closes my debugger so I cannot even trace the error back to the cause, so I'm going to have to do this the painful way. Grrr. I really want to have this done by Tuesday, so that will probably be my first focus this weekend.
I still want to work with air controls, I have spent no time with them, so they behave just as they do when the player is on the ground, and it doesn't feel right to me at all.
I've started sketching out an actual state machine. It's something I probably wont have time to get in by Tuesday, but it's definitely the model we will want to follow for the game if it is picked (and I sincerely hope it will be.) We have so many animations and transations and movement controllers that it will get out of control without states passing around to each other like a perfectly build machine. It will be very sexy.
One of the most disappointing bugs to be discovered last night was that somewhere over the past few days a bug was introduced that kills multiplayer. The game closes on the xbox, which in turn closes my debugger so I cannot even trace the error back to the cause, so I'm going to have to do this the painful way. Grrr. I really want to have this done by Tuesday, so that will probably be my first focus this weekend.
Tuesday, September 25, 2012
Developers Log. Prototype Date 22 - Abilities and Movement Controllers
The biggest woe of the week was finding out that our physics engine, JigLibX, is failing on the xbox. The .DLL was causing the xbox to crash. After an hour and a half of trying to fix it, I decided to switch physics engines. I could have left it, as it worked fine on the pc, but I really want to show the avatars performing the actions. So I bit the bullet and set off to change out the physics engine. Fortunately I had created a PhysicsBody class that served as a wrapper for the physics controls on the player (managing movement, gravity, dimensions, etc.) This was the only class I had to change, essentially changing where the wires are plugged in, to get the new engine to work. Unfortunately, I first tried Jitter, which didn't work so well, and so I finally settled on BEPU Physics. Third time is the charm.
On top of getting a shiny new physics engine, I decided to change movement from being directly contained within the Player class, to being inside of a MovementController. I then split this into 4 classes: GroundMovementController, AirMovementController, WallHangingMovementController, and WallRunningMovementController.
Each of these controllers constantly monitors when it should start applying movement to the player physics body. This prevents convoluted code within the player class, each condition requiring conditions and flags that would be must be switched on and off. Instead, each controller has clean and manageable code that uses the StateManager to detect when the player is against the wall, on the ground, in the air, or etc. Each controller also has its own stats for movement, how movement is changed (for example, on the ground the velocity is set each update, whereas the air controller preserves velocity, altering it only a fraction of the amount, thus preserving momentum, but still giving the player some control, but less than when on the ground.) This enables us to change mechanics for movement easily without effecting everything else, or wading through dozens of variables, each for the various conditions.
Lastly, I have implemented the DoubleJumpAbility, WallRunAbility, and WallHangAbility. I'm not finished with wall run just yet, and also need to add an ability for when the player wishes to pull himself up off of a ledge. Everything is going very smoothly following this architecture, and I feel I have been able to accomplish a lot in a short amount of time, which is absolutely necessary because I have so little time left before we demo the prototype :X
On top of getting a shiny new physics engine, I decided to change movement from being directly contained within the Player class, to being inside of a MovementController. I then split this into 4 classes: GroundMovementController, AirMovementController, WallHangingMovementController, and WallRunningMovementController.
Each of these controllers constantly monitors when it should start applying movement to the player physics body. This prevents convoluted code within the player class, each condition requiring conditions and flags that would be must be switched on and off. Instead, each controller has clean and manageable code that uses the StateManager to detect when the player is against the wall, on the ground, in the air, or etc. Each controller also has its own stats for movement, how movement is changed (for example, on the ground the velocity is set each update, whereas the air controller preserves velocity, altering it only a fraction of the amount, thus preserving momentum, but still giving the player some control, but less than when on the ground.) This enables us to change mechanics for movement easily without effecting everything else, or wading through dozens of variables, each for the various conditions.
Lastly, I have implemented the DoubleJumpAbility, WallRunAbility, and WallHangAbility. I'm not finished with wall run just yet, and also need to add an ability for when the player wishes to pull himself up off of a ledge. Everything is going very smoothly following this architecture, and I feel I have been able to accomplish a lot in a short amount of time, which is absolutely necessary because I have so little time left before we demo the prototype :X
Tuesday, September 18, 2012
Developers Log. Prototype Date 15 - Players, Cameras, and Abilities - Oh my!
The previous blog was short by design; I wanted to keep it short and simple in the event that someone stumbles upon it, via their favorite search engine, in search for help in getting JigLibX to work on XNA 4.0. Much more has happened the past week or so than just getting JigLibX integrated, and I want to briefly overview that here.
First, we are not only just loading each player's avatar now (tested with 2 signed in players, but should support up to 4,) but we have custom animations working. These were huge choke points that were great to get passed, now the animators can start animating and see their work.
The Player class reads controller input and plays animation when different buttons are pressed. Additional advancements for the player are a Camera class that is self governing, draws just the viewport, renders each object on the screen for it's perspective, and follows around it's target (the player) with some nice smooth motions to keep crisp feeling with the camera. (Oh yeah, the player moves about now too.) The camera still lacks in logic to prevent a wall from cutting off sight of the target, but I don't anticipate having time to implement that before the prototype is done. It's not that it will be painfully hard to do, I just have too many other priorities to get done in too little of time.
I then created a PhysicsBody class which is entirely responsible for the Player's position, rotation, and collisions . A physics body can have more than one JigLibX physics body, so that we can build our avatar's collision system with multiple simple collision bodies. This will be useful for detecting when a player can grab a ledge, run on a wall, etc, as we need to be sure certain proportions of the body are in specific spatial locations.
Lastly I created an abstract Abilities class that is a GameComponent. All abilities (from jump, to grapling hook) will be an Ability and can thus have Activate called on them. Each component is self governing, so that it knows how to behave pre-activation, during activation, and post activation. This enables us to have a powerful base for iteration as well as modification. Keeping the code modular we can throw away code in the iterative process without breaking anything else. I built a Jump ability and got that working very easily. I am excited to move forward with this.
Currently I am working on a StateManager that will clear the states each update, and whenever a state is asked for, it will be determined with a small raycast. The state will be stored to keep the number of raycasts limited to at most 5 (currently, for the 5 directions I am checking) each update. This is important for all of the acrobatic abilities we will have, (wall runs, wall jumps, etc.)
The other pot my hand is in is getting a debug drawing working for each collision body so that I can see what is going on. I hope to also be able to draw the rays I am casting, with color coordination for if they are detecting a collision. This is mostly for me to be able to verify all my code is working exactly the way I want, and see any ways to improve upon it.
First, we are not only just loading each player's avatar now (tested with 2 signed in players, but should support up to 4,) but we have custom animations working. These were huge choke points that were great to get passed, now the animators can start animating and see their work.
The Player class reads controller input and plays animation when different buttons are pressed. Additional advancements for the player are a Camera class that is self governing, draws just the viewport, renders each object on the screen for it's perspective, and follows around it's target (the player) with some nice smooth motions to keep crisp feeling with the camera. (Oh yeah, the player moves about now too.) The camera still lacks in logic to prevent a wall from cutting off sight of the target, but I don't anticipate having time to implement that before the prototype is done. It's not that it will be painfully hard to do, I just have too many other priorities to get done in too little of time.
I then created a PhysicsBody class which is entirely responsible for the Player's position, rotation, and collisions . A physics body can have more than one JigLibX physics body, so that we can build our avatar's collision system with multiple simple collision bodies. This will be useful for detecting when a player can grab a ledge, run on a wall, etc, as we need to be sure certain proportions of the body are in specific spatial locations.
Lastly I created an abstract Abilities class that is a GameComponent. All abilities (from jump, to grapling hook) will be an Ability and can thus have Activate called on them. Each component is self governing, so that it knows how to behave pre-activation, during activation, and post activation. This enables us to have a powerful base for iteration as well as modification. Keeping the code modular we can throw away code in the iterative process without breaking anything else. I built a Jump ability and got that working very easily. I am excited to move forward with this.
Currently I am working on a StateManager that will clear the states each update, and whenever a state is asked for, it will be determined with a small raycast. The state will be stored to keep the number of raycasts limited to at most 5 (currently, for the 5 directions I am checking) each update. This is important for all of the acrobatic abilities we will have, (wall runs, wall jumps, etc.)
The other pot my hand is in is getting a debug drawing working for each collision body so that I can see what is going on. I hope to also be able to draw the rays I am casting, with color coordination for if they are detecting a collision. This is mostly for me to be able to verify all my code is working exactly the way I want, and see any ways to improve upon it.
Monday, September 17, 2012
Developers Log. Prototype Date 14 - JigLibX and XNA 4.0
*Edit* The following left me with a few xbox 360 exclusive errors that were not apparent when I was running on windows. After jumping through a few more hoops, I was still unable to get it to run correctly on the xbox, and switched to BEPU Physics. So these steps won't actually get JigLibX running on XNA 4.0 for the xbox.
Having looked through a few of the top 3D open source XNA physics engines such as Jitter, BEPU Physics, and JigLibX I felt that JigLibX was the best fit for what we needed. I particularly liked the component style of framework, it meshes well with XNA. There are several other implementation styles and core mechanics about it that I liked, so it was selected to be the physics engine for Ninja Royale's prototype.
The major issue with JigLibX is that it hasn't had an update since XNA 4.0 came out, so the version downloaded from the website wouldn't work with the project we have. Here is how I solved this problem:
Get the latest from JigLibX's SVN. You can find the SVN here. noone88 (The original author I believe, certainly the main contributor) ported the project to XNA 4.0.
The project I downloaded still didn't work. Visual Studio was having problems with converting the project, so I had to edit the file JigLibX Xbox 360.csproj using a text editor (open with -> notepad, for example.)
The first line to look for, found near the top, is this
Simply change the v2.0 to v4.0 and voila!
Okay, so not voila just yet, but almost. Just find these two lines, found close to the bottom:
You can either remove them, or comment them out (I chose to just comment them out). I was unable to find anything similar from my XNA 4.0 install, so I commented them out and everything seems to work just fine. [*Note, to comment them out, simply surround the lines with the opening tag "<!--" and the closing tag "-->" excluding the quotes, of course]
Having looked through a few of the top 3D open source XNA physics engines such as Jitter, BEPU Physics, and JigLibX I felt that JigLibX was the best fit for what we needed. I particularly liked the component style of framework, it meshes well with XNA. There are several other implementation styles and core mechanics about it that I liked, so it was selected to be the physics engine for Ninja Royale's prototype.
The major issue with JigLibX is that it hasn't had an update since XNA 4.0 came out, so the version downloaded from the website wouldn't work with the project we have. Here is how I solved this problem:
Get the latest from JigLibX's SVN. You can find the SVN here. noone88 (The original author I believe, certainly the main contributor) ported the project to XNA 4.0.
The project I downloaded still didn't work. Visual Studio was having problems with converting the project, so I had to edit the file JigLibX Xbox 360.csproj using a text editor (open with -> notepad, for example.)
The first line to look for, found near the top, is this
<XnaFrameworkVersion>v2.0</XnaFrameworkVersion>
Simply change the v2.0 to v4.0 and voila!
Okay, so not voila just yet, but almost. Just find these two lines, found close to the bottom:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v2.0\ Microsoft.Xna.GameStudio.Common.targets" /> <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v2.0\ Microsoft.Xna.GameStudio.NestedContent.targets" />
You can either remove them, or comment them out (I chose to just comment them out). I was unable to find anything similar from my XNA 4.0 install, so I commented them out and everything seems to work just fine. [*Note, to comment them out, simply surround the lines with the opening tag "<!--" and the closing tag "-->" excluding the quotes, of course]
Thursday, September 6, 2012
Developers Log. Prototype Date 3. - Games we can learn from
Here is a list of five games that have ideas, controls, or gameplay mechanics worth looking at for either a single player or multiplayer game (or both.) I wanted to look into both, not yet being decided on the exact game we will be making:
1.
Mark of the Ninja - A interesting 2D ninja stealth game being developed
for XBLA. If we go single player/co-op this is worth studying. The pace
and puzzles are really intriguing. I especially like how it seems that
there are several ways to move around the map, going past the guards
through the front door, finding a way to go above, or through a vent
beneath. Video
2.
Splinter Cell Conviction: Co op - A great game that capitalizes on
stealth co-op gameplay. Splinter cell is also great for integrating
multiple entry paths to an objective, offering a unique experience for
each player, which adds to the life of a game. Video
3. Assassin's
Creed - An amazing example of fluid controls. the game is set up in
such a way that a completely new city is easily navigated using the
acrobatics in place one the player has mastered the controls. By
repetition the player learns what can be used to grab on to, swing from,
slide down, or safely jump off. The player can master the controls and
feel awesome as he/she travels about accomplishing goals. The fluidness
of both the controls and the level design is important to study for what
we will be making.
4.
Mario Kart Battle Snes/N64 - Both of these versions offer amazing
gameplay on just a few levels. The randomness of the item pickup adds to
the re-playability, as each round is different. Items are given out at a
fast enough pace that the player is expected to miss attacks more often
than not, making successful hits give a feeling of mastery and accomplishment.
5. Ninja Gaiden - Originally I hoped to observe controls with regards to movement and wall running and such, but ended up being mostly intrigued by the camera. Unlike in Batman: Arkham City the camera doesn't just follow the player, but it acts more like a movie. The player can control the camera, and set the angle which he/she wishes to view the action. Left on the joystick is always left relative to the camera, and not the player. This works very well and feels surprisingly natural. Both control styles work, and we will definitely need to experiment and see which we like better.
Tuesday, September 4, 2012
Developers Log. Prototype Date 1. - First coding
Ninja Royale was picked as one of the eight games to be prototyped, which is awesome! One of the main points we discussed as a team after having talked with Rodger and Bob about the game's potential, and things to be cautious of, was the importance of not being married to any one idea just yet. While the original pitch was a ninja-arena-battle game with avatars, we want to be sure to be open to, and testing, other game aspects. Certainly being cautious of the multiplayer deathtrap of indie games, we explored ideas with single player and co-op, both with and without stealth mechanics. Rodger's idea of creating a game with such tightness and polish that players could master and create strategy over, effectively creating a sport was a big hit too. (As a highly competitive League of Legends player myself, I definitely enjoyed this suggestion.) The addition of skill trees or skill sets was interesting as well, and something I hadn't thought of much before, but is most certainly worth exploring. Such concepts as a ninja being expert in stealth, agility, or distraction etc (or even non-ninja classes) is very intriguing and will require further thought.
Jumping in head first, Adam and I went to the EAE lab after our cs3130 class and got a simple avatar running around. I just downloaded a simple code sample and ran it, nothing too code heavy, but I wanted to get the experience before heading to work. (Sadly, my Xbox is currently sporting the "Red ring of death" fashion statement, so I won't be able to test avatar code within the comforts of my own home.) I just barely finished a Player class that contains all of the logic for setting up a player viewport. I am rather pleased with the code, as it is very crisp and dynamic. I could easily add a method with just a few lines of code that would allow for players to leave or join the game at anytime, instantly changing up the viewports on the screen. While this doesn't seem practical for our game idea, it's nice to have such possibilities come to mind having a clean foundation for our player objects.
Carrying forward that will be a major focus of mine, keeping a clean modular architecture. I feel this is key in allowing us to easily expand and grow our code base, being most optimal for when five or so more programmers start working on the game as well. Additionally, this serves the prototype phase very well, allowing us to remove gameplay code that ends up not being what we want, without bringing the game to it's knees because the code was so heavily woven within the game's engine.
The next phase, now that my split screen code is setup (supporting 1-4 players) is to give each player their avatar to be played. I anticipate having this done by Thursday so that I am able to go test it (and fix anything that doesn't work correctly) in the lab.
Jumping in head first, Adam and I went to the EAE lab after our cs3130 class and got a simple avatar running around. I just downloaded a simple code sample and ran it, nothing too code heavy, but I wanted to get the experience before heading to work. (Sadly, my Xbox is currently sporting the "Red ring of death" fashion statement, so I won't be able to test avatar code within the comforts of my own home.) I just barely finished a Player class that contains all of the logic for setting up a player viewport. I am rather pleased with the code, as it is very crisp and dynamic. I could easily add a method with just a few lines of code that would allow for players to leave or join the game at anytime, instantly changing up the viewports on the screen. While this doesn't seem practical for our game idea, it's nice to have such possibilities come to mind having a clean foundation for our player objects.
Carrying forward that will be a major focus of mine, keeping a clean modular architecture. I feel this is key in allowing us to easily expand and grow our code base, being most optimal for when five or so more programmers start working on the game as well. Additionally, this serves the prototype phase very well, allowing us to remove gameplay code that ends up not being what we want, without bringing the game to it's knees because the code was so heavily woven within the game's engine.
The next phase, now that my split screen code is setup (supporting 1-4 players) is to give each player their avatar to be played. I anticipate having this done by Thursday so that I am able to go test it (and fix anything that doesn't work correctly) in the lab.
Tuesday, August 28, 2012
Developers Log. Pitch Date 1. - Ninja Royale
I finished the pitch for a 3D Mario Kart battle / Assassins Creed mix played with Xbox Avatars. As gameplay is one of the most enjoyable aspects of a game for me to program, I wanted to develop a game with a world, physics, and mechanics that are inherently fun to play with. Packaging objectives and challenges on top of that will hopefully create an experience that not only I would enjoy playing, but many others would too.
This lead me to the idea of playing as a ninja, with the ability to run on walls, leap from building to building, and do flips mid air to dodge incoming projectiles. If the controls are done right, the user will be able to master the controls and feel awesome competing in this environment. I've always loved the SNES and N64 Mario Kart battle games; despite the limited number of levels, I could never get enough of the competitive play. I feel following a similar game design will give a long life to our game, despite our limited time to create only a handful of levels.
I have a fear that the idea will get shot down because it is 3D and perhaps seems too hard to polish. Obviously I have never developed something of this magnitude, and I recognize my own tendencies to underestimate scope at times, but I do feel that with a solid team this project could most definitely be pulled off. I spent a few hours of time in Unity3d creating a engine using my own physics and collision (rather than using Unity's.) Currently I have a ninja character Max Locher threw together for me, that runs on walls (and jumps between two parallel walls while running forward), runs up walls, picks up items, and more. The only thing missing here is handling our own graphics which we will have to do in XNA, as opposed to using Unity's graphic rendering capabilities.
The last concept of using the player's Xbox avatar accomplishes two main goals. First, it gives us a crisp and polished model to use that helps set the mood of being less realistic driven. The game will instantly have an infinite number of variety for the models, as each player will have a unique custom avatar. The second goal accomplished is that it helps draw in the audience we are developing for. Many of the players heavily involved with indie games will have spent time customizing their avatar, and some will have spent money on their avatar-- so being able to play their avatar as a freaking ninja should be a pretty big appeal for a lot of people!
This lead me to the idea of playing as a ninja, with the ability to run on walls, leap from building to building, and do flips mid air to dodge incoming projectiles. If the controls are done right, the user will be able to master the controls and feel awesome competing in this environment. I've always loved the SNES and N64 Mario Kart battle games; despite the limited number of levels, I could never get enough of the competitive play. I feel following a similar game design will give a long life to our game, despite our limited time to create only a handful of levels.
I have a fear that the idea will get shot down because it is 3D and perhaps seems too hard to polish. Obviously I have never developed something of this magnitude, and I recognize my own tendencies to underestimate scope at times, but I do feel that with a solid team this project could most definitely be pulled off. I spent a few hours of time in Unity3d creating a engine using my own physics and collision (rather than using Unity's.) Currently I have a ninja character Max Locher threw together for me, that runs on walls (and jumps between two parallel walls while running forward), runs up walls, picks up items, and more. The only thing missing here is handling our own graphics which we will have to do in XNA, as opposed to using Unity's graphic rendering capabilities.
The last concept of using the player's Xbox avatar accomplishes two main goals. First, it gives us a crisp and polished model to use that helps set the mood of being less realistic driven. The game will instantly have an infinite number of variety for the models, as each player will have a unique custom avatar. The second goal accomplished is that it helps draw in the audience we are developing for. Many of the players heavily involved with indie games will have spent time customizing their avatar, and some will have spent money on their avatar-- so being able to play their avatar as a freaking ninja should be a pretty big appeal for a lot of people!
Subscribe to:
Posts (Atom)