Christuserloeser wrote:...it looks absolutely fantastic as it is if you ask me.
But there are many problems.
One of them, for example, is that the gameplay is inconsistent across different machines. On the DC the controls feel clunky and laggy, it's harder to input special moves, and combos are harder to hit and perform. It also differs too much between my computer, Rodrigo's computer and my mom's computer. Their computers are faster, and it's impossible to do all the hits during several combos when playing in them.
This problem happens because in the Quake engine the gameplay and the physics runs at a variable framerate (also, it's thanks to its variable framerate that we can do FPS counters in QC). This isn't a big problem in Quake itself, but in one-on-one fighting games all the elements of the gameplay works so closely together that the game must have perfect synchronism and rigid timing. The video itself may have a variable framerate, but the rest mustn't. And this is not how the Quake engine works.
Christuserloeser wrote:...how high would you rank the lack of hardware acceleration and the 320x240 limitation with your current engine within your list of reasons for this decision? Maybe you could give an estimated percentage ? 50% ? Higher ? Lower ?
It's pretty much impossible to give an exact value, but it was very small. If everything had happened as I predicted in the beginning, it wouldn't be a problem. Sure, the graphics would still be low-res and low-color, but it would have been a game with good gameplay, interesting original features and a good amount of content.
However, we had no experience, we were unprepared, and due to this we faced a regular flow of bad surprises going on top of the problems we already had. The framerate problem mentioned above is one of them.
We also found out that the visual quality of the 3D models are a lot more sensitive to lighting and to animation when they're cel-shaded. Slight deformities in models are unnoticeable under normal lighting, but in cel-shading they generate bizarre shadowing and messy outlines. So, while cel-shading makes it much simpler to draw textures, it requires a lot more accuracy and testing when modeling and animating.
Quake's vertex-based animation also became a problem. When vertex-based frames are interpolated, each vertex follows a straight path all the way from a frame to another. However, all animations in the character models are achieved through rotating parts of the model around their joints. Mathematically, this means that the interpolated model's shape will be wrong at all times. In practice, this may be unnoticeable if the angular differences between a frame and another are small enough. Because of this, there were several times when the number of frames in some animations had to be increased because the interpolation was making them ugly. Plus, we made the models in Milkshape 3D, and it's a pain to add/remove/switch frames and animations in it because it treats everything as a single cumulative animation. Reordering animations in qME also gives a lot of work because we would have to reorder everything every time we re-exported a new version of the model. If the engine and the model format supported joint-based (skeletal) animation, animating the models would have been much easier.
These are just some of the technical problems. There's many more, and there's also many non-technical problems. I could spend weeks explaining them.
We should have done a lot of research before starting to work on this project, discovered all downsides of the techniques, tools and technologies we were going to work with, searched for alternatives, devised a solid work plan, prepared a time schedule, assembled reference databases, etcetera etcetera etcetera. Instead, we just started working on it right away
.
Now, what we will do about this is to write a private postmortem of this project, and use it to learn with our mistakes and be better prepared for future opportunities.