03 Apr, 2014, quixadhal wrote in the 61st comment:
call_out() is just scheduling a function to be called (by the driver) in a given LPC object, at a given future time.
So, if you have a function that updates some values, and you want it to run every 5 minutes, you could have the create() function schedule a call_out("update_foo", 300); If you don't specify an object, it assumes the object the call_out() routine is called from. Let's say the object in question was /daemon/magic_d.c
So, 5 minutes (or slightly more) later, the driver calls "/daemon/magic_d.c"->update_foo(). It does whatever it's coded to do, and may well re-schedule itself to be called again in another 5 minutes.
heart_beat() is called a "driver apply", and like the create() function, it can exist in any LPC object. When you make an object, you can call the driver function set_living(1) to enable heat_beat processing on it. If you do, every 2 seconds (or whatever the driver is set to use), it will call the heart_beat() function in your object.
Personally, I dislike using them because you end up writing overly complicated code that has to deal with what to do in THIS iteration vs. THAT iteration. But in the old days, heart_beat was FAR more efficient, and was the only way you could keep a dozen players all fighting in combat without noticeable lag. Like many things, that may no longer be true.
The magnitude is the range at which the caster interacts with the anode, right?
Yes. Here's an example of how it might work (with the likely flawed formulas in my earlier post).
Let's suppose one the first offensive spells one can learn is magic missile. Magic missile costs 2 fatigue points and requires 10 power points. The caster is in immediate range of an anode that currently holds 100 power points. The caster casts the spell which costs him 1 fatigue point (1/2X effort) and takes 10 points from the anode. He then moves around to where he is at medium range from the anode which now contains 90 power points. The caster casts the spell again which costs him 4 fatigue points and takes 10 points from the anode (only 1/2 power or 45 available points at that distance). He then moves around to where he is at distant range from the anode which now contains 80 power points. If the caster tries to cast the spell again, it would cost 32 fatigue points (16X effort). However, from an 80 point anode at a distant range, one could only draw 1/256 of the power, or 80/256 = 1 (rounding up). One point is not enough to power the spell, even if he could pay the fatigue cost.
Well, my idea for making it central would be to make everyone a mage of sorts… thieves are stealth mages (using magic to enhance their sneaking skills, turn invisible, or teleport/phase through wall), fighters are melee mages (possibly using magic to enhance their strength and durability), clerics are healing mages… etc. So all classes are in some way dependent on this system.
There is already a potential point in common, the notion that actions have a cost, fatigue. Casting a spell costs fatigue points. And so might other actions like regular movement, climbing, swimming, etc. And so would physical combat too. Every round/turn a character is in combat, they would burn fatigue points. You could assign fatigue costs to the use of combat skills and special combat moves. For example if you are using a "second attack" skill, it costs a specific number of fatigue points. If you have a difficult (high level) combat moves, like "walk up a wall and back flip over and behind your opponent like Xena warrior princess", it has a much higher cost. I would imagine a number of thief-type actions could also be expressed in fatigue costs.
DikuMud had hp, mana and move. Move was really a specialized fatigue that only applied to movement. Since "mana" is something in the environment, you end up with something like "health and fatigue".
Methinks the "game" of designing a game would be more fun, if you'd pick the most unlikely, surprising or interesting design choices.
Telnet, websockets, vnums, areas, exits, network, database… What's that got to do with the game?
What about wizards? How does magic work? Where do wizards get their power? How do they cast spells? Where do they learn them?
An alternative idea is to focus on the Next Minimal Step and actually build a reference implementation as we go. That'll force us to not stray too far from pragmatic reality or worry about being perfect on the first try.
At least, this is the aspect that I'm most interested in since I otherwise worry that progress will be stifled by endless design bike-shedding. After all, grandiose ideas aren't so fun anymore when you have to start bringing code and complexity to the table.
I would love to start building something, but I'd like some help with the wire protocol. Could we cover that?
I like the idea (brought up on Page 1) of exchanging structured JSON between the client and server. I think it'd be easiest to start with structured data over telnet.