The Server Tick Foundation

So now I suppose is where I start the server tick. Today will be interesting. I have an appointment at 1:30 so lunch might be the end of work for the day depending on what happens after that. However, I would like to get the server tick code started if not to a point where I can start implementing day and night. I would like to get the basic systems in place for the care gameplay loop before I go and start adding graphical detail like animations.

I may spend some time on my lighting once I get day and night in, just for a change of pace, then get back on to the care system functionality and balancing the secondary stats to the primary. Adding mini games for study, play and training will come a while later, but the very core of the gameplay loop will hopefully be done by Halloween. In the case that I am actually moving, I will then have a short time where I wont be able to work on the game at all. Then I will be back to it, probably starting on adding the player to player interaction systems before moving on to the details and mini games.

At any rate, I need to consider how the tick will know the time. I think the best way to handle that would be with the database, as I may have mentioned before.

So I will create an app in the API that will track server-related things like last tick, config, current running events, etc. Then expose endpoints accessible to the game's socket servers for loading the config and saving/loading the last tick. I will need a model that has each server as it's own object in the DB, if there are multiple game servers or login servers the API needs to know the difference between them, so I will have to assign them IDs and then have a config model with a foreign key to the server that needs to load it, etc.

Modelling this data is important, it will help me think about how the servers work and what values should be dynamic. For instance, maybe I want to change the rate at which stats tick down for an event. Maybe I want a thanksgiving event where slimes can eat more often.

I also have to consider things like maintenance mode and closing servers down to only allow staff in for investigation of bugs or player jiggery-pokery. Also what regions the servers are in for players to have the ability to select the closest server to them for better ping. I also have to consider that maybe there will come a time where all the servers can not use the same database and figure out how inter-server communication will work in that case. Probably an intermediary DB? I will cross that bridge when I come to it, but it's better to have the thought of it early so I know it might be a problem and can prepare for it.

It's a little hard to focus with this phone call looming, but I am making steady progress in figuring out what sort of things should be moved from magic numbers into configuration.

It's going to be a lot of repetition now, sometimes we can't do it DRY, but that's why we have Ctrl+C, Ctrl+V and Ctrl+D.

I am finding that the workflow of writing a broad overview design document first, then creating the models for the data, then implementing the systems on top works best for me these days. There's still a lot of winging it involved, but I am able to keep the big picture more clearly in my head as I make decisions. Of course there are changes to the data model as I implement systems as I go, nothing is set in stone. But largely the models build a pretty good foundation and have become more a part of the design process than the implementation phase.

The way I used to do it was to lay down a basic idea of what the data would look as quickly as I could in order to get to the functionality of the systems around it as fast as I could. I have learned, of course, over the years, that this was foolish and that the most important part of any software is the data itself. After all, the basic idea of programming is telling a computer how to manipulate data.

Anyway, back to the model. Needed a break from repetition to prevent myself making stupid mistakes.

I want to spend a little more time thinking about the server tick tracking, like... is there any reason I would want to track every single tick individually, making a row in the DB for every single time a tick is fired? Probably not. I mean, I can't think of any reason to.

Is there any other data I should store in the tick tracking aside from the server that fired it and what datetime was? I can't seem to think of anything. The servers are aware of their own timezone in the model so no need to be tracking that.

Welp, with that... I think it's time to make and apply migrations, then build the endpoints so the servers can load their config. Gonna be the first update I make to the login server in a while, actually. It's 11 now, not much more time today... I wont rush it though, if I have to come back and resume where I left off tomorrow then that's what I have to do. I knew this week was going to have some hiccups.

It occurs to me I didn't create string representations for the models.

I should do that.

That will work.

Now to configure my local dev server.

Tick log is in place, now to get them endpoints up.

Next I need to load the data from the API onto the servers. First, Lunch and phone calls.

Welp. No call came. Looks like I will be making more calls tomorrow. For now I will be starting with loading the login server config from the API.

Probably want the server objects to reference the configs, not the other way around. Not sure why I did it that way.

Now to map all the config data on the game server to it's CONF singleton and then tomorrow after I make some phone calls I can get to work on implementing the tick and sending ticks to the API to be logged.

Config mapped

Just going to make sure the login server is able to get the game server's IP from it's config and then I am done for the day I guess. Not much else I can do with the time left.

K.

Well, that's all working. Going to make a build so I can run the login server from terminal like I tend to do and push all changes.

Now I have the foundation for the server tick, I can get started actually building the game loop tomorrow.