HentHighSchool Development Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

collapse
* Recent Posts
Re: [HHS+ 1.9.5] Official Bug Report Thread by Shilo
[Yesterday at 07:42:57 pm]


Re: [Mod] King's Way 2.0 by Spellsword
[Yesterday at 05:21:58 pm]


Re: [Mod] King's Way 2.0 by vadi92
[Yesterday at 04:13:53 pm]


Re: [Mod] Grafitti and interrogation (function) by fateavernicus
[Yesterday at 02:05:31 pm]


Finished the events/game/entire town enslaved by you! by fateavernicus
[Yesterday at 02:00:29 pm]


Pages: [1]   Go Down

Author Topic: Time, Scheduling and the annoyances of the background concerns  (Read 4973 times)

Zythen

  • Code Monkey
  • Administrator
  • Sr. Member
  • *****
  • Offline Offline
  • Posts: 406
    • View Profile

The game wouldn't be anything without it, execution of the day to day events that make up the random background noise behind any major/main event which the player is involved in. The tick and tock of time passing and life continuing.

In essence its the modelling of time and its passing and management of it in the game, and is one of the more fundamental and important elements of the game foundation, and as such, its one of the more important parts to get right as soon as possible.

Here I hope to outline for anyone to read, and discussion if anyone is up to it, of what I've settled on for management of scheduling and time within the game. Hopefully I've accounted for enough flexibility in the future, as I envision eventually that the core schedule will be manipulated or enhanced by scripting additions from content authors, as opposed being stuck to any rigid hardcoded (ugh) or loaded schedule.

The concept and the final implementation is actually quite simple when you think about it. The game has a master Calendar object, it is responsible for carrying the current time and day. It is the object you tell/ask to advance time, and it is responsible for ensuring that any schedule is advanced accordingly by communicating with the other objects in the game.

For example, you could ask the Calendar to advance to the next day, whereby it will specifically run through the instruction to pass through every minute until 11:59pm and then advance the day by one before resetting the time to midnight. Other methods allow you to advance to a particular time in the day, another to just increment a specific number of minutes.

When advancing time, the Calendar will iterate through all the locations (locations will likely have to register themselves with the Calendar, otherwise they are "outside of time" as such), and tell the location that its about to progress through a specific period of time (the Calendar ofc will know the start and end time of that period and supply it), the Location is then responsible for updating its local environment and updating any information it needs to (in the case of School, lessons are taught, people interact, school closes.. whatever). This goes for any number of locations in the game which means it doesn't have to stop at the school and surrounding town. Of course having locations within locations is another concept, so you can have schedules and environmental updates for a myriad of things, specific shops within town, a cafeteria within the school (although tbh, that would likely be better to schedule in the school).

The schedule object itself, is a sequence of time periods which are named for the sake of human readability, and will be tagged/linked with functionality which executes the environmental changes for that time period. This tag/link can relate to a piece of specific code within the location, or in later versions of the framework, user written scripting. This means, specific locations can load thier own schedules, and content authors can script and add thier own elements to the schedule thus allowing for expansion beyond the hardcoded events for each location type.

All this bound together allows the update of environment in each location in the game and organised in such a way that expansion, reorganisation and flexibility is retained to a rather significant level imo. Of course, the previous discussions of time periods or time slots are just the UI applied over the top of this. Regardless of which system is implemented this schedule setup will allow for either, its just a case of patterning the advancement of time.

Of course, the actual implementation of this is rather more complex than it sounds, and needs to be thoroughly tested, otherwise things either don't happen, happen too often, or time just twists and everything tastes of purple before imploding and the system dies :)
Logged
Pages: [1]   Go Up
 


anything
SimplePortal 2.3.3 © 2008-2010, SimplePortal