brycemehring / hexel Goto Github PK

The user should be able to:

• Build towers on hex tiles on the map
  • Towers may take up more than one hex tile.
• Select and view a tower’s details in the sidebar
  • Upgrade or sell towers

Currently we are drawing a single circle to display the radius while placing and selecting towers. The issue comes into play when the user places a tower down, the circle stops following the mouse and just shows the attack range of the placed tower.

The enemies need to have health bars so that we know their remaining health.

While in co-op mode, there needs to be a method of finding players to play with. For this to work as expected, there needs to be a centralized server to manage the matchmaking.

Occasionally when the the the user clicks when the wave message box is is up, it does not fade away completely. As of right now I'm sure on the cause of this issue.

The towers need to have more stats:

• Kill count
• Attack rate

Sound resources:

• http://www.bfxr.net/
• http://freemusicarchive.org

This possibly could be implemented in the SDL host. This would only work on the desktop platforms though.

Currently if the text box is filled up with too much text, it will be clipped. Either the text box will have to become scrollable or previous messages could be removed(like a queue).

There should only be a single game class for both multiplayer and singleplayer game modes.

Create a sidebar menu where the player can view their score, buy, upgrade or sell towers, pause the game etc.

Some towers are quite overpowered. Their stats need to be modified to make the game more difficult and enjoyable to play.

When a tower has a longer recharge time between firing, it would be nice to see the remaining time until the tower fires again.

Enemies will move along a predetermined path specified by the map.

Breadth-first search can be ran once per map to find the shortest path from each tile to the goal. Using this algorithm over A* has the benefit that the pathfinder only has to be ran once instead of for each enemy unit.

Source: http://www.redblobgames.com/pathfinding/tower-defense/

As we are now using the logo in game as a part of the splash screen, it would be nice if the logo was of higher quality. The comet is quite rough around the edges.

If the shift key is pressed in the text box, the characters are not inserted as upper case.

Different levels should be stored via some file system.

JSON or Lua files could be used to store the level data.

A set of maps needs to be generated for the user to play. This could be a manual process in which we manually place the hex tiles and then save the map, or the maps could be automatically generated upon request.

This is related to #13.

This is is related to issue #19.

This class should manage the rendering of the weapon and doing damage to the target.

Each enemy should have death animation. It could either be a sprite animation or we could have the sprite fade out.

This message box should be removed.

If the user clicks the save state button within the map editor, an error is generated because MapEditor.serializeGrid(...) is being called as a static function and as a method in different locations.

Transforming the map editor into a regular class instead of a singleton would solve this issue. This issue is mainly derived from the behavior of buildUI(...) because it must know of its parent.

The first step is to build MOAI for android. The steps are laid out in the MOAI readme. The Android NDK is also needed to be installed, with links being provided in the readme.

There might be some changes required to our code base to get the android build working, but I'm unsure as of right now.

We are going to need at least some basic sprites for towers, units, and more. They do not have to look nice initially, just we should be able to tell the difference between two different units/towers.

The function createChildView() should only be defined once.

Currently in single player, if enemies keep on spawning and being destroyed, the game does not seem to be freeing much memory. I've seen the game use more than 1 GB of memory at times.

The main menu should have a button to quit. One way to end the game is to call os.exit().

This could be used for dynamic enemy generation and what goes in each wave so that we don't have to hard code what goes in each wave.

This should gracefully close the Hexel game application.

If the window is resized, all of the GUI widgets will need to be repositioned. This could be done via a callback mechanism on the resize event.

Also the game should be using world space instead of screen space in order to better support different resolutions.

In this mode, the player is tasked with defending key points from waves of AI enemies by placing various types of stationary towers on the field. After each wave is completed, future waves will progressively become harder. Money is earned by defeating enemies and at the end of each wave depending on how much money the player has on hand, which can be spent on upgrades for the player's buildings. The game is over when the player is reduced to 0 lives, and the player loses a life whenever an enemy reaches the key point.

This could be implemented as part of the build with Jenkins.

We could use https://github.com/Olivine-Labs/busted

This will show off a very minimal concept of the game to help other developers get started.

We could have a CI system set up with Jenkins or even Travis-CI so that the source is built after each commit. This is related to issue #6.

A couple of issues that need to be taken care of in relation to hex grids:

1. How are we going to store the hex grid?
2. Point to hexagonal collision detection needs to be implemented.

This seems to be a good resource to start with: http://www.redblobgames.com/grids/hexagons/

Sometimes the health bars for enemies can become negative which is not supposed to happen. This occurred after this commit, 7f7e389.

Explore the basics of network communication with MOAI. Get two Hexel instances to communicate with each other as a precursor for coop and versus gameplay.

On Windows there is a slight delay when sounds are played.

In this mode, you will be teaming up with a variable number of friendly players to help with dealing with endless waves from the enemy. Teamwork will be encouraged by having split resource pools for each player, restricting particular player’s towers to different sections of the map, or by restricting the types of towers available to each player. Waves will not start until all players have selected “ready” during the build phase.

Should we allow for towers to be placed in the middle of a wave?

Currently towers will fire upon dying enemies, and if they are dead, the attack is ignored. The towers should avoid firing upon dying units.

Each enemy type in the wave can have a weight which corresponds with how many of this type of enemy will spawn in the wave.

Players will be in charge of sending enemies to attack other players in addition to protecting their base by constructing towers of their own. Players will receive resources based on the number of enemies that their tower destroys. This continues until one of the players quit or runs out of health.