kevy

Gardevoir has a gun, and he is FUCKING PISSED

* Ability to set tile rotations and flip X/Y.

* The above feature exposed several loading and rendering bugs that have been squished.

This made me realize that having to manually click what direction I want my tile to appear as is horribly inefficient. Will need to think of some keys to press that can work as shortcuts instead.

Works great otherwise. Definitely saves on memory when you can reuse assets.

* Centralized asset access to a common static class.

* Implemented a better tile picker. Instead of using the scroll wheel to cycle through every tile until I land on the one I need, I can just click a button and it switches to that tile. This frees up the scroll wheel for zoom control, which I plan on adding on later.

To do, probably tomorrow:

* Loading json maps implemented.

That's about it for today. This could've happened yesterday, it's not hard for me to load in a .json file and parse it. Issue was, I needed to re-arrange my code a bit more, and I didn't have the energy to do that yesterday. Had to start switching gears to start getting ready for work.

So I spent some time making sure my asset system pipeline worked. Made a handful of tiles, saved, loaded, fiddled with a bunch of names to make sure there weren't any conflicts, blah blah blah. Things are running smoothly, so after this point I need to start working on a proper editor. Using keys and mouse inputs that make sense and create a workflow that won't make me want to tear my own hair out. I have the next 4 days off, so after chores, I can definitely start cranking out some work.

Have an in progress screenshot!

"Polish as you go. Don't depend on polish happening later. Always maintain shippable code." - Romero's Programming Principles

* Preprocessor now renames assets into a 14 byte string, reducing asset bloat.

* Program now can save map data as a .json.

These two changes actually brought up a problem I hadn't accounted for today. I had no way for my program to dynamically infer what asset was what. In short, if I changed the order of my assets in the folder, by renaming them or adding in a new asset that doesn't fit in neatly at the end of the list, this would effectively break the save. Since the file would get renamed based on the order it gets loaded into the preprocess, there was no way for me to guarantee that asset 0001.png was the same asset every load.

This brings back one of my more common lessons I like to share with other programmers, and that's to always design your code to be dynamic/flexible. Since we're in the age of computers that can afford more loose (but still rigid) code, it's always within your favor to make sure the worst case scenarios get addressed, even if you're confident that any edge case or failure will never happen. Funnily enough, the poster I'm quoting from also has a bit on this in a similar vein:

"It's incredibly important that your game can always be run by your team. Bulletproof your code by providing defaults for load failure."

* Wrote a very bare bones map editor. All tools start off very basic. All I can do right now is left click to add a tile, and right click to remove a tile. There's no coordinate limitations in it what-so-ever, so I don't have to worry about how big I make the maps, aside from performance reasons of course.

At some point, I will have to start saving these into .JSON files for maps that are WIP, then a custom binary version for finalized versions.

Some more tool basework today.

* Pre-compiler generates enum for assets. This allows me to not have to worry about memorizing the file path for an asset, just the file name.