TGE 1.5.2 Spells without AFX (theory)

#1 Well if your spell is called fireball it kind of implies AOE damage.
So if you raycast it, it pretty much the DnD version of Fire Arrow.

Here is a thought for you, make both the raycast and aoe version of the spell and add into your game the ability to combine 2 spells into one with added mana cost or whatever.

So you could raycast at a specific enemy and it would do nice point damage, but the extra fireball spell on top of it would hit surrounding enemies as well. Maybe even make it a delayed Fireball such as the 'Explosion' spell in Ultima Online...

#2

Quote:Well if your spell is called fireball it kind of implies AOE damage.

Yeah, I agree.

Quote:So if you raycast it, it pretty much the DnD version of Fire Arrow.

Can be a second spell.

Quote:add into your game the ability to combine 2 spells into one with added mana cost or whatever

Nice idea for an advanced spell system. I just need to keep it simple for now.

Quote:So you could raycast at a specific enemy and it would do nice point damage, but the extra fireball spell on top of it would hit surrounding enemies as well.

A 'targetted' fireball spell, maybe. Focused attack on one player, with radius damage to others nearby. Good, but again, more advanced than a 'simple' spell.

I think I need to keep it a simple area effect spell, that appears, say, 10 meters in front of the player?

#3 I would say to go ray cast then, instead of a set 10 meters (or whatever variable you use) in front of the player. It allows more control. Make the raycast is an explosion once it hits its target and does AoE and make sure the player can click on the ground or objects instead of only enemies.. adds more strategy. These opinions are just what I have in mind as a player that would be more enjoyable. It's your game though ;)

#4

Quote:Make the raycast is an explosion once it hits its target

Not sure what you mean. Use the actually raycast to cause the explosion? If so, how? If not, could you explain what you mean?

Thanks!

Tony

#5 First thing that strikes me is you're receiving input on the client, in function toggleSpeelBook(), then telling the server... and all the server does is tell the client what they've just done. Why not just open the GUI when the client pushes the button, instead of having to ask the server to ask the client to open the GUI?

Here's a rule of thumb: handle input and GUI on the client. Handle gameplay-changing events on the server. For example, if one client opens their spellbook, does the server need to know? No, because the game world isn't changed at all. However, if the player shoots a fireball, does the server need to know? Yes, because a game-changing object has been introduced to the simulation.

Here's a basic example of what you might need to do to get a spell system working with a GUI:
On the client:
-The player pushes a button on the keyboard, causing toggleSpeelBook to be called and the spellbook GUI to open, on which there is a 'cast fireball' button
-The player pushes the 'cast fireball' button, which sends a mesage to the server telling it that we just cast a fireball spell
On the server:
-The server creates the spell effect - it may need to do a raycast or AOE check, or create a projectile object.

#6 Thanks Daniel.

So even though the Gui has the "cast fireball" button, toggling the gui does NOT need to involve the server, right?

So my commandToServer is only needed to "cast fireball". The actual fireball spell occurs in the server, which then tells the client where to assign damage?

Thanks again!

Tony

#7 Well, you don't even need to tell the client about damage. Normal game objects are fully synced to the client already - everything the client needs to accurately display and predict the current state of the game is sent to the client. So if you damage an object on the server, the server will send the updated damage total to the client, so that the client's copy of the object also appears damaged.

But other than that, yes.

#8 Thanks Daniel,

So to keep the GUI toggle client-side, is that just push.canvas/pop.canvas?

#9 Yep, have a look at TDN or some existing script files for more detail on how to push and pop GUI dialogs.

#10 OK, so lets see.

Step 1. Create a GUI
TODO: Paste GUI Script here

Step 2. Script the GUI display toggle

$SpBk_State = false;      
     
function toggleSpellBook()
{      
   if ($SpBk_State == false)
   {      
      commandToClient(%client, 'PopSpellBook',%player);
      $SpBk_State = true;      
   } 
   else 
   {      
        Canvas.setContent( PlayGui );      
        $SpBk_State = false;      
   }
}

I used a global variable here because that's how it was done in a resource. Is there a better way? I know you don't recommend globals.

Step 3. Script the keybind

moveMap.bindCmd(keyboard, "ctrl s", "toggleSpellBook();", "");

Step 4. Put a button on it (GuiButtonCtrl?)

TODO: paste script here

Step 5. Script the button to cast the fireball

TODO: paste script here

