Proposed GameTime addition

[clintbellanger]

Henrik's sent in a proposed Game Time addition (see pull request #924).

We haven't discussed this. As with all major features, let's talk about it before we consider merging it in.

I do like the idea of showing elapsed time played in the load game screen. I'm not sold on the idea of basing events off of elapsed in-game time, particularly for this genre of game.

[hean01]

imho, controlling a story by time adds a dimension to the game, your not bound to strict quest lines and adds a more dynamic side quest handling. Take for an example a side quest around the zombies in northern frontier plains, with a quest dialog like:

Trade guild dialog:

[dialog] you=What about the frontier plains? him=Something strange is going on in the north graveyard... him=...at night zombies crawl out of the graves. him=All delivers of provisions to our outpost must be done during the daytime.. him=I will reward your with 40 golds if you end that madness. set_status=fr_plains_graveyard_start

and let the [events] that spawns the zombies only be available after midnight like

available_within=00:00:00, 00:04:00

which makes the quest only to be available for ending in the in game hours.

The formatting of current in game string looks like: Day 3 - Afternoon, see Time::toString(), i had this viewed in minimap while testing it all out and it was a nice dayperiod hinter. Having a hh:mm:ss clock is out of the question/scope, in this genre of game.

The initiative to adding this GameTime is that i started with some dynamic lightning and needed a time track to change the overall scene lightness for the hours though a day.

Additional ideas can be enemy stats controlled by the in game time, for example a zombie could be 1.5 stronger at night then in daytime, a quest enemy grows strength over time so the later you take the enemy out the harder it will be..

[hean01]

To clarify what the pull request includes are:

Adding the GameTIme impl. into the game so it tracks time, save/load from saved game and a display a duration of game play in the saved game menu. That is all, the other information about controlling game quests etc. is just possibilities with this pull request.

[dorkster]

I don't think I like the idea of time-triggered quests. What fun is it when you're ready to get a new quest, but you have to wait around for it to become active? Or worse, you miss the time window the quest is available in and have to wait another day cycle.

That being said, a quest enemy that gets stronger over time sounds pretty cool. Having enemies being stronger at certain times of day could work, but we'd have to make sure we had a solid lighting system.

[clintbellanger]

I wish we could have a nice lighting system. There's no real way to do that in vanilla SDL 1.2. I mean, short of using SDL + OpenGL. It does keep the core engine pretty simple though.

One possible way to handle day/night is to have e.g. two versions of the Grassland tile set, one day and one night. And check GameTime on map load. But that might be getting outside the scope of the engine, really. I'd like to leave the persistent world stuff to heavier RPGs, and keep Flare closer to Action-RPG simplicity.

[igorko]

I like current stuff. Time dependant quests should be discussed later, after light will be added. Few notes:

• IMHO it would be nice to add overall time counter and current time to GamePlay Window. But as currently we don't have lights, time of the day will be confusing.
• enable_playgame string should be in separate file. Maybe we will move it into another config file, called "mod_type.txt"

[hean01]

I'm currently working on a lightning system, that's the whole reason for why i added this GameTime object.

I will present write up and screens / techniques when i have a prototype implemented for further discussion.

[clintbellanger]

Interesting. Mind mentioning what approach you're taking? I don't really know of a good way to do it fast and nice-looking without introducing a ton of new dependencies.

If lighting is the main motivation behind these changes, perhaps I can create a "lighting" branch where we can pull these time changes and experiment with lighting. Then if the lighting reaches an acceptable quality/speed level we can merge into the master branch.

[clintbellanger]

Ok, I created a "lighting" branch. @hean01 can you please merge with the latest changes and issue a new pull request to my lighting branch instead?

I think these time additions aren't strong enough on their own to be in the current Flare master, but if we got a good lighting system going then they'd be well worth it.

[igorko]

@clintbellanger I have pushed changes directly, but looks like GitHub doesn't handle commiter name correctly(so this should be avoided in future). Or maybe it was because I didn't set username in repo settings...But it always differs from github account name. Anyway branch is now up-to-date.

[igorko]

@hean01 Is there any progress?

[hean01]

@igorko Not really

General the techniques involves several renderings maps of an object/tile, texture rendering, ambient occlusion, normal map which are used to calculate the lightning, the lightning is per pixel calcs into surfaces which is a bit slow and the i need to blit with mul for the calculated light surface which is done per pixel, i need to do some more investigation on how to use gl textures or how the sdl_texture works, looks like it has a mul blend mode..

[igorko]

Note that Clint doesn't plan adding openGL dependency before beta release, though you can talk with him about this.

Clint said "I don't know of a way to do this with SDL (even in a simple way, just blitting an entire tile darker or lighter). If we used SDL + OpenGL it would be possible, but we're not moving to OpenGL just for this.

Maybe SDL 2.0 will allow something like this."

[hean01]

@igorko i know, SDL_texture is a feature for SDLv2.0 and might live up to what the approach needs.. i need alot more time to look into the topic...

[stefanbeller]

@hean01 Any update on the dynamic lightning system?

[igorko]

@hean01 can we move this issue to flare-engine-next? @clintbellanger Or we still can implement this for 1.0 ?