bbergen / sdl_graphics Goto Github PK

When shot, large asteroids need to spawn two or three smaller asteroids in their place.

Occasionally the game will exit out after selecting the Continue option in the game menu while the game is paused.

To duplicate, repeatedly pause the game and select continue. After a couple or repeats the game will exit.

Breaking a brick should have a random chance of releasing a power up, which will float down towards the bottom of the screen. If the player 'catches' it with the paddle, it should provide a random effect on the player for a short time.

This will just be a stub for now.

Some Ideas for Power Ups:

• Wider Paddle
• Multi-Ball!
• Slower Ball
• Extra Life

Some Ideas for Power Downs:

• Faster Ball
• Narrower Paddle
• Controls Reversed

There are some utility functions that are duplicated across the breaker and pong sub projects. They should be refactored into a separate unit that can be used by future projects.

Candidates for refactoring into common utilities include:

• error()
• render_circle()
• contains_point()
• find_mid_point()
• circle_intersect() (maybe a better name that describes finding a point on the circumference of circle given an angle.
• various random functions such as rand_boolean(), rand_color() etc.
• Potentially common geometric structs, such as point, circle
• Potentially common gui component structs such as label's and buttons.
  • If added, these should have corresponding render functions

We need some asteroids that slowly rotate around the screen.

Stick with simply large asteroids for now.
Collision, small asteroids, and explosions will be handled in a separate issue, but should be kept in mind during the design and implementation of this issue.

Ensure there is a function for generating random asteroids.

Random asteroids should:

• Have a manageable range of vertices.
• Random speed/direction of rotation
• Always be a complete polygon (bound finite chain of points)
• Be closed polygons
• Fit roughly in the same bounds regardless of number of vertices
• Should never be self-intersecting
• Wrap the screen
• Have all functionality encapsulated in asteroid.c, with only its API exposed in asteroid.h

When the space bar is pressed down, the ship should emit a burst of bullets from its nose, along the vector that it is pointing.

A cool sci-fi shooting sound should accompany the action.

Collisions with the bullets will be handled in a separate issue, but should be kept in mind during the design.

When asteroids are shot, currently they just disappear.

An explosion needs to be displayed. What I'm envisioning is something like a random range of pixels shooting out at random vectors for a random range of distance.

Asteroids now has most of the main mechanics functional and now it needs to be turned into an actual game.

Implement a lives and score system.

This is just a stub for now. I'll edit it later to include a mock up of how I'd like the score/lives overlay to look.

When the time comes to write the render engine for Asteroids, let's try to make it as a separate and discreet module that can be reused among multiple future projects.

The initial API can be small and simple, but ensure that it is robust and well encapsulated so that future tweaks will leave existing projects that use the engine unaffected.

Core Features:

• This is just a stub for now...

Adding unbreakable bricks in #6 has revealed some bugs with the collision detection on bricks.

Occasionally the ball will get caught inside a brick for a second or two.

This may also be related to the update frequency normalization that was done earlier.

The Brick collision boxes likely just need to be expanded by a small amount to account for the less frequent collision checks.

Currently the bullet TTL is a hard coded value. This means that on smaller resolutions, bullets can travel further making the game easier.

Similar to how the asteroid radius was converted to a coefficient for the resolution, convert the bullet ttl to a coefficient so that bullets will travel an equal distance, regardless of the screen resolution.

The project overall could benefit from a custom made unit test frame work.

Revise project_test.c such that it can do the following:

• Contain a series of useful assert macros for supporting tests
• Contain a system of dynamically running a list of test cases
• Continue running gracefully if a test fails
• Provide a report on number of tests passed/failed and which passed/failed
  • It would be nice to generate this report in simple html
  • Maybe even open the report in a browser once the tests run!

Currently, when a new game begins, or a life is lost, the paddle and ball are re centered and the game continues instantaneously.

Change this system to start the game (and continue after a life lost) with the ball touching the center of the paddle and motionless.

In this quasi-paused state allow the player to 'aim' the ball in a 180 degree arc above the paddle (perhaps not letting the ball go exactly horizontal, there should be at least some y axis motion).

Display the aim vector with a short line coming out of the ball in the current aiming direction.

In this state, instead of moving the paddle when left and right are pressed, move the aiming vector and visual display of it.

When the space button is pressed, the ball begins to move along the chosen vector, and right/left buttons revert to moving the paddle.

What use is a scoreboard if there is no score to keep track of.

Implement a system of scoring when breaking bricks.

• Point values should be in tiers.
• Later, when difference brick types are added, they can have difference values.

Also, when all bricks are cleared off the screen, the player needs to advance to another level.

Implement a level system with the following requirements:

• 4 different brick layout patters (colors can differ, but layout should be the same).
• Wrapping after level 4. When level 4 is cleared, the pattern cycles back to the 1st.
• Use the already added music files, which will switch on each level. Ensure the transition is pleasant.
• There should be a speed modifier that slowly increases. This when when the level's wrap the difficultly continues to ramp up.
• Speed modifier should be tied to a score modifier, so that as the game progresses, the value of the bricks continues to increase.
• Background color. Each of the 4 level layouts should have a soft, pleasant background color (likely a pastel tone, that is consistent. This way a light theme (music + background) is maintained.

Builds are generating a good number of compiler warnings. Most of these are from discarding const qualifiers, primarily in the Menu subsystem.

Refactor functions where parameters are being implicitly cast to either take a more appropriate data type (const SDL_Color for example) or explicitly cast the parameter.

From here on most of these SDL projects will likely have some sort of persistent preferences, for example sound settings, high scores, or preferred resolutions.

It doesn't make sense to have to write a system to read and write these preferences to the file system for each individual project.

Add a new tool to the common directory with a header and implementation that manages reading and writing of persistent preferences to the file system.

The system should:

• Be encapsulated and hide its implementation
• Be ignorant of the exact nature of the preferences
• Be passed the location to read/write the preferences
• Provide a simple api that provides the following functions:
  • write(prefs)
  • read(prefs)
  • get(prefs, key)
  • put(prefs, key, value)
• As hinted at above, the preferences system should either function similarly to, or delegate to a hashmap behind the scenes.

When the pause or esc key is pressed while playing Asteroids, a pause menu should be brought up that is similar to the new game menu.

The player should have the option to continue their game, start a new game, access the options menu, or quit the game.

The Classic Asteroids game had an alien ship that would randomly spawn and try to shoot the player.

Let's add one as well.

It should spawn and move about somewhat randomly, shooting at the player with a different color bullet. It should suffer collisions from asteroids similar to the player's ship

It should play a sci-fi sound when it spawns.

The list implementation created earlier uses a linked list implementation, which is great for situations where there are lots of insertions, removals.

It would be nice to have an alternate implementation using dynamically sizing arrays for constant time retrieval though.

Implement a vector backed with a dynamically sized array. Provide an api similar to the linked list implementation but with the added ability to specify a default allocation size, and maybe a load factor (defaulting to powers of 2).

Be sure to include unit tests for the new data structure.

Add the ability to disable/enable sound and music from the Breaker pause and new game menus.

Breaker needs a score board.

Here is a quick crude mock up of how it should look:

• Music icon must toggle music playing with mouse press. Done
• Sound icon must toggle sound effects with mouse press. Done
• High score will just be stubbed in for now, persistent preferences/high scores will come later Done
• Current score will be stubbed in for now, or can simply increment on brick break.
• Lives can be simply stubbed in for now. Done

Edit 2015/08/10 17:51:17 - Still Left To Do:

• Clean up the high/current score and lives rendering Done
  • A small margin of padding needs to surround the text Done
  • The fonts need to render smoothly and not be stretched. Done
• Add a simple framework for rebuilding the score/lives textures when required

Currently bricks just disappear when they are 'broken'.

A little flash could be added with a simple animation.

Perhaps some pixels exploding out, and the brick 'chunking up' for a second.

The current implementation of the asteroid object container holds both large and small asteroids in the same vector.

As asteroids are destroyed, new small asteroids are added, and the size of the vector is continually monitored and compared against a threshold. When the vector size dips below the threshold the vector is topped up with large asteroids to keep the game going.

This very quickly causes the vector to be saturated with small asteroids.

Large and Small Asteroids need to be manages separately

Add a new linked list to the game struct to store small asteroids.

When a large asteroid is destroyed, randomly add 2-3 small asteroids at the destruction site to the new list. Allow this list to grow infinity (as a game balancing feature). Prune this list similar to how bullets and explosions are pruned (although it will be a bit different as asteroids don't follow a FIFO policy).

Only check the Large asteroid vector against the threshold (which should then be lowered to maybe 60-80%) for top ups. Use the existing check and copy logic in place for asteroid respawning.

Breaker and later projects could probably benefit from a generic HashMap implementation.

• Add a HashMap implementation that can take a void* Key and void* Value to the common directory.
• Include a well documented header file
• Implementation should support the following standard Map functions:
  • put(void*, void*)
  • get(void*)
• The following would be nice to have as well:
  • key_set()
  • entry_set()
  • values()
  • contains(void*)

Currently the background of the playing field is just solid black.

It would look slick if it was a randomly generated star map!

Currently the asteroid size is based on a fixed range and when the asteroid is of type 'large' or 'small'.

Due to this fixed range, the game area is more crowded, and thus would be more difficult, on smaller resolutions.

Change the fixed ranges of asteroid sizes to be based on the screen irresolution. Similar to how the ship's size is.

Just a stub for now, but asteroid-ship collisions need to be implemented.

This should probably come after implementing the lives/score system

When the ship is accelerating, a small triangle should flicker behind the ship.

A thrusting sound should also play while the ship accelerates.

Breaker Needs a Pause/New Game Screen

Here is a mock up of how it should look:

Simple eh?

Implement the following features:

• Pressing Escape, or Pause, or Space during a game will pause the game and display this screen.
• When the game starts, or after a game has ended, a variation of this screen should show that does not contain the continue option.
• The selected menu item will display in a different color, red maybe.
• Default selection will be the top item.
• Pressing up or down will cycle through the options, ensure you can cycle from bottom to top with one press
• Space or Enter will fire the selected option
• Pause the music will the game is paused
• Include a pleasant sound when cycling between menu items.

Menu items will have the following effect:

• Continue... - Un pause the game (only available if game is in progress)
• New Game - Starts a new game from level 1 with starting lives/score. Be sure high score is set if implemented
• Quit - terminates the program gracefully

Currently the paddle only has crude collision detection.

Occasionally the ball will get stuck inside the paddle for a few seconds.

• Implement a more robust collision using separate axis test similar to brick collision.

Currently the scoreboard implemented in this issue only has a placeholder value.

• Add a system that will store the users highest score, as well as the state of music and sound effects options (on or off) in a file.
• Store the persistent data in a flat text file located at ~.breaker/breaker.conf

Once Issue #21 is completed, random asteroid generation will be in the game.

The next step is to start colliding our objects.

Implement checks to determine if bullets collide with asteroids on screen.

When a collision occurs, remove the asteroid from the screen, and free its resources. An algorithm similar to bullet pruning might be effective, although with bullets pruning is always done at the head of the list (basically a queue) asteroids may need pruning through out the list.

Also add a new sound resource for the collision and play it when one occurs.

Do not worry about explosion animations in this issue, that will be handled later.

The map API is using non-unique function names such as put() and get(). This is probably a bad idea and cause name clashes in the future.

Refactor the map API to have map_ pre-fixed on all function calls to prevent any issues moving forward.

Just an Issue for Hosting Screenshots that will be linked in the readme

Currently bullets come out at a consistent 4 bullets/s.

Change the implementation to be bursts of 4-5 bullets at a more rapid frequency, with a longer pause between bursts.

This should make it a bit easier to destroy smaller asteroids, and also had some challenge to the game instead of simply spamming the shoot button.

Currently destroying asteroids doesn't quit free up the resources associated with them. It just sets them invisible.

Also, there is no re-generation of asteroids. The idea of the game is that it sort of continues infinitely.

Implement a system that checks to see if the number of visible asteroids in the asteroid vector is below a certain threshold.

If it is, generate a new vector of asteroids to replace it, copying the remaining visible asteroids to it to avoid losing them.

Ensure that the threshold is an easy to adjust threshold for gameplay tweaking purposes.

Currently the ball just bounces off the bottom of the screen.

This is certainly not good! We need to start turning this into an actual game.

Implement the following:

• A system for tracking 'lives', which are lost when the ball touches the bottom of the screen.
  • Current lives are tracked on the scoreboard, which will be done in another issue prior to this.
  • Start a new game with 3 lives.
  • When a life is lost, start the ball in the middle of the screen in a random direction
  • When the last life is over the game can simply restart with the default lives for now.

To make breaker levels interesting, there should be a couple different brick types.

This issue should be done before Levels & Scoring

Add the following types of bricks:

• Unbreakable Black Bricks - worth no points, always black, and have a unique, 'tinny' sound.
• Double Bounce Bricks - bricks that take 2 collisions to break.
  • Make this system extensible so that triple, or quadruple bounce bricks can be added later

On going projects could benefit from a common logging utility.

The Logging utility should have the following features:

• Simple api with create, and write.
  • If create is used twice from the same executable, it should return the same log
• Discrete levels of warning, e.g. Severe, Warn, Info, Fine, etc.
• if Debug mode is enabled, the write should tee to the log file and stderr