jasontbradshaw / coconut-run Goto Github PK

The current Sprite hierarchy is:

- Sprite
  - Movable
    - Avatar
    - Block

When incorporating other items (bananas, power ups, etc), this hierarchy
might fail us. For example, we might allow a Coconut to collide with the
Avatar when the Coconut is falling, but disallow this with Bananas.

Thus, I propose a new hierarchy:

- Sprite
  - Movable
    - Avatar
    - Droppable
      - Coconut
      - Banana
      - Heart
      - etc

The interpolation between logic updates it not working. One problem is that 
each sprite does not have a current_velocity member that the renderer can 
use.

Putting a simple circular shadow under the sprites would make it look much
better. See the lol.jpg series on the group uploads for how it could
improve presentation.

What steps will reproduce the problem?
1. catch '1', '/'
2. catch '0'
3. division by 0 error

What is the expected output? What do you see instead?
Not sure what we should output. Maybe nothing, until the 0 is popped off?
I.e. catch python's eval() division by zero exception.

The player will be able to pimp out Coco with items. Items increase Coco's
abilities.

Item categories:
- head gear
- necklace

Chipmunk (http://code.google.com/p/chipmunk-physics/) is a physics engine
for 2d apps. There is a python wrapper for it, pymunk
(http://code.google.com/p/pymunk/).

Physics implementation is rather unnecessary, but still cool. Maybe
sometime in the future.

Special effects (visual and auditory) should occur after a
collision(coconut w/ avatar) to make that collision noticeable to the player.

Examples: avatar sprite reacts, sound, text displayed

An operand is any rational number. Thus, we should use a regex expression
to check if a string is a an operand.

Allow joystick support. Paul has a 360 controller. Get at it ;).

The number of lives should be represented not with a number, but with hearts.

What steps will reproduce the problem?
1. catch a number (e.g. 4)
2. catch another number (e.g. 3)
3. now we have a VALID number 43

What is the expected output? What do you see instead?
We should not see 43 and it should not be valid. We should see two seperate
numbers 4 3, and it is not valid.

Please use labels and text to provide additional information.

The coconuts don't disappear, despite having been asked nicely to do so.

You can only collect bananas if you are carrying a basket. A basket can
only hold a certain number of bananas. The more bananas in the basket, the
slower Coco moves.

New state machine allows coco to run off screen.

Possible solutions:
ugly hacks.. think harder, elben

In Animatable, each state should have its own mspf value. We should be able
to set this value when we set a state to an animation sequence.

Coconuts hitting the ground should be visually and auditory more pleasing.

Examples:
 * shadow that increases in size as coconut gets closer to ground
 * dirt rises from ground
 * coconuts bounce after hitting ground (and avatar)
 * coconuts roll

coconut_run.py currently has an avatar_vel variable that controls the speed 
of avatar movement. Different avatars, however, can have different 
velocities. In other words, Avatar should have a max_vel member.

Currently, we can have an infinite (until out of memory) number of operands
and operators. We need to design a limit on expression size, as part of the
game play.

Example:
- start with a low number of oprnds and optrs (e.g. 3). Increase this as
level increases or as you "buy" more room.

The backdrop (background landscape) should be more than an image. We will 
eventually have animated backdrops with multiple levels.

To do this, we need a Backdrop class that can handle multiple surface layers 
and animated surfaces.

We should be logging stuff for our own future benefit. Check out Python's 
Logging library.

Player should be able to save current state of game and load it at a later
time.

Some of the things Game should hold:
- player's name
- # of bananas
- # of lives
- items bought
- avatar stats
- etc

Implement (realistic) acceleration for falling coconuts.

Instead of locking the frame-rate down to some arbitrary constant
(currently 60 FPS), we should have it dynamically adapt based on how fast
the machine is currently rendering it.

A sprite's movement speed should adapt based on the current frame-rate, and
should appear to move at the same real-world speed regardless of whether
the machine is rendering the level at 6 or 600 FPS.

How to: http://www.gamedev.net/reference/articles/article1382.asp 

We are manually compute paths to files: folder+'/'+file

We should be using os.path.join(folder, file), which figures out the path 
arithmetic for your OS.

We need some way to have different "areas" of the game where things take
place.  Game play is one are, different menus are others.

Abstract input handling from the main loop into its own function.

Right now, the player gains one point per logical frame. This should be one 
point per second, with extra points for picking up special items and such.

Resolution is currently 640*480. We find that 800*600 gives us more much
needed room.

The only work left is to resize all backdrop surfaces to the right
resolution. This should be an automated process so that we can switch
between any resolution with easy.

A flexible expression engine is needed for the educational math portion of
cocorun. The expression engine should be able to handle complex math
expressions such as "sin(4 * (4 + 3))".

Ideas:

- Primitive
 - Operand
 - Operator
- Expression

We should abstract these two blocks of code into different functions for
easier readability.

Write a Sound and Music class.

Right now, the rect of a sprite obj is tied to the sprite's image. We
should be able to manually specify the dimensions of the rect. This way, we
can crop out the sprite into what is actually part of the sprite and what
is not.

An example of where this is needed is the avatar sprites, which is 96x64px.
But we do not want all 96x64 to count as the sprite.

Make a way to save and load game configurations. Allow everything to be
configurable through this system.

Most of the settings will be hidden from the regular user.

The ground level is currently the bottom edge of the screen. We should
provide a padding between what is "ground" and the screen edge.

A member ground_lvl should be part of the Level class.

Unary operators are currently limited to the following formats:
[sin, 3, ...]
[..., +, sin, 3, ...]

Unary works by operating on the next element. It cannot be sequences as such:
[exp, log, 3]

This is due to limitations in Expr.__str__(). It can only place a
parenthesis after the first right, and cannot tell if right is a unary.

Solution:

Implement a stack for keeping track of when to put parenthesis.

We should be able to save a game settings into a file and load it.

Settings:
- drop frequency
- drop velocity
- etc

Currently, our GameManual (see wiki) consists of little useful information. 
This should eventually be the one-stop place for a player to learn about 
Coco's Fun Coconut Run.

The Quick Guide section should get a player up and running as fast as 
possible. Other sections should go into detail about each feature.

Currently, collision detection does not feel real. The Rect that Avatar
uses is just the image size of the avatar (32*64 px). This can be improved
by making avatar.rect the collision rect and some other image_rect the size
of the image.

Create a cocolib.py that stores all the classes used in coconut_run.py.

What steps will reproduce the problem?
1. start game
2. collect coconuts
3. hit "d" to remove the last coconut caught
4. more than one coconut (expression) is removed due to very low repeat key
delay

What is the expected output? What do you see instead?

We should only see one expression be removed. Instead, we see a lot of
expression being removed, even if we try to hit and release the "d" key as
fast as possible.

Possible solution:

Only remove once per "d" key press down.

1. We catch, in order, "3", "+", "-", "3"
2. This expression is: "3+-3"
3. Python evaluates this as: 3 + (-3) = 0

We, however, would not want this. "3+-3" is an invalid expression because
we consider "+-" as two operators next to each other.

Thus, we must write our own parser that distinguishes operators versus
operands. The rules may be:

Let U = unary operator,
    B = binary operator, and
    E = valid expression.

E is valid iff at least one of the following holds:
 1) E = a number
 2) E = E B E
 3) E = U E

