Procedurally generated HTML5 3D world with day/night cycle
endtime.at
endtime.at
https://www.youtube.com/watch?v=RjAyq2kmGT8 - I left at the time trailer was recorded, but effects like day of time are still look like my work (as are explosions, it seems).
As I haven't had enough experience then, I made your mistake - there was no difference between dusk and dawn. And, in fact, there is.
The dust that gives red color of the sky sets down before dawn (pun intended). Thus dawn glow is much less reddish and more like red gold.
(overall effects like intensity of light can be computed from cos(sun light angle to player's normal), subtle effects like change of glow's color can be computed from sin(sun light angle to player's normal), just in case)
In your simulation there's no anisotropy in color of the sky. And this is HUGE mistake. Sky's diffusion and reflection is very anisotropic and omitting this gives your simulation very unnatural feel.
I discovered this game some time ago, from the CopperLicht engine home page[1]. I am a web-developer by day and an amateur 3D designer after dark, looking to build something similar. If the creators of End Time are here, can they (or anyone with experience in this domain) share some insight about the development process, especially procedural world generation?
It is nothing really complicated: I created a deterministic randomizer class, and generating the worlds 3D geometry based on each squares coordinates as random seed. Terrain is currently based on a simple sin/cos function, buildings are built from blocks like minecraft does it. See the third Copperlicht tutorial in its documentation on how to create own geometry and stuff.
I know it's a crappy graphics card, but this demo isn't some magical eye candy either, and there's not even a lot of gameplay going on.
I'm not sure if the problem is actually on the graphics programming side of things (bad shader maybe?) or it's just the javascript being slow.
The real solution would probably be finding an effective way of dealing with memory on the client side. I don't know what the state of the art in javascript land is but big environments like this are better streamed from disk into memory portion by portion rather than putting it there all at once (i'm pretty sure there is no standard api that lets you do something like this).
You keep track of all the points the player is currently looking at, and sort them. Then when the world state is updated, the server check all clients whether to send the new update or not.
There's also not really a lot of benefit to doing something like this. Maybe you run better on computers that have worse graphics cards (and I don't actually think you will), but you'll run worse on computers with worse internet connections. You also are now spending a lot more on servers because every player needs a nontrivial portion of a server machine.
If you have any kind of multiplayer game: It would make cheating harder, and make some kind of cheats impossible.
(yeah, I know it's 2D isometric and not real 3D, but it's still pretty, and it's still a fully-functioning roguelike)
You do have to have be careful when applying this carte blanche on procedurally generated terrain, as you can end up with all sorts of unrealistic/dangerous/fun? cases.
Cool demo though
when i keep my mouse and drag around screen. How can one JS application can make my computer dance ? Great game.
Sad to think this poignant simulation will eventually become just another zombie shooting club.
"Get out of here stalker".
And that's not bad at all.