Simulation Idea

[Mickey Kudlo]

The main idea being, EVERYTHING is dynamic, including plants, water, animals, monsters and NPCs.

Plants are easy, already have done that. They grow, spread seed, die.

Water and how it can shape the land via rain and rivers and flooding. Tried in V1/V2 but was always too dangerous and required close monitoring.

Animals would not spawn. Would roam, eat, reproduce, die. System would add more if population destroyed.

Monsters would not spawn except maybe in dungeons? Would roam, reproduce, build, whatever that specific monsters nature is. Wouldn't always attack players. Behavior toward players would depend on various factors.

NPC, basically human monsters with more advanced needs that players could fullfil. Like building them a house to collecting fire wood and food, etc.

One problem is increased CPU usage on server, could create a seperate AI program that connects like a client and controls stuff but easier to just multi-thread it.
Players also, may have problems coping with the extremness of the environment. Grinding to level combat skills not really supported but the 100 cap or maybe faster leveling may help.

[Miner 49er]

It would be interesting, but you would definately need to thread the server. If you wanted to be a risk taker, you could even attempt to use the gpu to process some of the AI.

[Mongo]

As stated before, absolutely love it .. every aspect of it.

I can see it causing strain on the hardware, but maybe if we can get some donations going we can get some new hardware up and running.

[Jon The Great]

CPU shouldn't be that big of deal anymore since servers are so fast today and with mutlithreading should be a peace of cake.

[Mongo]

Wait did it really just change my word to "toughware"?

[Miner 49er]

CPU shouldn't be that big of deal anymore since servers are so fast today and with mutlithreading should be a peace of cake.

I imagine the biggest issue will just be synchronizing all the threads. That would suck.

[Mickey Kudlo]

Well, if you have just 1 thread dealing with certain AI units(animals, npc) then it not too bad me thinks.

[Miner 49er]

Well, if you have just 1 thread dealing with certain AI units(animals, npc) then it not too bad me thinks.

Well, those AI units would definitely need access to the world, which I imagine would create a good bit of waiting if you spawn too many threads, and they all attempt to grab the world data. (Don't quote me on this, I'm not a threading expert)

[Greatest]

in theory I love the idea, in practice I remember all the sectors that were completely taken over by thorn bushes...

sim would be helpful for those of us who always tame sheep or cattle to keep a meat supply around, they always either die off or spawn like crazy.  so an actual way to control them would be good.

[Mickey Kudlo]

in theory I love the idea, in practice I remember all the sectors that were completely taken over by thorn bushes...

sim would be helpful for those of us who always tame sheep or cattle to keep a meat supply around, they always either die off or spawn like crazy.  so an actual way to control them would be good.

Would need the system to regulate to make sure a MIN and MAX level is maintained.

[Novibear]

That sounds cool to me too.

[Zachariel]

On the other hand, if you would implement my vision of client/server model,
you can shift (if not physics, then) less-important and time-insensitive
calculations to clients without risking security...

[Novibear]

Application partitioning is important for balancing out the workload.

[Mickey Kudlo]

On the other hand, if you would implement my vision of client/server model,
you can shift (if not physics, then) less-important and time-insensitive
calculations to clients without risking security...

Um, what "physics" does RPGWO have? heh
Or you just mean general world rules of actions? Like movement, combat, usage, casting, /pooping, etc.

[Greatest]

Um, what "physics" does RPGWO have? heh

I think he was hoping you'd add jumping to the next version...height/distance you can jump based on strength, agility, and burden

[Mongo]

I woke up 3 am tonight and laid awake, restless and unable to fall asleep, because I was thinking about how
the client/server model should work. I come back online at 8 am and lo, behold, Mickey asks which
client/server model we should use.

I got just the thing for you:

I envisioned an unified client/server executable, like you, but it does not quite work as you imagined it.
Current online 3D games make the server calculate some or all parts of the physics and other data,
so the player could not noclip through walls, wallhack and perform live injection or replay with
packet editors to go into godmode or give themselves millions of dollars.

