ogrady / mw3 Goto Github PK

Currently, the config is mapped as on the original SNES-controller for the game. We might want this to be reconfigurable in the future.

As Nitros weapon is not part of the hitbox (and therefore the exitpoint for bullets is not in the box, too) Nitro can shoot bullets behind blocks.

• work out a simple protocol to communicate actions over a TCP-connection
• create a runnable server to broadcast incoming message to connected clients

Triggering a collision on a corner (as following the blue arrow would cause) causes the Mech to jump into the opposite direction (red arrow).

first level to test out basic functionalities like

• falling and colliding
• destructing parts of the map
• maybe interacting with parts of the map as pilot (levers and buttons)
• maybe active parts of the map (lifts)

Replace all existing sprites of the first mech with new ones. This includes:

• body
• arm rotation
• shielding
• sword
• bullet
• stationary shield
• jumping
• flying

several issues with the style in NitroRenderer:

• missing modifiers for variables / methods
• variable-declaration at arbitary position in code
• class-variables don't start with a underscore

sword moves farther than the bottom-line of Nitro

Currently, sounds are played regardless of where their source is. This should be changed so that the distance of the source to the viewport influences the volume of the played sound.

We currently only support rectangular hitboxes for blocks on the map. But even the original game features triangular hitboxes, allowing for ramps on the map. I'd like to achieve this by running some sort of magic wand over the tileset when loading the map. This could be done once and be stored in a separate file for future use, if this would take up too much time when starting the game.
This would be a good starting point: http://losingfight.com/blog/2007/08/28/how-to-implement-a-magic-wand-tool/

