Would I use separate scripts to define gameplay modes?
by Jon Lorber · in Torque Game Builder · 09/01/2009 (11:43 pm) · 3 replies
I'm working on a game with three different gameplay modes. My thought was to have a different script for each mode (as they have different rules for on screen objects.)
What I'm not sure of is that these game mode scripts are not actually objects in the level and when I try to call functions in them they're not found. The scripts are exec'd from within game.cs properly and produce no errors.
Is this approach correct or am I should I build all logic into game.cs instead? I could imagine a "switch" command that detects the mode and affects it accordingly but this seems like a bad way of doing it.
What I'm not sure of is that these game mode scripts are not actually objects in the level and when I try to call functions in them they're not found. The scripts are exec'd from within game.cs properly and produce no errors.
Is this approach correct or am I should I build all logic into game.cs instead? I could imagine a "switch" command that detects the mode and affects it accordingly but this seems like a bad way of doing it.
About the author
#2
As for your first question, I think it would be really awkward to use objects for gamePlayMode states. You could do it but it wouldn't be very intuitive and you'd be better off just storing the gamePlayMode in a variable that's either global or you pass to functions that act differently depending on the game play mode.
09/02/2009 (3:04 pm)
The first code snippet is defining the global function "InitGame" and the second is defining the member function called "InitGame()" of the "GamePlayModeOne" class. If you were going to use the first, you'd go InitGame() from anywhere in your code but if you want to use the second, you'd go MyObjectNameHere.InitGame() where MyObjectNameHere is a object of the type GamePlayModeOne.As for your first question, I think it would be really awkward to use objects for gamePlayMode states. You could do it but it wouldn't be very intuitive and you'd be better off just storing the gamePlayMode in a variable that's either global or you pass to functions that act differently depending on the game play mode.
#3
For example I have a core class called DefaultGame which has a bunch of barebones methods useful for all types of game -- this package is always active. Then when a Deathmatch level is loaded it activates a DMGame package that contains all the necessary overrides or functional differences of the DefaultGame, and through the use of function fallback (Parent::) I can reuse those functions already defined without having to duplicate existing functionality for each game type/mode.
It's simple (to my mind), flexible, and it works great.
09/02/2009 (3:34 pm)
I do something similar in the 3d engines by using a script object to encapsulate my gameplay modes by giving them a namespace, and then use package functionality to work within XX namespace depending on what level/mission is loaded. For example I have a core class called DefaultGame which has a bunch of barebones methods useful for all types of game -- this package is always active. Then when a Deathmatch level is loaded it activates a DMGame package that contains all the necessary overrides or functional differences of the DefaultGame, and through the use of function fallback (Parent::) I can reuse those functions already defined without having to duplicate existing functionality for each game type/mode.
It's simple (to my mind), flexible, and it works great.
Torque Owner Jon Lorber
function InitGame() { //do something }and
function GamePlayModeOne::InitGame() { //do something }