Question: If I use a raycast, then I have to have a target for the raycast to strike, right? Can a raycast strike terrain? Do I even want the ray to strike terrain? I think I'd rather just have the fireball appear/detonate at a point a random distance in front of the caster. Something like "rnd(3)+10" to put it 11, 12, or 13 meters ahead of the player location. I wouldn't want the player to look down and cast it at his own feet.

More to come...

#11 You've got the right idea, but why are you doing a commandToClient when you're already running the command on the client? (And your %client variable is not set, either.) I don't know if this function even works on the client, and even if it did, it would be redundant. The point of commandToClient is for the server to tell a client that it needs to execute a particular function. If you are the client, all you need to do is execute the function.

Also, a minor error - 'popping' is removing a GUI. 'Pushing' is putting the GUI on top (making it visible).

I don't usually reccomend globals, but that's because people tend to use them inelegantly and in places that will only cause problems in the long run. In this case, it's probably acceptable to store the status of the client's spellbook in a global toggle. However, it's probably not necessary - you can check directly to see whether the spellbook GUI is open, and then turn it on or off based on the result of that check, with no need to store the global variable.

Raycasts simply trace a line between two points, and tell you the first thing hit. Have a look at the function syntax on TDN. If you specify terrain in the type mask, then the ray can collide with terrain; if not, the ray will pass through it.

#12 OK, so what I'm doing is overkill/redundant. I can see that, now.

I'm basing my scripts on an Inventory Pop-up tutorial by Tim Newell.
www.garagegames.com/community/resources/view/1842

I know its old, but it works, but others have also commented to me that the commandToServer is unneccessary for a GUI. That's why I started this thread. To figure out new/better ways of doing this correctly.

Thanks Daniel!

I'll rework my GUI toggle, post it, and if its correct, I'll move on from there.

#13 And again, I'm completely off topic, but here goes...

Why does 'toggleCamera' use a commandToServer? Does the server really need to know that the client is toggling camera view?

function toggleCamera(%val)
{
   if (%val)
      commandToServer('ToggleCamera');
}

OK, back on topic...

Is this more like what I should use to toggle the spellbook on/off?

function showSpellbook()   
{   
    canvas.pushDialog("spellbook");   
}   
  
function hideSpellbook()   
{   
    canvas.popDialog("spellbook");   
}

I can put this in default.binds.cs

//------------------------------------------------------------------------------
// Spellbook
//------------------------------------------------------------------------------

function toggleSpellbook(%val)
{
      if (%val)
      Canvas.pushDialog(SpellbookGUI);//SpellbookGUI.gui
}

moveMap.bind(keyboard, m, toggleSpellbook);

#14 Personally I like Ballistics moreso than ray effects. Especially for very slow moving objects (I imagine its a medium paced fireball, something you can watch fly out).

Only issues I seem with Particle Emitters for projectiles is the you can only have two at a time. Firey orb + [sparks or smoke or flametail].

Raycast would be neat for a non-traversing fireball or such spell. You could cast/channnel the spell on a point, which would then create a delayed explosion from that point. It would be much like 'painting' a target for a modern warfare game. I imagine this is how I would do a meteor spell as well and many other GTAEs (Ground Targetted Area of Effects) with the engine.

#15 I haven't looked at the syntax for pushing/popping dialogs, but that looks more like what you should be doing. Also be aware that the function you've written for default.bind will make the GUI visible when you first hit the button, but will never remove it, so the GUI will remain permanently.

I suspect that in the case of the camera view, cameras are represented by server-side objects. This prevents clients from hacking their cameras to be able to go places the game designers don't want them to. In this case, since the camera is managed on the server, the client has to tell the server that it wants to make a change to the camera object.

#16

Quote:Only issues I seem with Particle Emitters for projectiles is the you can only have two at a time. Firey orb + [sparks or smoke or flametail].

@Aron - I wonder if it's possible to create a double projectile. Two projectiles at the exact same time, but with different particle emitters, so you could 'simulate' 4 emitters total.

@Daniel - I guess I could use a variable in there. It looks like it would have to be a global. Something like...

function toggleSpellbook(%val)   
{   
   if (%val)
      {
         if $isVisible = false
         {
            Canvas.pushDialog(SpellbookGUI);//SpellbookGUI.gui
            $isVisible = true;
         }  
         else
         {
            Canvas.popDialog(SpellbookGUI);
            $isVisible = false;
         }
    }
}

moveMap.bind(keyboard, m, toggleSpellbook);

#17 Looks good!

Aron - I'm not too well acquainted with the particle system, but can't each emitter emit several different particle types? So you could do the smoke and flame for a projectile in the same emitter.