Game Development Community

unusual needs

by Xemame · in General Discussion · 11/15/2010 (4:31 pm) · 10 replies

Hello,

My society is considering using your engine to make games on an interactive table.

However, we have unusual needs and we like to know if Torque3D can fulfil them: We want to make little games, each one lasting for 5 minutes. The difficult part is that we want to be able to make a new game, to save it somewhere and then to play it with the engine, without rebuilding everything. Is there a way to do this with Torque3D?
For example, with our former engine, we saved each game in a dll. Each game had handles Update and Draw that the engine was using to run and display them.

We also need an other thing: At the end of a game, the next one begins in the same window and is played. At its end, a third one is played, and so on. So the engine must be able to load several games, one after one.

The last need: when a game ends and the next one begins, there is a transition between them. For example, as in this picture, http://img571.imageshack.us/img571/6263/transitionfinal.png , [IMG]http://img571.imageshack.us/img571/6263/transitionfinal.png[/IMG] , the former one goes as the new one comes. An another example: the former game become more and more transparent, as the next one, transparent at the beginning, becomes more and more opaque.

Can you tell if what is possible?
Can you give me links or information about the way to do this?

Thanks a lot!

About the author

Recent Threads

  • C++ plug-in

  • #1
    11/15/2010 (5:53 pm)
    If I understand you correctly then yes, you can do this with Torque. In principle this sounds like the gametype mechanic in the stock Template and FPS Example. Each individual game would be controlled through the script package system. Think of packages as a means of overriding a default set of scripts.

    I would create each differing game as a level and give it, the level (.mis) file, a unique "gametype" property in the level info object. Then when a level is loaded, this propery, if present will be used to tell the game what script package to execute.

    The only problem that I see offhand would be the desired transition element since if each "game" is treated as a level scene there would be a pause (and a level loading gui) as the next "game" is loaded.
    #2
    11/15/2010 (7:27 pm)
    Michael is spot on with his suggestions.

    It is possible that you could take a screenshot of the final state, perform the transition with a GUI to the default start-state of the new game.
    #3
    11/16/2010 (7:12 am)
    And you can of course hide the "loading level" gui.
    #4
    11/16/2010 (4:18 pm)
    Thanks for your replies!!!

    So it is possible to save games in .mis files and to make the engine load them one after the other, but a graphical transition as shown in [IMG]http://img571.imageshack.us/img571/6263/transitionfinal.png[/IMG] is not possible because only one level can be loaded at a time?

    We also have an other need (yes, again): we want to make new objects, to save them (for example in a file) and to be able to make a game by reading the files and adding them, without rebuilding everything.
    For example, each object is an animal and is saved in a file. At the beginning of the game, the engine reads a text file with "use 2 cows and 1 dog", so it loads the files of the cow and the dog and adds these animals in the current game.
    Meanwhile, we implement the dog and save it in its file. Then, the engine can add a dog in the game, reading the dog file, while it has not been rebuild and has never seen a dog.

    Is it a way to do something like this?
    #5
    11/16/2010 (7:59 pm)
    Yes it can.

    It can dynamically add object in the game, even during a session.

    The part I'm not sure is : can it import new media during a session (or should all media that can be used be present in sandbox at startup ?).
    #6
    11/16/2010 (8:05 pm)
    Any resource can be loaded at any time into the game, you have complete control over what's loaded at startup and what is loaded later on.

    Best of all, you can have your resources automatically update in the game as soon as the file is overwritten with a new version.
    #7
    11/17/2010 (9:59 am)
    thanks for your replies, but I am not sure we speak about the same thing, so I explain again what we need:

    With Torque, I could make a new animal, let say a dolphin, implement its behavior, save it in a file, put it on a machine with the program to play my games, launch the program with a config file containing "use two dophins", and (tadaaaah), there would two dolphin in my game ???
    The file containing the behavior would not give only parameters (ex: its size is ..., it is shinny, it collides, etc) but code, to allow new behaviors not implemented before. For example, the dolphin swims and there are no parameters IsSwimming, so I put in the code that the dolphin cannot go out of the water.
    The file can be used by the program while the program have not been rebuild in order to be able to use the dolphin.

    This is just an example to show that our needs are to be able to have objects with special behavior saved in their own files, to use them in the engine and to make new objects without rebuilding the engine, instead of putting every objects in the engine.

    Do you know what is possible to do?
    Thanks!!!
    #8
    11/17/2010 (2:36 pm)
    What you are describing is not that unusual. With this engine, anything is possible, given the proper knowledge.
    Quote:
    The file containing the behavior would not give only parameters (ex: its size is ..., it is shinny, it collides, etc) but code, to allow new behaviors not implemented before. For example, the dolphin swims and there are no parameters IsSwimming, so I put in the code that the dolphin cannot go out of the water.
    The file can be used by the program while the program have not been rebuild in order to be able to use the dolphin.
    The properties of the dolphin would reside in a Torque structure called a datablock. Controlling it's behaviour and restricting it to only water can be done through Torque script and can easily be done - no engine-side modification or compiling needed.

    Quote:
    With Torque, I could make a new animal, let say a dolphin, implement its behavior, save it in a file, put it on a machine with the program to play my games, launch the program with a config file containing "use two dophins", and (tadaaaah), there would two dolphin in my game ???
    Yes.
    • make a new animal, let say a dolphin = .dts shape
    • implement its behavior, save it in a file = datablock + scripts
    • launch the program with a config file containing "use two dophins", and (tadaaaah), there would two dolphin in my game = .mis file, the level file.
    And back to the game/gui transition: that is only a hurdle in that a stock example of what you describe doesn't exist. Torque by default uses a load a level, complete the level, and then load the next level methodology. Each and every level can have a controlling script attached to it through the script package. Can this process be altered by you for the needs of your game? Yes.
    #9
    11/17/2010 (9:06 pm)
    Quote:For example, the dolphin swims and there are no parameters IsSwimming, so I put in the code that the dolphin cannot go out of the water.
    The catch is that some things are just done better in C++ than in scripts. Most of the script functionality deals with callbacks - i.e., responding to events instantaneously, rather than determining the millisecond-to-millisecond behaviour and movement of an object.

    Quote:restricting it to only water can be done through Torque script and can easily be done
    Just out of curiosity, how would you do it? I can't think of any simple way off the top of my head, though I'll readily confess that I don't think well in script - it usually takes some effort on my part to get into that particular gear ;P.

    Anyway, that said, you can easily make it possible by changing the source code first to give you greater freedom in scripts. For example, I know of at least one person who moved the Player's movement update code into script, allowing them much greater freedom when prototyping new movement ideas. If you were to do the same thing, you could override the method for any different object class you liked.
    #10
    11/20/2010 (4:06 pm)
    Daniel is correct in pointing out that some things are better if done in C++ rather than script.

    @Daniel: possible ideas for restricting movement to water only:
    • Make use of the shapebase onEnterLiquid() and onExitLiquid() callbacks. Upon the onExit event simply take the player's current velocity and direction for travel and impulse them in the opposite vector. Would work better for a player, but could tell a scheduled AI think routine to seek a new route if it triggers the onExit callback X amount of times in a given time slice so that it doesn't constantly bob back and forth. Wouldn't be too much trouble to trigger an out-of-water-so-lets-flop-around animation as well as have the player's movement speed automatically reduced if out of water - give them a breath timer and they would eventually die
    • Use triggers or physical zones to restrict movement.
    • For AI I would probably use a recurring forward raycast check and if dryland/air is imminent simply steer in a different direction.
    But of course I would use script to rapidly test out these ideas, and then incorporate the mechanics into a game in C++ code with script controllable properties for ease of adjustment.