The current custom algorithm works fine for our currently used tiles, though it is rather slow. But some shapes might break it (like certain spike-shapes ///\ if we ever want to use them). So it would be nice to improve it to work for general shapes and maybe improve in performance.
Well known algorithms for convex hulls might be a good starting point.

• assert proper shape-finding for arbitrary shapes
• improve performance (currently about O(n^2)!)
• implement some simple-shape-detection. Rectangles might be represented by an instance of Rectangle, instead of shape (optional)

In some cases, bullets fly right through solid, destructable blocks (not yet tested for solid, indestructable blocks). As can be seen in the attached screenshot, the blocks behind the encircled block are already destroyed.

Slightly changing the position of the mech solves this issue. So it probably has something to do with the speed the bullets fly with (enough to entirely pass through one block before checking for collisions again?) or the contains-method of the hitboxes (they are now instances of Path, instead of Rectangle).

Add missing documentation to all classes

When solving #28, the Loading of the Map will be far more time consuming, as we will be doing some magic-wand-action on the tilesets to determine the arbitrary hitboxes. It will probably be faster to do that once and then store and load the maps in serialised form apart from the tmx-file.

Apparently the background-layer is rendered on top of the destructable-layer, allthough it is displayed correctly within the Tile-editor.

It should be possible to receive key-up as well as key-down events. This may be interesting for switching various states as well as animations.

The input class could contain a list saving all keys pressed during the previous key-capture call and iterate the list to see if the key is still pressed. If the key is no longer pressed, an event can be thrown.

Currently, only Nitros primary attack has a sound. We need sounds for all actions and they have to be reigstered via the corresponding NitroSoundManager.

This issue has to be split into several smaller tasks and will probably not be fully included in the second milestone.

It is currently pretty unclear what the colliders are for and which collider is reponsible for what. E.g. when a projectile moves it also handles its own collisions, which is not as intended.... therefore. This needs some work.

first Mech will be the Nitro from the original game with all of its functionality:

• moving (done)
• rotating its arm (done)
• hitting with a particle sword (done)
• jumping (done)
• hovering (done)
• shooting bullets (done)
• blocking (done)
• creating hovering shields (done)
• receiving damage (done)
• modify received damage when in shielded-mode (done)

Hitting an object with the particlesword currently deals damage to it in every tick as long as it still intersects with it. This leads to massive damage and should be avoided. Probably by remembering objects that were hit by this particular particlesword.

KeyboardController and NitroKeyboardController both notify the renderer of key events so that those are events are sent twice each.

regarding the first working Mech
(movements and other actions like attacking and maybe ejecting the pilot)

Was temporarily removed in revision 664aa4c due to having more important stuff to work on. Can now be re-employed.

As for now, the game consists of one large state, which is useful for testing without having to navigate through the start-screen etc.
But sooner or later, we have to include additional states for level-selection, credits and so on.
Slick2D offers this functionality via the StateBasedGame and the GameState classes - so we should swap out our current functionality in one state and then gradually add all other states.

When facing left and tilting the arm while using Nitro, the right edge of the sprite re-appears on the left side of the image.

Currently, health is shown as a number over the head of each entity. In the original game, it is implied via the sprite of the mech (in good state, damaged, almost destroyed). We could adopt this or use healthbars or anything similar.

gravity
collisiondetection and -handling
probably deflection

promising tutorial:
http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/

reacting to input by displaying the proper animation and taking care of peripheral issues like handling the exit-point for bullets, overlaying multiple animations when putting complex animations together from simple animations (a Mech may consist of an animation for the body and one for the rotating arm where the bullets are being created)

Currently Nitro can move his arms, shoot and use his sword (but can not move) while in blocking state, which is actually an interesting state. But it doesn't reflect the original game, in which blocking stops all other actions. Evaluate, whether we want this or not and then fix accordingly.

We are professionals and you are practised in writing them! :3

We need a file, storing the settings a user chose. Such as:

• which input-device he wants to use
• key-binding (this is already done)
• screen-resolution
• other visual settings (gamma, brightness, ...)
• window-mode on / off
• music- and sfx-volume

We furthermore need a GameState, where the user can alter this file from.

As for now, collision-detection puts some heavy load on the game, as whenever an entity moves, it will check for collisions with all other entities. Even if they are not near themselves. This slows the game down considerably, even in a 50x50 map (=2500 tiles to check) with some flying bullets and just one Mech. As we are planning on larger maps and multiplayer-support (= a multitude of bullets and mechs at a time), do you think it would be feasible to maintain a (B+-)Tree over the coordinates of entities in addition to the current list? Especially in regards to having to update the tree whenever an entity moves.

renderers should obtain the information about their state from the logic-object (_renderable.getState()) instead of maintaining them themselves (boolean flying)

As renderers are now dependent on retrieving state-information from the state-bitmask of the mech, it is important to maintain all states correctly. That means: adding and removing states inside the Mech/Actor/Movable when due. E.g. removing the JUMPING state, when the mech collides with a block underneath it.

When dying, Nitro displays a broken-animation. As the cannon is not part of the main-sprite, it is still being displayed and looks oddly out of place (though not being able to move, so this is more of a cosmetic bug). Same applies later on for when Nitro is standing around without a pilot, so we need to get rid of the cannon in specific states.

Bonus points for not doing it in the NitroRenderer like:
IF !disabled THEN render(cannon)

Apparently, the angle is not 100% correct, as we can't produce horizontal-flying bullets but only slightly off lines of bullets (see screen). Vertical (up and down) works fine.
Probably some rounding-errors, we can tinker with.

As is, upon a collision the position of Positionables p towards Blocks b will be adjusted in a rectangular way:
if(p ran in b from left) place p left of minX of b
if(p ran in b from right) place p right of maxX of b
and so on. This behaviour is unwanted with non-rectangular hitboxes. E.g. when colliding with a triangle-shaped block, we want to place p pixel-exact next to b to have slopes.
This might be automatically resolved, once fixing #17 .

Each CharacterAction should have a customizable Map of forbidden states to check for, which is currently just BLOCKING and DEAD.

As Chris rightfully noted, "MW" is already established as an abbreviation for a certain well-known game. Plus we should dissacociate ourselves from the original game anyway. Obviously, this issue can be addressed later on and is therefore not critical.

Whenever the game loads a ressource (map, images and later on sounds) it does that in our main-thread. It would be nice to do that in a threaded manner. Especially when loading the game and having the progress displayed.

Player should be able to leave the current Mech and enter another.

TiledMaps can't have their cells manipulated once they are loaded into the game. So we can't remove destroyed blocks from the map. They can be made un-blocked, of course, via the Block-Class, but the Image remains the same.

Currently, the only solution seems to be to introduce a new layer where all cells are interpreted as objects, rather than tiles of an image. Whether this has a grave impact on the rendering-performance, as we can't benefit from the opengl-pipeline as before, has yet to be investigated.

Currently, controllers tell the Mechs to move, which will cause the mech to go into MOVING state. When the controller doesn't call the Mech to stop in any way, it will think that it is still in MOVING state, unless the controller tells it otherwise (via move(0,0)).
We should change this to momentum, the mech maintains and decreases upon receiving ticks from the game so that it will come to rest over time.
(Due for next milestone).

When we start implementing NPCs, one obstacle will be that our NPCs are not the same size as one tile of the map. In fact, probably every mech will have his very own size.
This might make the use of classic pathfinding dire.
Slick2D provides us with pathfinding, to which we maybe can pass those sorts of context-information.
http://slick.ninjacave.com/javadoc/org/newdawn/slick/util/pathfinding/package-summary.html
If this doesn't work, we might have to span artificial grids for each sort of mech and maintain them whenever the map is manipulated.