Got a silly proof of concept working. The only sprite / object involved is the cursor, which uses a simple script for each direction to add 16px so it always stays on grid, along with a script for selection and deselection of units. It also uses several variables I added to keep track of:
- whether or not a unit / building is selected
- the index of the unit selected
- the underlying tile collision data
- the underlying tile graphic data
On a very basic level it works pretty swell! Or at least it looks nice on paper. There are several big things that are confounding me on taking it further, so maybe people can add to this topic if they are interested / knowledgeable and want to see this sort of thing in module form in the far future:
1. An efficient method for storing and accessing underlying tile data such that it can be read but not written over. (the current method I use works, but is a bit of a cop out, as it is only storing the last known tile, which varies from position to position / unit to unit over time, and is not actually storing all the data properly). I am guessing there would need to be a separate table of level data that you simply pull from whenever you swap a tile back? How do you add such a thing? EDIT: I got around this by making all ground tiles the same index, and simply being creative with how they palette swap, such that you get four different textures (shaded from light to dark). All other tiles are solid / other collision types.
2. Checking for tile collisions / indices at any given moment/place. I am currently using built-in tile types reworked to do what I need them to, so collisions are handled with the tiles as normal in engine, but what if I wanted to, if I hit the B button for instance, check a tile to the right and do something if it finds a certain index (like attacking to the right if there is an enemy tile)? Having tried this in code based upon the available scripts, it never seems to work right. EDIT: I figured out how to use the basic 'GetTileAtPosition' subroutine, which can be used to this end. You have to load the x and y you want to check into the system variables 'tileX' and 'tileY' before running the subroutine. The Y register then holds the tile type, and if you load the A register with the 'collisionTable,y' data, the A register has the tile type! You can then just do things by comparing it / branching etc. based upon what you got.
3. A good place /method to properly loop through each existent "object" represented in tiles and alter their variables as needed. Each unit or building in theory only needs a few variables to function (health, state, position for checking against others). Having worked with object oriented programming languages, this is the part that is the toughest to wrap my tiny brain around. Maybe just a table of all possible units / buildings up to a limit that you just add / subtract from with each thing having an index value to look it up from? I don't rightly know.
Hope this isn't too tenuous of a thing to post in this section, but I figured some people might be interested.
- whether or not a unit / building is selected
- the index of the unit selected
- the underlying tile collision data
- the underlying tile graphic data
On a very basic level it works pretty swell! Or at least it looks nice on paper. There are several big things that are confounding me on taking it further, so maybe people can add to this topic if they are interested / knowledgeable and want to see this sort of thing in module form in the far future:
1. An efficient method for storing and accessing underlying tile data such that it can be read but not written over. (the current method I use works, but is a bit of a cop out, as it is only storing the last known tile, which varies from position to position / unit to unit over time, and is not actually storing all the data properly). I am guessing there would need to be a separate table of level data that you simply pull from whenever you swap a tile back? How do you add such a thing? EDIT: I got around this by making all ground tiles the same index, and simply being creative with how they palette swap, such that you get four different textures (shaded from light to dark). All other tiles are solid / other collision types.
2. Checking for tile collisions / indices at any given moment/place. I am currently using built-in tile types reworked to do what I need them to, so collisions are handled with the tiles as normal in engine, but what if I wanted to, if I hit the B button for instance, check a tile to the right and do something if it finds a certain index (like attacking to the right if there is an enemy tile)? Having tried this in code based upon the available scripts, it never seems to work right. EDIT: I figured out how to use the basic 'GetTileAtPosition' subroutine, which can be used to this end. You have to load the x and y you want to check into the system variables 'tileX' and 'tileY' before running the subroutine. The Y register then holds the tile type, and if you load the A register with the 'collisionTable,y' data, the A register has the tile type! You can then just do things by comparing it / branching etc. based upon what you got.
3. A good place /method to properly loop through each existent "object" represented in tiles and alter their variables as needed. Each unit or building in theory only needs a few variables to function (health, state, position for checking against others). Having worked with object oriented programming languages, this is the part that is the toughest to wrap my tiny brain around. Maybe just a table of all possible units / buildings up to a limit that you just add / subtract from with each thing having an index value to look it up from? I don't rightly know.
Hope this isn't too tenuous of a thing to post in this section, but I figured some people might be interested.