Week 3/4/5?

What week is it now? Seriously I don't even know. Classes seem to all melt into one another.

Work has been pretty overwhelming. Luckily, both AI and Networking have pushed back expected due dates, so I have been able to catch up.

Anyway, as for Senior Team...

These past few weeks have been very interesting.

We split up our prototype into individual mechanics and iterated on each individually. The main things that we iterated on were controls, camera and health system.
In doing so, we have discovered our purpose for making this game, which makes me very excited.

The controls were a main priority. Both the team and tester feedback support our move towards the flickit controls, using the right and left bumpers to set whether the fighter is in Punch or kick mode, and the using the right stick to attack. Unity's input system, either because of the way is built or because of an inherit delay from the hardware, seems to be sluggish when responding to input. It it subtle but is enough to notice after a while. I am planning to try using the Raw Axis data from the controllers as input  We will lose much of unity input benefits, but should gain a good bit of precision for the input data.

[ A week of ignoring this blog post later... ]


This past week was spent learning Strumpy's Shader Editor and working on several iterations of the shader we want to use for some of the comics.

Through a mixture of light manipulation, rim darkening we got the comic look, and manipulating the light ramp texture allows us to perhaps use it for various ages.

I added a screen detail aspect to the shader itself, with uses the screen coordinated of the fragment to use as uvs on a texture.

I used a model of superman, since he was of similar proportions and color scheme, and because I could compare my results with actual superman comics from that age.

In the end though, it seems Rebecca does not want to go with this style. While I think that making each character have a distinct age feel would be much cooler artistically, the reality is that it presents a large number of issues. Firstly is in shader requirements. having multiple styles means very different materials and probably multiple shaders, which can take a lot of time. I had proposed to counter this with tools like SSE, and I think I was moderately successful in creating the Golden Age shader, but by making all of the characters follow a similar art style, we can simplify out modeling pipeline and reduce the number of shaders that we need.

It will also help in terms of animation reuseability. One thing that really concerned me about styling the characters after different ages was the difference in mesh proportions. For instance, Superman's(Golden Age) upper body is massive compared to Spidermans(Silver Age). This could easily create issues where certain animation look good on one, but clip badly on another.

Finally, and most importantly, I think going for the more modern depiction of superheroes("amazing Spiderman") contributes more towards our goal of bringing new people into the genre. Our basis for the superhero route was use the increasingly popular superhero trend in recent years. Most people within our target audience would likely be unfamiliar with the styles of the Golden Age/Dark Age etc from the actual comics, but would be familiar with a more modern style seen in shows like Justice League/Batman/Spiderman etc. Because of this I think the more modern look would serve our purpose well, and probably better than a more classical era specific style for each character.

[And Another Week Gone by without posting (Bad Adam Bad)]

This week I focused on Art Pipeline for animations. We have been planning on using Motion Capture data as the basis of many of our attacks, but there are many steps to this that we need to make sure that we have down before we go into production. I learned a good bit about 3DS Max, and will continue to do so. I went through some tutorials on cleaning up mocap animation, and tried to do some myself with mixed results.Essentially, what I would like to do is use .BIP files, a biped animation file used in max, as the basic animation data. A good bit of motion capture data is found in the BVH format (Biovision Hierarchy), and can easily be converted to BIP in max. BIP file (Biped Animation) are easy to transfer between bipeds, so hopefully this will make our use of them easier.

I plan meeting Josh Buck on Monday with Rebecca, to see if he agrees and if he has any suggestions for our art pipeline. This weekend I will be revamping the controls to be sharper and more concise  as well as bringing in more animations  and putting them to a character controller. By next week, I hope to be able to show some really cool stuff.

I also included Lumos Analytics into our game, and used it during our testing sessions to watch for attack use as well as how many times players used the blocks. There were some interesting results from our first two play sessions, and we will need to address them in the coming weeks. At the moment it is hard to judge because of how little difference there is to the attacks. I will be adding an idea I had this week, where while performing certain attacks, the character will be "weak" to others (so if im doing a high kick, a low kick will devestate me) to see if this affects the numbers.

Sorry for the delayed post, things are hectic right now, and look to e more hectic next semester.

Peace!

Week 2

This week was dedicated to prototyping controls as well as an animation/state system for controlling the characters.

We had a couple control schemes going around over the past few weeks. While developing the control system, I was originally aiming for a scheme that we had discussed, but were not going with any more. This in and of itself was a non-issue, though it does show that this group depends more on docs than others that I have worked with. I will have to remember to check the documents on the project server periodically to make sure I am on the right track.
Still the control system is pretty easy to change and quickly modify. Unity's Input system is one of it's weak points, in my opinion. It is a deprecated system, that could certainly use some updates. It requires one to manually input each control, and in the case of having multiple controllers on one computer, one must put in each control for each controller, a painful, repetitive task, to say the least. Still, it is done. On the player controller side of things, I built the controls in such a way that the game logic is not looking for particular axis, but rather, the controller accesses objects that encapsulate the accessors to Unity's Input System. This indirection allows control input to be changed without having to access the code, most can be changed in the editor. This will help us modify and scale the controls.

As for the state system, I tried a couple ways of going about it, as well as testing the blending of animations into one another. I tried to keep in mind that we want to try making this work in a networked environment. I will be testing the feasibility of networking this coming week.

Basically the state system will control pretty much every action the player tales in the game. it will also will be responsible for controlling the animations and movement of the characters. The players will always be in a state, when they are knocked down, when they are idling, when they are in the air, as well as one for each attack that they are in. These states will control which state the player can go to from from that state, as well as what inputs take them to said state. For instance, the idle state will allow the player to jump, no other will allow the player to begin jumping, though I may change this to allow jumping to be queued after an attack(so if they hit up while an attack is executing, it will cause them to jump as soon as they are out of that state.) During an attack, the controls are being checked for an input for the next attack. At a certain point in the execution(lets say 50%) the input is not being queried any longer, and at a later point(lets say 75%) the state begins transition (blending animations together, etc). This delay between decision and execution is to allow some time for when we implement networking. This delay could be used to send the next state to the other player. This all theory, that will be put into implementation next week.The state system minimizes what data needs to be sent between clients, so hopefully, this will make it doable. At the same time, networking is certainly not necessary, so if we discover that getting the level of precision we need for a fighting game is not possible, we can scrap online multiplayer all together.

So yeah, controls, states, animation, and stuff. Hopefully the prototype I developed will allow Donny and Eric to test some of their controls and gameplay. We are trying both a brawler like SSBM, and a classic fighter like Tekken/Street Fighter, so we will see how this develops.