Week 1

Anyway, this week has only had a little work on prototypes, sadly. A great deal of our time has been discussing and merging the different ideas we had into one set of mechanics to test together. My time was spent setting up our repo, and doing some quick work looking into the possibility of making our game in 2D.

Personally, after working on animation in 2D, I am personally against the idea.

It really depends on what Rebecca believes she can do in our time, whether she thinks she can do more art in 2D than 3D. It seems for the most part she cares little.

Working in 2D in Unity is interesting. I worked with it on Dungeons of Londree, where are environment was completely done in 2D art. Pieces of it were animated, so I thought I might be able to reuse the code for that. Unfortunately that code was made for a single animation, running through a single texture source. Parts were relevant, but it would need some modification (animation starting a certina frames of the sprite sheet, etc, instead of the whole sheet.

We were also working in M.U.G.E.N and looking at other 2D engines. Donny was looking into it for a prototype of our control scheme. It was not as easy as we had imagined and we spent a good deal of time looking at it's design (as its a famous 2D fighting engine). We looked at editors made for it as well as engines made in other languages (Flash, C++, XNA). There were many things these games had that I had not thought about, including State Settings, Sounds etc. I had thought about them at a game wide level, but one thing that each of these engines made clear was how deeply they were integrated into the animations of the character. Most had sounds played from individual frames, states set from individual frames, as well as having individual hitboxes set up for each frame. I had know about the hitbox issues, but looking at the massive amounts of data for the frames made one thing quite clear: doing 2D meant ALOT of work for the designers. Each frame needs a hitbox, and while many can have the same hitbox, they still need to be set up. This could be reduced programmatically, and I could develop a system to automatically add boxes based on transparency., but it would still need a designer to edit EVERY. SINGLE. FRAME. Not cool.

Working in 2D also means we cannot make full use of Unity's animation system, as well as their collision system. We would still be using the collision system to do the detection of the hits, but we couldn't just attach it to the fists, and wait for a collision, we would have to manipulate a collider box through script every time the frame changed, a huge pain in the ass in comparison, and I think it would be less stable, as if we are changing the size of a collision box and the new box moves into another, we might not get the same effect as we would get with a normal collision that happens with transform movement (so instead of translating something, we would be changing the size of the box, not sure if Colliders would fire their events in this occasion. We could also still use Unity's Animation system, but the frame changing would need to be programmatically created from an editor. It would be the same as any other editor. We would be unable to blend animations together unless we wanted to do a multilayer sprite(body is one sprite set, each arm is a sprite set, etc) which would be an immense amount of work and setup. The alternative of course is a single sprite for animating, but this is an immense amount of work for the artist, as every combination of states that would look different wold need to be drawn, and programmatically we would be unable to blend.


3D on the other hand, allows us to make full use of most of Unity systems. The Engine is built for 3D, and has powerful editor systems. 3D animations would brought in with FBX importer, and we could add sound effects to the animations through Unitys Animation Event System, as well as state changes( or at least some of them, as others would be dealt with elsewhere, like when they get hit or are stunned).

Collisions would be much easier, instead of hit boxes in 2d and changing properties continually, we could add simple colliders to the bones of the rig then check the collider around the fist for hitting another player. This could be set up once, as the colliders would animated with the character.

Animations can also be blended together both with standard blending and additive blending. Unity Animation Scripting. Currently this is all done through script, but I have some stuff from the summer that open it up to be edited a little closely, removing particular transforms from an animation(so we could for instance take the arms of a punch animations and overwrite another animations arms using it).

There are also many shaders that can work for 3D that would be unavailable for 2d(since there would be no vertex data), though there are also pixel shaders that we cannot use on 3d that we could on 2D.

There is the potential of using physics for the knock backs, instead of having them animated. This is not planned at the moment, but a thought to reduce animations, having the falling done through physics would reduce alot of the workload from Rebecca.

I also worked in Unity networking, getting the basic example working and looking at update times. While I am really interested in doing multiplayer, I won't lie, I am quite worried about networking. It doesn't seem particularly difficult, but in a game where timing is EVERYTHING, having event a fraction of a second delay could be critical.

All in all, we got alot of figuing out things done this week. We have more or less decided on going with 3D, we are prototyping the mechanics individually, and the game is coming into its own. Next week we are developing a 3D prototype of the controls on the xbox controller, and I am doing a proof of concept of the animation system for combos.

WWWWWWWWWWWWWWEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE.