fishies / sf-snake Goto Github PK

Would it be better to draw using sf::VertexArray?

(Maybe data representation might also only keep vertices of the snake rather than every block... but computation would not be as consistent; a player who changes directions more often would have a more computationally expensive game. Not sure if this second idea would be better in every scenario. For which scenarios do I want to optimize?)

The game currently lacks music and sound. Such critical components of any properly polished game should not be neglected.

Allow the player to customize game options such as keybinds, size of level, speed of game. This may require a menu screen.

Currently when the player selects a direction to turn, input is locked until the next frame. Therefore at times the game's controls will feel unresponsive. The proposed solution is to replace input locking with a Direction variable that always accepts input deciding what direction the snake will turn in the next step (so actual direction change is not processed until the start of the next frame).

This one is relatively straightforward to implement; just check the food's spawn spot against the tail hash set before making the placement.

Currently sf-snake uses cstdlib's rand function, even though this is supposed to be a C++11 project. The C RNG in this code should be replaced with C++11 library function(s).

Currently the game's collision checking logic is O(1) due to use of a hash set. However, the hash set is used alongside a queue for O(1) tail growth/movement. Therefore the space complexity is O(2n) -- still linear, but is it good enough?

We can eliminate the need for a queue with some changes to what we put into the hash set; we want to track the "age" (that is, the game tick number on which the tail block was generated) of each tail block and pop off the oldest one with each step.

So we want to:

• Keep O(1) collision.
• Track "age" of tail blocks.
• Be able to check for "oldest" block in O(1) time.
• Account for overflow in "age" variable.

Proposed solutions:

• Perhaps we can change unordered_set to unordered_map with coordinates being the key and age being the value? Would run into problems when checking for oldest.
• Hash a single value containing data of age and location? Would run into problems checking for collision.

Wall collision is checked in GameBoard::update() and tail collision is checked in PlayerPiece::step(). Should reorganize code.