Custom Calendars and Times

Hi all,

So I've fallen off the blog wagon again, but never fear, I haven't just been checking out the latest cosplay porn videos based on Nier: Automata or Overwatch. I've put work on Particularly Wavy on hold for the moment to focus on a creation tool for the Unity Editor: a tool that lets a game designer create a custom calendar.

Why would I do this? This is yet another part of my plan for creating a deeply reactive RPG/RTS smashup. I don't want to just use the default calendar system, with 365 days in the year, 12 months named their familiar names with their familiar lengths, seven days in a week, 24 hours in a day, 60 minutes in an hour, and 60 seconds in a minute. I want to set my game in a fantasy world, so it makes no sense for them to use our calendar. But, at the same time, I don't want to hard code everything for that particular game. I'd really like a tool that lets me set up the calendar how I want, and then get on with designing the rest of the game. The NPCs in the game will make plans based on this calendar, they will have needs and moods which change based on events (which happen at particular times and last for set amounts of time), quests will have time-based elements to them, such as meeting an NPC at a particular time of day, or completing a task within a time limit, and of course there will be a day/night cycle which influences NPC activity and stealth, etc, etc.

I have now began working on such a time system three times, and I think the 3 time could work. The first two were based on an extremely flexible system with classes something like the diagram below. The work flow would go something like this:

1. Create a calendar
2. Start adding time categories. The first time category added is always primitive.
3. The secondary time categories can be changed on the fly:
• their base category
• the number of base categories
• the names

As a small example, if you wanted to mimic Erikson's Malazan Book of the Fallen time system, you could first create a calender, then create a primitive time called Beat, and set the length to 1 real time second. Then, create a non-named time called Bell and set it to equal 3600 Beats, making it the same as an hour. Next, you could create a non-named time called Day, and set it equal to..., say, 24 Bells, for now, although we really don't know exactly how long it lasts. Lastly, you create a non-named time called Year and set it equal to...nobody really knows, for now let's be uncreative and set it to 365 Days. If we wanted to add months, we could to this by adding a SequentialGameTime before the Year, calling it Month, and then adding however many month names we wanted inside this category, and then setting the length to be identical, or giving each month a different number of days in it.

However, I needed to duplicate most of the code for every class because the BaseTime class is based on Unity's ScriptableObject class, which can only be created inside the Unity Editor and not during actual gameplay. This would prevent me from making a new date or time requirement dynamically, which defeats the whole purpose of creating the time system in the first place. I was also using Unity's UnityEvents, which function something like C#'s delegates and events, but are serializable, so their listeners persist after you close the program down and relaunch it. However, although they sound nice to work with, they are actually a huge pain in the ass.

So, instead of having complete flexibility, I created a system with Second, Day, and Year built in, and then allowed the designer to create subdivisions of Day and Year in order create however many or few categories they wanted.

Right now, I am at the stage of making sure that I can accurately update this system during runtime, after which I will worry about saving and loading a game time, and still later I will worry about setting times for events and conditions such as those described for NPCs and quests above. So far, it seems to be flexible enough and easy enough for me to understand what to do etc, and does not require duplicated code.

I do still plan to return to Particularly Wavy in the near future, but for now this is what I'm most interested in working on.