kevy makes a game

I try to make a game and post my ramblings here.

[kevygame]

09DEC2021

Started outlining the binary export for maps.

The difficulty comes in having to come up with a format that is it's layout. Can't just write numbers to a file, you have to come up with rules on how to write it, and how to read it. Bonus points if you can make it flexible, which I thankfully know how to, but the hard part is figuring out what data is necessary for this format. So, while not a whole lot of code got written today, a lot of planning (mostly in my head) happened.

There's also the issue of binary formats culling unnecessary info. Have to take a hard look at what is only necessary for editing purposes and cut that info out for the final product.

Which then leads into a separate chunk of code needed to interpret these files, which will not get the benefit of being editable, and will not get the benefit of running on already established code.

/shrug, part of the process!

[kevygame]

Took a break today. Little unsure where to go right now. I suppose map compiling at this point.

[kevygame]

07DEC2021

* 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.

Assets are definitely not final. I'm in no way a pixel artist, so I'll have to study a bit to get the aesthetic I want so I can avoid having it look like a crummy flash game.

[kevygame]

06DEC2021

* 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:

Add UI for tile properties. I currently have code set up to allow tiles to be rotated and mirrored, but no way to tell a new tile to use these properties.

[kevygame]

05DEC2021

* 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!

[kevygame]

Asks have also been enabled

Don't know if anyone is even looking at this, but if so, *shrug*

[kevygame]

04DEC2021

"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.

EDIT: This has since been fixed, forgot to mention that originally.

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."

These 'bulletproofs' have yet to be made in my code, I can only polish so much within the time frame I have before real life gets in the way. If I ever do manage to form a team, I'm probably going to take the role of lead developer and make the tools for everyone to use.

[kevygame]

03DEC2021

* 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.

[kevygame]

02DEC2021 - Let's try to make this daily

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.

* Binary backup system. This is a subject I've thought about for a long time and something I feel a lot of people would appreciate. I have some code set up to automatically back up compiled builds onto a separate hard drive, each will create a new zip per day (per minute/hour felt too specific). I've always had a fascination with cut content and how games evolve over time, so I'm working with this in mind, that one day, these builds will 'leak' on the internet, and eager fans will dissect it. also serves as a way to track any major library changes, IE "I know this was working yesterday, let's see what's different".

[kevygame]

Let's start things off - 01DEC2021

I want a place I can go to and publicly document my progress through this. Over the many years of slowly teaching myself how to program, I feel like I'm at a point where I can start taking the most important advice people have ever given me when it comes to game development:

"Just start making something"

My one obstacle I've had following this is self confidence. I can't make something if I don't know where I'm going, but at this point, my knowledge has fallen into place in a way as to where any problem I can think of, I can confidentially say to myself I know how to solve that problem. I want to start sharing this process and what I manage to accomplish each stab at the game I give. While I won't be sharing the private repository that will keep track of the more technical details, I'll be throwing in bullet points here on what got done, stuff I've observed, and problems I've run into.

01DEC2021 Changes

* Initialized the base project. Included needed API's and libraries to start building a base. To my right as I type this, I have a posted from John Romero, titled 'Romero's Programming Principles', and the advice being focused on here is "Great tools help make great games. Spend as much time on tools as possible." Also it's signed by the man himself. So a lot of early work in this is making the code that can help me build the worlds I need to build.

* Started work on the pre-compiler. The API I'm using works faster with a packaged resource system. This allows for assets to not be embedded within the executable, and saves on memory management.