CSV TileMap Game

The first "full" game using this tilemap system has been released on github.

Blinkas Breakout GitHub

In the coming days it will get a project of it's own with some images and videos. 

Now that the basics of this system are working how I had originally imagined them I've gone back and cleaned things up a bit and tried to add detailed comments about everything happening. 

With that taken care of I have updated the code py file in the repo and files section to the latest version. Hopefully this can now serve as a good starting point for someone looking to build a tile based game.

I will probably leave the other variants of the code py file in the repo and files section in case anyone wants to see the different stages of development. But for now I would recommend starting from the current main code py file. It has all of the features and is the most well commented.

I think now I'll take a break from working on the engine to build one or two specific games using this system.

I've uploaded another new alternate code py file and a new map csv file to go along with it they are named "entity_system_and_camera" in the file section and the repo. 

This new example contains a re-worked world state and entity system. Namely they've been separated into two more distinct systems. This helped solve a lot of headaches around what happens when entities were located on the same tile. That's diving a bit into the nitty gritty though.  

The really cool thing about this update is that it allows for the map csv to be bigger than the screen. There is a very rudimentary camera system that will auto-follow the player as they move around the larger map. In the example code the map is wider than the screen by a few tiles and the camera will follow left and right as the player moves across a certain threshold.. Take a look at the set_camera_view() function if you are interested to see how we pull out the relevant portion of the larger map to draw onto the screen. 

Perhaps at some point I'll work on a way to load a different "zone" from a new map csv file. So the player can go in/out of buildings and between various "zones" within a larger game world without needing to have it all loaded at once.

But before I get ahead of myself I do intend to spend a bit of time cleaning this version up a bit more and documenting it much better. Once that is complete this will probably become the main code py file in the repo 

In the code.py file we draw the world based on the input coming from the CSV file which is pretty neat. We have blinka in the game that we an move around with the d-pad, also pretty neat. But beyond being allowed to walk on a tile or not we don't have any other interesting interactions or ways to change anything within the world.

Lets try to tweak it to allow blinka to change the world. In our case specifically by making it so that the robot head can be pushed around, until it gets stuck in a corner that is is.

I've added a new file code_basic_world_state.py that implements a rudimentary world state feature. Broadly speaking it allows for updating things other than the player inside the world by allowing tiles to declare a before_move function that will get called immediately before the blinka is allowed to move onto the tile. 

Now we can define a function and put some behavior inside of it. When the player moves blinka to the tile our function gets called giving us the opportunity to update something about the world (or do anything else we want really). 

In this example our function is allow_push(). It will let blinka push the robot by first checking to see if the next space in the correct direction is walkable, and then updating the robot sprite by moving it's position in one tile in that direction.

The other change with this version is that the location of blinka is determined by the 'player' in the csv file rather than hard-coded as x/y values on the screen.

As with the code.py file still this could use a bit of cleanup and some more clear commenting. I will do my best to get it done sooner rather than later but may still succumb one more time to the temptation of working on the next feature first: allowing for a maps bigger than the screen.