Practice game 2
Practice game number two is going to be a space invaders clone.
Again it is something I could produce in a short period of time as it is a well know problem. I am not taking this route as I want to experiment with ideas and add a little bit to the game "library" that is very slowly amassing.
Library has quotes around it as the library and game code live in the same directory. They only differ inside my brain...
I spent some time working on a entity component system. Yes an over kill for space invaders but I wanted to get back into the mindset of using one. |It was kind of fun coding that up.
Having finally reached the point of needing some graphics I did a tour of applications that could create pixel art. Initially I though I could use Krita but it doesn't allow cut and pasting into the same layer. I want a cut and paste workflow for my 8 by 8 pixel art. Krita is not really designed for this.
Then I thought gimp but I didn't enjoy the UI. Some more searching and I finally decide to use aseprite. Unless you want to donate/pay then you build from source. If I find myself using this a lot I will probably purchase it. It built really easily although I did find it crashes when I try to export sprite sheets using the UI (I use Linux).
You can use aseprite from the command line fine and I will be exporting the images in a little shell script. I am going to end up with multiple ase files so the plan is write out all the individual frames of all the sprites to a directory and then pack them into a texture/sprite atlas using a different tool.
I like simple code and that means I like simple data formats. The positions of each sprite in the texture atlas is described in a separate, usually human readable, file. This is commonly a JSON or XML file. While it can contain additional useful information about animation groups it is not what I need or want.
This makes a JSON or XML much more complicated than it needs to be. A simple csv file would be ideal and easy to parse. So I start looking around and wow is one difficult to find. I started to think that perhaps I will write my own. The algorithms are not too bad and it would make a good weekend project. However I want to progress. Eventually after nearly a whole evening rummaging around I find a tool .
It was a little too late to actually try to build and integrate it but here it is https://github.com/whitingjp/spritesht. It looks like it will integrate well into my slowly growing make_data.sh script.
Getting this sorted I taken about the expected amount of time, setting up work flows is not conceptually difficult but does take a little time.
Again it is something I could produce in a short period of time as it is a well know problem. I am not taking this route as I want to experiment with ideas and add a little bit to the game "library" that is very slowly amassing.
Library has quotes around it as the library and game code live in the same directory. They only differ inside my brain...
I spent some time working on a entity component system. Yes an over kill for space invaders but I wanted to get back into the mindset of using one. |It was kind of fun coding that up.
Having finally reached the point of needing some graphics I did a tour of applications that could create pixel art. Initially I though I could use Krita but it doesn't allow cut and pasting into the same layer. I want a cut and paste workflow for my 8 by 8 pixel art. Krita is not really designed for this.
Then I thought gimp but I didn't enjoy the UI. Some more searching and I finally decide to use aseprite. Unless you want to donate/pay then you build from source. If I find myself using this a lot I will probably purchase it. It built really easily although I did find it crashes when I try to export sprite sheets using the UI (I use Linux).
You can use aseprite from the command line fine and I will be exporting the images in a little shell script. I am going to end up with multiple ase files so the plan is write out all the individual frames of all the sprites to a directory and then pack them into a texture/sprite atlas using a different tool.
I like simple code and that means I like simple data formats. The positions of each sprite in the texture atlas is described in a separate, usually human readable, file. This is commonly a JSON or XML file. While it can contain additional useful information about animation groups it is not what I need or want.
This makes a JSON or XML much more complicated than it needs to be. A simple csv file would be ideal and easy to parse. So I start looking around and wow is one difficult to find. I started to think that perhaps I will write my own. The algorithms are not too bad and it would make a good weekend project. However I want to progress. Eventually after nearly a whole evening rummaging around I find a tool .
It was a little too late to actually try to build and integrate it but here it is https://github.com/whitingjp/spritesht. It looks like it will integrate well into my slowly growing make_data.sh script.
Getting this sorted I taken about the expected amount of time, setting up work flows is not conceptually difficult but does take a little time.
Comments
Post a Comment