Dev Diary - MMORTS Resources

Dev Diary - MMORTS Resources

It has been several months since my last update; a lot of new things have happened in my life (his name is Æthelstan!). But back in the saddle I continued where I had left off: Resources!

The first part of all of this is harvesting resources. I've tackled now and will save the second half, spending the resources, for another day. This feature revolves around the definition of a resource node and a unit's interaction with it. I thought it would be extremely simple. I then started digging (no pun intended) into all of the quirks and problems. Finally I realized that things can be a lot simpler by creating look-up dictionaries (similar to old look-up arrays for trig values).

The main problems I ran into were: 1) How are resources stored, in memory, on the server and 2) how are node statues transferred to the client? To solve these I decided to create a dictionary of what type each node is with the location as the key (x+"-"+y) and a enum as the value. When a command comes in to harvest a node, I check if a node object had already been made. If not create it from this look-up dictionary (or reject the command if key is not contained in the look-up). This keeps me from having to store an object for every resource node in the zone. Instead only nodes that are less than 100% are actively stored in memory. Once a node is depleted (and after some time of it not being touched) I drop the object from memory, which effectively restores the node back to full.

Solving the second problem forced me to create a new update message to send the client the state of any active nodes. Because of the reverse look-up system if a node was full there would be no object server-side, and nothing to send in the update. To resolve this, on the client each node GameObject checks for an update that corresponds to its location key. If it finds ones it updates its stats and marks the update as 'consumed'. If the client node goes several update cycles without finding a fresh (non-consumed) update the node will reset itself.

This resource update has a flaw in it: lag. If there is too much lag between client and server an empty node may appear on the client as full/harvest-able only to disappear a second later when the update finally gets through. I've tried to hedge against this by making all update type messages the highest priority, but future safeguards will need to be installed.

Finally, I purchased some new assets from "Villains for Hire" (https://vfh.carbonmade.com/). These lovely humans are the artistic style I want for this game and will give me full models to utilize while developing the next phase of features. The featured image is of these four guys, and they have made this project a lot more fun to work with; especially when you mix up x and y, and your little crossbowman starts aimlessly wandering off in the wrong direction.

This next month my goals are to flesh out the unit abilities complete with healing, buffs, debuffs, auto-casting, and such.

Author face

Christopher Axthelm

Creator of Mad Hatter Worlds games. Facinated with logic, world building, and software systems.

Recent post

-->