Super Swordsman

Abstract
Game Title:Super Swordsman
Development Team Members:Luis Bermudez, Calvin Hsu
Game Genre:Fighting Side Scroller
Brief Description: Super Swordsman is a side scrolling platform game rendered in 3d. The player must kill simple patrolling A.I. by pushing them off the platform, or attacking with a sword. The player can also dodge attacks and recover from falling by performing a wall climb.
Overview
Game Story / Objective:A ninja is infiltrating a town and must kill all guards of the town walls
Game Mechanics + Controls:
  • A: Move left
  • D: Move right
  • S: Dodge/Duck
  • W: Jump
  • Space: Attack
  • Jumping preserves your current horizontal velocity.
  • Dodging makes you "invincible" to enemy attacks temporarily, but has a cooldown afterwards so it can't be reused repeatedly.
  • You can only attack while standing still, and attacking stuns an enemy so that you can attack again.
  • If you miss an attack, there is a cooldown penalty, but hitting allows for a combo bonus and there is no cooldown.
Technology:
  • Newton Dynamics: Used a wrapper to integrate with Ogre3D rendering system. Newton was used for collision detection, character physics, raycasting/hit detection.
  • Ogre3D Rendering: Used for rendering, allowed for easy implementation of shadows, and loading of meshes.
Aesthetics:
  • Game models: Foreground model plus background models came with Ogre3D engine as samples
  • Skins: Modified the orginal skin to make the player darker. The original ninja skin was a bright cartoony green. We made the enemy models purple, akin to the "foot soldiers" in Teenage Mutant Ninja Turtles :D.
  • Lighting: Chose a darklight with lighting from the front to cast nice shadows on the backwall. Choose an orangeish color for torch feel.
  • Textures: Choose town building textures in the back with a stonewall texture for the front platforms, to make it look like a city wall.
Media
Screenshots: Basic attack:

Jumping across:

Killing an enemy makes him fly off!:


Got killed:
Development Summary
CODE: outline of code structure, including a clear description of all original code written, as well as an indication of any external code or libraries used.

Original code:

Character Class:
Controls all logic for a character (whether be enemy or player). Includes state for what action is currently being done, timers, for each of those states.

Contains aerial vs. ground state. Character properties such as movement speed, attack damage, attack lengths, stun times, mass, hp, aerial control speed.

The physics controller is encapsulated in this class, which includes methods for calculating force to get an appropriate speed. Includes raycasting for determining hits. (Calvin)

Character View:
Determines what animation to play based on a character's current state. Contains properties about how an animation should be blended, how long it should blend for, whether an animation should repeat. (Calvin)

GUI:
Encapsulated in FrameListener, updates player HP display and enemy HP display. Reports HP and # of enemies remaining. (Luis)

Game Logic:
Encapsulated in FrameListener and BeginEnd singleton, checks to see if characters should be killed upon falling below a certain threshold. Respawns the player upon winning or death. Keeps track of live and dead characters. (Luis)

Input:
In FrameListener.h, determines which player commands to call based on the keyboard hits. (Calvin)

AI Controller:
Updated each frame, determine the AI action to patrol it's platform, attacking every fixed number of seconds. (Luis + Calvin)

External Libraries / Code

Ogre3D:
http://www.ogre3d.org/

Rendering engine. Allowed easy loading of models, and creation of shadows.

OgreNewt:
http://walaber.com/index.php?action=showitem&id=9

Wrapper for Newton Dynamics for Ogre3D. Allowed for easier integration of physics and rendering engines.

Newton Dynamics:
http://www.netwongamedynamics.com

Physics engine used for collision detection and character movement. Raycasting also used for hit detection.

Animation Blender:
http://www.ogre3d.org/wiki/index.php/AnimationBlender

Ogre3D already includes vertex interpolation, based on which animations are enabled, and what weight they have. AnimationBlender encapsulates this functionality, and allows a smooth blend from one animation to another over a given time.

CONTENT: All game models and textures came from Ogre3D SDK. Textures were modified in color for use of the project. Levels, which consisted of simple platforms, were original.
Reflections
Three Greatest Challenges: Character Physics:
Character physics proved to be much trickier than originally thought. Implementing a simple character motion of achieving constant velocity left or right, and being able to stop quickly turned out to be non-trivial in a physics engine.

Setting velocity destroyed the effects of constant gravity and made the player float. Instead everything needed to be done through forces. Some calculation needed to be done per step to apply the less/more force to achieve the desired velocity.

Jumping proved to be a challenge, and couldn't rely on the same system used for ground movement. I wanted the player to retain the same horizontal velocity prior to jumping, not move at a constant velocity like on the ground.

Furthermore there had to be a way to detect whether or not a character was in the air. This was solved by using a collision callback, so everytime a player contacts the ground, and if he had jumped before, then set his airstate back to the ground.

Animation Blending:
This was a software engineering challenge in how to separate the model and display. With animations, the display could possibly affect the model, the animation is done so the action is done.

I later decided to decouple this with a separate model and character view. The model would hold separate timings, which the view would try to animate.

The other issue was that with 3d rendering, animations needed to blend correctly in order for the game to feel right and not feel jerky. We did achieve this, but it still didn't feel fully responsive as actions felt delayed with animations needed to blend in.

There were problems with actions syncing with animations. Such as a melee attack animation. The method was to do hit detection as soon as the player hit the button, but really that was when the animation showed that the sword was starting to move. We ended up picking an animation that was faster, and speeding the animation time to compensate for this issue. I also thought about using a collision object attached to the skeleton's arm joint to do hit detection, but that would add a lot of complications.

3d Physics in a 2d World:
The physics engine was for a 3d world. But it turned out that some work was required to make it fit to 2d gameplay. We had issues with players sliding off the axis of play, because they didn't collide perfectly headon with AI characters. The solution was to turn AI geometry into very wide rectangular boxes, so that any offcenter force wouldn't cause the player to slide off.
Three things that went right:
  • Aethesetics: Though we didn't create the art or animations, it took work to get the animations playing right with the gameplay mechanics. We did select the lighting, and what animations to use, and I think the game ended up looking pretty good.
  • Character controller: After some work, this ended up being pretty good. It allowed for some aerial control and it allowed the player to move around easily. It didn't feel like it was accelerating out of control.
Three things that went wrong:
  • Using animations: Using animations forced us to develop the game very differently. I think we were too constrained by it and weren't able to develop interesting gameplay.
  • Gameplay: The gameplay isn't particularly interesting and we didn't have the time to implement rewards or powerups, which were central to making the gameplay interesting. We were left with a basic combat system as a skeleton, but no meat.
  • Sound: Another result of the game being too technically oriented was that we didn't have time to implement sound. As a result we lost a big dimension of immersion.
Other final thoughts:As the first game both of us have either developed, we clearly tried to bite off more than we could chew. While in our planning phase, we had actually thought we were toning down to make an achievable game, and we clearly under estimated the problems and workload to get basic mechanics running smoothly.

We tried to achieve an aethsetically pleasing game as our first game, which greatly hampered us and distracted us from focusing on core gameplay. In hindsight I think we should not have bothered with complicated models or animation, but rather should have worked with something simple, and develop an interesting game off simple visuals.

I learned a lot that it is more important to get some fun gameplay up then it is to focus on aethesetics. And even more importantly, that gameplay can be implemented on simple ideas rather than complicated structures.