Rapidly pressing the left or right arrow keys causes the avatar to jump in
that direction.

If lives > 14, hearts go off screen.

Find better way of display lives (maybe HEART X a, where a = num of lives).

Any sprite should be able to animate. From outside the sprite, animation
should be automatic. The user should not have to (and perhaps should not be
able to) animate the sprite manually.

Animation code may be complex, and does interplay with both logical and
graphical aspects of a sprite. Hence, we should strive to hide its
rendering complexity when working in the logical.

Visualize rects so we can see where the collisions are happening. This will
make refining collision rects easier.

Even though there is built in acknowledgement of unary operators (e.g.
sin(), exp()) in the expression engine, there isn't full implementation
support. 

The biggest reason is that currently, if our Expr looks like: e = ["sin",
"3"], then str(e) ==> "sin3" instead of "sin(3)".

What steps will reproduce the problem?
1. hold left arrow
2. press "d"
3. Coco stops moving left

What is the expected output? What do you see instead?
Coco should continue moving left and whatever "d" does should happen.

Possible Solution(s):
Instead of moving Coco after we detect a left arrow key down, we set some
flag that will move Coco left forever until we see a left arrow key up.

When you gain or lose health, the health indicator (hearts) should not
appear/disappear abruptly.

Some ideas:
- fade in/out
- scale in/out
- scale in, "pop" out (need new sprite)

We need installing and starting up instructions for Windows, Linux, and Mac
OS X.

We might want to check out http://www.pyinstaller.org/.

Questions:
- if we don't use pyinstaller and do it manually, do we need to include
python and pygame or show user where to get it?

The basket should follow Coco's head up/down movement. Easiest solution is
to make the basket part of the Coco sprite.