Pretty sure that's what he was referring to.

[Zachariel]

I woke up 3 am tonight and laid awake, restless and unable to fall asleep, because I was thinking about how
the client/server model should work. I come back online at 8 am and lo, behold, Mickey asks which
client/server model we should use.

I got just the thing for you:

I envisioned an unified client/server executable, like you, but it does not quite work as you imagined it.
Current online 3D games make the server calculate some or all parts of the physics and other data,
so the player could not noclip through walls, wallhack and perform live injection or replay with
packet editors to go into godmode or give themselves millions of dollars.

Pretty sure that's what he was referring to.

Yeah, I wrote a long post about it.
If you really think this through, it makes sense.
When I wrote that post, I was assuming that you'd be remaking RPGWO in 3D,
however, my idea still works (and even better), if used for a 2D world, since
2D data is 1/3-rd lightweight than 3D.

You can't trust players to calculate their own environment, but you can trust them
to calculate the environment of someone else, if the server chooses whose' they will
calculate to eliminate the "buddy system".

Time insensitive calculations like the contents of a container (when entering a sector)
in the vicinity of the player can be received from other users many seconds later, as long
as the data is available when the player reaches the container.
Same thing with "knowing" the contents of sectors around the sector the player is currently in.
You don't need to fetch the whole world before starting playing, you need to know just enough
so the world will seem seamless, but the data of nearby sectors is always available and loaded.

This can be done for multiple of things, including player locations.

Imagine it as a P2P network, only that who talks to whom is controlled by central server.

[Naed]

I don't think RPGWO ever really implemented it but I work with SQL all day long, and a constantly evolving world of objects screams database to me.

UPDATE t
SET t.size = t.size + 1
from Trees t
Join Sunlight s ON t.x_pos = s.x_pos AND
                         t.y_pos = x.y_pos AND
                         t.z_pos = s.z_pos
WHERE s.intensity > t.minGrowthIntesity AND
          t.size < t.maxSize

I am not familiar with mmo games coding but it would only seem logical that they are run on big databases? I see no reason rpgwo should be any different for the simulation aspect of it. Text files can be exported in whatever format the server engine requires, on whatever schedules are required. a 1000 * 1000 * 128 world would span 128,000,000 entries for single units on a tiny world. I've never put the thought into the data structures that must be designed for MMO's until this moment, I would imagine that due to the size, some sort of sector system (like in rpgwo) of different sizes would have to be generated to manage the giant evolving world.

I will stop rambling and go write this down as I am not being useful here and have opened up more thought that I should on a work night.

P.S. for programmers I made no attempt to normalize my statement, it is an example.

[Zachariel]

I don't understand how evolving world needs huge databases.

Lets take a growing flower for example.
It sprouts in the spring, blooms and pollinates in the summer,
withers in the autumn and hibernates in the winter.

If I were to program that flower, all the client requires are the multiple representations of
the flower in its multiple states, then all that is required is data to tell a flower what state
to be in and display it correctly.
When the player moves away from the flower and goes into another sector, the state of the flower
can be forgotten, since the player is not viewing it anymore. This works with the client only "knowing"
the sectors around the player and not the whole world.

[Greatest]

I don't understand how evolving world needs huge databases.

Lets take a growing flower for example.
It sprouts in the spring, blooms and pollinates in the summer,
withers in the autumn and hibernates in the winter.

If I were to program that flower, all the client requires are the multiple representations of
the flower in its multiple states, then all that is required is data to tell a flower what state
to be in and display it correctly.
When the player moves away from the flower and goes into another sector, the state of the flower
can be forgotten, since the player is not viewing it anymore. This works with the client only "knowing"
the sectors around the player and not the whole world.

and if whats in that sector isn't stored in a database then when the player returns its all blank or redrawn randomly...if something has to be somewhere its stored, storage = databases

with no storage: you build a house walk away and come back and its gone; you play for a while gain a few levels log out your char is gone