So, we have the slimes on the client and server, now what?

Well, I don't really have a clear picture of this point in development. It's kind of a limbo between getting the networking set up and the slimes loading and getting started on the care systems. There are a few things I need to do, important things. The order I do them in isn't important, however.

One of these things is character creation and loading. I've done this before so it shouldn't be too hard to do again, the data is modeled in a similar way to the last time. I will also have to animate the player character and add some input handling, state machine, all that fun boilerplate stuff for a player character.

I also need to start thinking about how the slimes will animate, how many frames I want to use... ask myself questions like "Do their faces change?" and "Do I want to use a squash and stretch with in engine deformation of the texture or do I want to animate that in the sprite sheet?" among myriad other decisions I will have to deal with for the foreseeable future.

Then there's the script loading for the client and the server for each slime part. Not all slime parts will have scripts but the ones that do need to be loaded into the client or server respectively. I also have to consider how these scripts will work. The initial thought I had was to write a bunch of hook functions, then in the main slime fire the hooks whenever certain other functions are run. Like an On_Tick() or On_Fed() function that are triggered whenever these things happen. Of course, there needs to be an On_Load() to handle anything that would modify the slime from the start.

Finally I need to decide how I want to handle the apartments, I think I will make them a little less... complex than the Gerucrash apartments. I may forego the tanks for now and leave the customization for after I get the actual slime interactions and care working this time. I do think it's important for the player to have a few creative outlets in game and their apartment is where most of the game will take place until I start on the adventure systems(maybe next year sometime).

Then I can load in some slimes to an apartment, load a player character in and get on with the development of the actual game-play. I am going to assume it will not be until mid October at the earliest that I get to this point.

I suppose since I am already working on the slime loaders I should just get on designing the script template and get them loaded. For now all they will do is print that they were loaded, then as I add more functions to the slimes they will get more complex, I will try to account for what things I think will require hooks for the template now. This should make developing the functions that will call these hooks in future a little easier.

Gonna be a lot of hooks here. Tedious but it will allow me to imagine what these things could be used to do, so that's fun.

In the case that I am somehow not the only person developing these things I think it is important for future devs to know how this works.

Now that I have a basic template here that will likely change as the slime develops more I can write the code to load it on the client and server side. I will use the Jack face since I can use it to test things like loading a shader for making it glow or a particle emitter to make some sparks come out of it's eyes now and then.

I will have to write a particle emitter wrapper I think, something that can take the sprite and use it as the area of the emissions in some cases. Anyway, first I need to get the scripts added to the database and loaded from it. The question is; should I cache them on the client or just load them directly? It's a lot of API hits to load them all but, even encrypted if they are tampered with it could become a problem. I am thinking of things like having a slime feed itself automatically, etc.

I will just load them directly for now, hopefully I wont need to worry about caching them.

I've also just remembered I need to add a Slime versioning system to the loader while I was looking at the model uploading the scripts.

I suppose I will kill two birds with one stone when I load the script client-side. Making a note of it here so I will get on that once I get done with lunch, as it is now that time of the day again.

Looks like it's time to modify the serializer for the client API endpoint. Oh boy. I need to add fields for the URLS for each potential script that client might need to load for the slime.

Hmm... this will create a lot of database hits for each slime loaded...

I could have the Slime model hold all it's own script references, however on every update to a part script it would not be updated to the slime as well unless I directly link to the file in the post save function. Even then if the file name changes it would break the link.

I suppose I could write the upload function on the API to automatically handle file naming... then do as above. Hmm...

The script would also have to be changed if the slime's part is changed for any reason. So this would have to be handled in the post save function. Maybe I am overlooking another, smarter way to handle this.

I suppose I could also just prefetch the parts when a slime query is fired... but that would make the query even slower, it's already dealing with a lot of data.

For now I will just use the serializer method I started out with and revisit this at a later time, once I have a clearer picture of how this will need to be optimized.

I might just use a redis cache of the queries or something in future.

Alright, didn't seem to add too much more to the query time after all though I suspect this will change as more parts are added.

I've written a file formatter for the script uploads as well, to prevent overwriting. As you can see it was implemented after the Jack face script was uploaded, let's check and make sure it works by re-uploading the scripts.

Oh yeah, didn't use UUIDs for the PK fields on the parts.

Maybe I should add the name to the filename as well. ID+NAME.gd.

Nah, I settled on

{instance._meta.model_name}{instance.id}{instance.name}.gd

That should prevent any overwrites.

The client is now loading all part scripts.

Well, got the shaders to load.

And a shine shader...

I still need to create and load particle effects, but this is promising.

Anyway, it's time to clock out. I got 2 working shaders and have the scripts saving to the API object storage and loading to the client. I still need to load the server scripts over on the game server yet but that should just be iterating on what I did on the client.

First thing tomorrow I will work on creating a particle emitter factory for the scripts to call in order to build particle emitters for the slime parts as well, to add further customization.