IndieGameDev.net Forums

You might find someone in /r/playmygame or /r/testmyapp

I wish I had a mac to help you out.

Saving and loading is always something I leave until mid development and I realise I should have incorporated it sooner.

Those are the reasons I don't add the feature from early either. I guess I just don't remember to come back to it early enough. End result is I can play through the game without being able to save, then I need to add the save game feature, so now I'm adding serialisation to everything.

EighthDayAdvent wrote: ↑Mon Jun 08, 2020 10:54 am

Deckhead wrote: ↑Sun Jun 07, 2020 10:29 pm Those are the reasons I don't add the feature from early either. I guess I just don't remember to come back to it early enough. End result is I can play through the game without being able to save, then I need to add the save game feature, so now I'm adding serialisation to everything.

Yeah I had a lot of pointers stored in data structures that needed to be converted to IDs and then loaded in. I didn't really plan it out but whats done is done.

I'm so glad I've implemented a Entity-Component System. No more pointer serialisation; just a bunch of IDs. I can't stress how much easier it is to work with.

I'm not 100% with your data layout from your description; but on the surface, having a series of pointers to neighbour tiles is going to cause a lot of cache misses.

Are these pointers to each of the subtitles on the neighbour positions, or pointers to the "parent" tile?

You can always make pathfinding faster at the expense of memory. In case you've not come across them before, Vector Fields could work for you... depending on map sizes. If there's sort of "landmark" tiles that you always need to pathfind to, storing a vector field for each could improve things. If you need to do a vector field for each tile... it could be quite a big footprint.

I'm always amazed that I wrote some of the code I uncover in my code base. It's garbage some of it.