codemouse92 / diamondquest Goto Github PK

This is along the lines as #7 or #8, but is the most complicated of the three tools.

Power level corresponds to blast radius. (The actual in-code rules for blast radius should be coded in a maintainable way, not hard-coded.)

The proposed corresponding blast radius and power level is as follows:

7655567
6543456
5421245
5310135
5421245
6543456
7655567

(You're welcome to suggest changes to the above.)

The hardest part is, once the player sets down the TNT, the character must automatically pathfind to the nearest safe space outside the blast area, and then move there at double or triple normal walking speed. After the explosion, the character must automatically move back to the spot where they had originally been when the player placed the TNT.

The player character's sprite is offset incorrectly. Fix so it loads from spritesheet.

While walking (or performing most other actions), there are two-step animations. Show these during that action. (Start w/ walking animation.)

The main menu needs to be made functional, such that you can create a new game with a name, or load from an existing profile. We have not yet determined the game file format; bonus points for doing so. Otherwise, just creating the skeleton framework for the functionality is enough.

When the player switches from walking to free-climbing, the avatar sprite needs to change accordingly.

Related to #2 and #3.

Allow digging with pickaxe. This will require implementing a power level indicator.

For purposes of implementation, you can give the player free power levels on request. (Eventually will be provided by solving math problems.)

Gameplay:

1. Player selects power level 1-7 (use constants to define bounds; we may change them later). Selected power level persists after selection. Eventually, player will have to solve math problems to recharge to the selected level; they should not have to select the same level multiple consecutive times.

2. Each STONE or TREASURE block broken with pickaxe consumes one power level. DIRT is free to mine.

#6 will need to be figured out first.

This task is reasonably simple: building a basic navigable grid that can hold text. However, there are some important factors, so please read through the below notes.

We need a screen that appears over the gameplay map, much like the menu does, but which will show the math problem to be solved. In game, it will be automatically triggered when a math problem must be solved. For debug purposes, you can set it to toggle with the = key.

This screen must be set up in a sort of grid configuration:

• Each cell in the grid must be able to contain either a character — usually a digit or an operator — or a blank.
• Some cells must accept input from the user: these should be marked out in a different color.
• Display text as large as is possible! We want this to be playable (in full screen) by players who may have low vision.
• Arrow keys must be able to navigate through the cells, highlighting each. Skip moving into blank, non-input cells. Highlight the cell currently visible in a different color; use a different color still for selected input.

We'll handle automatic carry-over in a separate task.

On the note of colors, I propose a yellow background for highlight, cyan for input, and green for highlighted input. Be mindful of good contrast, but avoid white-on-black or black-on-white. (Make sure the color choices are RGB constants, so we can change them later if needed.)

Here's a good example math problem (particularly hard, yes) that you need to be able to display. ? represents input field. and # represents a place where you might have a carryover.

123+45.6-788+900-876+53.4+210=????

  #####
 123.0
+ 45.6
_____
 ????

P.S. The answer is -332

In this example, the user would be walked through the PEMDAS by the game.

The exact nature of the math content and problem generation might change later, but the above at least shows how much room we'd need. If we can accommodate the above or more, then the rest will be easy.

IMPORTANT: Make sure you define the number of cells that you're fitting on the screen horizontally and vertically with constants, and determine the width and height of each cell from those constants and the screen resolution. We may need to change the values later.

Allow the player to select a tool:

• P or A = Pickaxe
• D = Drill
• T = TNT
• Space = No Tool

The sprite and the player state need to update accordingly.

Precedes #7, #8, and #9.

Walking and climbing should gradually move the character between the two points, rather than jerkily moving them forward an entire block at once.

The trick to this will be syncing the gradual motion to the speed of the walking/climbing animation for #2. It may be best to move forward in 25% block increments, rather than smoothly.

Additionally, the speed should such that it still feels responsive to a player tap-tap-tapping the arrow keys.

This works along the same lines as #7. The only difference is that the drill mines multiple blocks in a straight line (horizontal or vertical).

The drilling distance depends on the power level - one power level is consumed per STONE or TREASURE block mined (DIRT is free to mine).

There is a special set of sprites for using the tool, versus just holding it, such that it appears the character is being pulled along.

When the player reaches the end of the drilling distance, they should go back to holding the drill, unless the player is not standing on a solid block at that point. In that case, put the drill away and go to the climbing position.