New feature wish list.

#1 1. I think the game save feature would be relatively easy. You just save all the sim objects associated with the mission to a file. You could reload that instead of loading a mission and it should reload the mission. A while back I did something similar to this with the mysql resource. I saved aiplayer objects to the database and reloaded them on mission reload. They even were facing the exact same direction as they were when I saved the mission, some look angle and everything. So I think it would be possible with the rest of the objects. You might have to do it in phases or something so you don't get players spawned before the terrain gets spawned. So it may need to be a hierarchical save.

2. Multi level is just multiple missions.

What do I want?
1. Better/more docs on the "source code". Like building a game from scratch example without using most of the T3D code. Start with gamebase. BTW GG, the docs are way better than TGE days in my opinion and so is the code base. Thanks for that! That is it.
2. Okay, maybe I want the plugin that writes the game just how my brain imagines it and debugs and tests it before I touch the computer...that would be nice.

#2 Working on 2, 1 is a little farther out....

I had half of that working at one point - using triggers to port between different mission files and land you at particular spawn points based on which trigger you entered. I made a "hub" mission with exits to three other mission files. All I had left was serializing my objects out to files or a database.

It'd be a little more work, but you could set up objects that would be saved to a separate file when the mission is saved from the editor so your NPC's, monsters, other dynamic entities would be tracked in a separate file from the static level objects. Then, you load the mission file and then load the dynamic object file - nobody falls to their doom that way.

Even more work would be to build serialization into the objects at the engine level, but probably better on a few different counts than the script method.

I need to sit down with a pen and paper and think about this one anyway - dinking with a project that will need this.

#3 I could have sworn serialization was working in TGE. I had a script that would dynamically generate the mission file and launch it. Maybe that is different from the current values being saved after it has been running a while.

#4 I meant setting up the objects so that they had a member to dump their current state information to a stream and read the data back during a factory-based creation process, to include dynamic field data. Seems like it might get a little weird crossing the VM line to get or set the dynamic data, but it is probably not as complicated as I think it is.

It would probably be easier to save it all out as a separate "mission" file that only stores volatile objects (i.e. NPC's) via script. Then we could just ensure that all of our moving parts are added to a specific SimGroup and dump everything in it on save. Then just load that file back and re-create all of those objects in our save SimGroup.

I'm pretty sure a few different serialization approaches were implemented by various people for TGE. The dynamically generated mission files sound pretty interesting - did they use random terrain data as well? Or just dynamically populate the mission with NPC's?

#5 All I can say is I'm new to trying to do Torque scripting, and I'm not a C programmer so editing source code for torque isn't for me.

All I want to do is this:

1. player pushes a button or gets a key-card on 1st "level or mission file"
then on level say 6 he needs it to open door to get say a FUSE to put
in computer on level 1, to power up complex.

2. Play is tired of playing game or reaches save point, so everything is
saved to a game save for that player, so he/she can start were they
left off before quitting.


This should already be built into Torque, why be able to make multiple levels for a game if you can't get to them?

I'm stupid I'm not a torque script guru, just a normal guy tiring to make a simple game.....

#6 This may come off as sounding condescending but its not, I get that a lot, whatever people tell you, they lie when they say the appreciate honesty particularly when such honesty might be directed at them :p

1) moving from one zone/mission/level to the next is relatively easy, documented in several places around here.

2) You will undoubtedly get a whole bunch of 'makemygame button' comments from others, you will need to ignore their attitude but understand their message. As a game developer you need to understand that not every conceivable game element is in a game engine, nor should it be, that is up to the game developer to work on. This is one of those things.

I'm going to reference your final comment, and simply say that, if you want to make your own game and on your own you need to learn stuff; art, code, script heck even the lingo, if you want to make a game without learning anything, then something like the FPS Creator (google it if you've not heard of it).

#7 I'm not sure FPS Creator does this out of the box either - you'd still have to script it.

I'm going to be working this out myself for a personal project shortly, so I'll be able to share it as a resource when I'm done. I'll probably add it to the documentation after that - it has to pass QA before it gets to go into the docs.

Along with this you'd need to have some sort of system in place for handling your save files. For instance, do you want to allow the player to simply save at will or are you using savepoints? If you're using savepoints, do you want to keep a list of the 10 most recent or do you simply want to just keep the last save? Is it a single player game? If not, things get a LOT more complex because the engine only supports one active mission at a time. This raises issues of what to do if two players want to be in two different levels at the same time. I have some thoughts on that last one, but you'd have to tweak the engine source.

Mission cycling IS in the engine, but it's very bare-bones and doesn't save any information to carry between missions because the base example scripts cover a basic deathmatch game. There is no need for persistent information to carry from mission to mission in this type of game.

Anyway - a little patience and I'll have something put together. I'll share it when it's working. I have to do some learning myself for the save file part, especially if I want to keep it all script-side.

#8 Save-now/load-later is actually pretty simple, but hard to define generically for all of the visions of what people around here have of what a game is. There is actually a Resource that can get you started for this.

Persistent or stored inventory can be done many different ways, none of them all that difficult.

Multiple levels with spawn points and triggers between them is something I've detailed/described how to do several times. You just got to make sure that a new parameter is added/passed/used in a few script methods.

#9 Check out the stock save functions in the scripts to see how it's done, you'd just need to save it to a new folder. As long as everything in-game is added to the MissionGroup simgroup it'll be in the .mis file.

As for loading, check out how mission selection is done in stock scripts.

And as for making buttons and gui's in general, read up on the Gui Editor in documentation.

#10 After a cursory spelunking session in the docs it looks like all SimObjects are flagged as canSave by default. Additionally, a save() method is built into SimObject so it should be as simple as putting all of your moving parts into a simset or simgroup and then just iterating through them and telling them to save themselves to the specified file. If you attach your player's inventory to them via a dynamic field you'll get the bonus effect of having it save itself, too.

Yeah, Michael - I set a global to save the name of the spawnpoint I wanted to target in the trigger, then looked for it when spawning the player in the new mission file. I did a fallback to the default spawn point if the desired one didn't exist. It was pretty simple, but I was stumped until I realized I needed to schedule the mission cycle with about a 250ms delay - it was hanging my game otherwise.

And I completely agree - RIF! (Reading Is Fundamental, for those who weren't born early enough or in the right place to have been exposed to that ad campaign) The documentation is there - it needs work, but it's there....

Update
More spelunking and a little dry run turned up this little tidbit - SimObject.save() spits out this:

//--- OBJECT WRITE BEGIN ---
new Trigger(CTDay) {
   polyhedron = "-0.5000000 0.5000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 -1.0000000 0.0000000 0.0000000 0.0000000 1.0000000";
   dataBlock = "transitionTrigger";
   position = "25.655 2.56151 0.798635";
   rotation = "1 0 0 0";
   scale = "1 1.36444 2.8148";
   canSave = "1";
   canSaveDynamicFields = "1";
      mission = "levels\ChinaTown_Day.mis";
      target = "CTDay";
};
//--- OBJECT WRITE END ---

So loading it back in should be pretty easy. Armed with this it's all just figuring out a good algorithm for saving and loading what you want.

#11 I think my last post must have sounded?? (mad, stupid?, like I am lazy?)
I'v been working on computer for 28 years, programming that long too.
I have over $400 in books on Torque (TGE & T3D), not to sound a$$y, I'm just want to say I do Read, a lot, Print out code to understand stuff.
I also remember RIF, lol. I'm 40, and this is something to play with, and I hope my question help others find information too.

I know ppl just want the answers given to them, don't do any work.
I guess I'll just go read and not bother anyone else.

Thanks 4 the help!

#12 Saving a mission in progress is pretty simple. Most dynamic objects like Projectiles are added to MissionCleanup when they are created, so calling MissionCleanup.save() will give you the TorqueScript needed to recreate all your dynamic objects, as Richard demonstrated above.

However, the save() method is inadequate when it comes to describing things like mounted objects and images. All that is output into the saved file are the console members defined in initPersistFields, as far as I remember. If you script everything like inventory systems, saving the datablocks of currently stored and mounted items, then you should be able to us the onAdd callback to reconstruct your objects the way they were, more or less.

A while ago I tried to make SceneObject a subclass of SimGroup (well, share its abstract interface, at least), so that you could use the hierarchical saving method to write out mounted objects in a sensible manner. It turned out to be difficult to integrate with the editor, though, and I abandoned the work because it was taking too long - and still wouldn't solve problems with objects like Triggers that need to store object handles (or any sort of SimSet, for that matter).

#13 Multiple inheritance? That should conglomerate the features of the two parent classes, but I'd only be guessing as to how many ambiguous functions there are.

#14 The problem is that SimSet is a SimObject, and diamond inheritance is no fun. What I actually did was just create an abstract class called SimSetInterface and made SimSet inherit from this class and SimObject, then made ShapeBase inherit from this abstract class as well. I only implemented a few of its methods with any substance, just the ones used in object creation - which redirected to the mounting system. Then I set about the lengthy process of making the engine recognise the new interface class instead of defaulting to SimGroup. At the end of it all, the tree inspector GUI class didn't want to behave properly, so I scrapped the changes. It'd be a really nice feature (and allow mounting objects to each other in the world editor, by dragging them onto each other in the scene tree), but it's not critical.

But I think I'm pulling us off-topic here... bottom line is, it'd be really nice to have some form of quicksave/load built into the engine. I think a blanket state save/serialization method is something pretty much any game could use, unless your focus is multiplayer-only. If you leveraged packUpdate and its siblings you could get access to a lot more of the internal class data than you do with save().

#15 Now, you understand why this is a Wish List item for me! LOL.
Even you guys see the difficulty in implementing this function.

I guess if you went threw and Named everything instead of the default
name random number assignment. If I'm not mistaken, changes every
time the mission is loaded?

It would be easier to save out the state of something if you knew the name of it, (and it doesn't change every time you load the mission).

A database that holds the information of CANSAVE = TRUE items in the mission, and a list of variables from the item.

Items could easily be referred from the file in any mission.
Then things like button, switches, triggers, cars, etc could be easily
read & updated, this would mean building in database handling in torque, if it doesn't already have it???

I guess the big problem would be saving variables in the file. How to address all the variables that you want to be saved, some how you would have to mark them as a savable? I can't at this time think of how to address this issue....

Just something to think about...

Mike

#16 Hang on. Just hold it right there! How do MMOs and the MMO kit/s handle this? I mean, in a persistent world with multiple players logging on, playing and then logging out again, the server's got to have a huge stream of x, y and z updates as well as inventory items etc.. Why can it happen in an MMO and not be implemented in any sp game project? Or am I missing something incredibly obvious as usual?

#17 The issue is not so much that its difficult, the difficulty lies in adding it to a game 'engine' as a feature, it could be done i'm pretty sure ridiculously easy, by just saving *every* item of information and state change. In reality, what you want is a fast saving of your game specific information.

As for persistent worlds, they are constantly saving so its slightly different as they are designed from the ground up with a live database system to back up the persistence.

#18 @Michael,
I apologize if it sounded like I was poking fun. I was not. I really like wish list stuff and it is fun to conjecture the impossible to get a smile. Apparently it had the opposite effect.

@Richard,
I used prebuilt terrain data. Part of my next step was to generate terrain and assign texture data based upon elevation and region rules. I am not to that point with T3D yet, but I would love to generate roads using the new widgets dynamically. That is something that really interests me and using the cool new T3D widgets should be fun.

#19 Ok, so - if we upgraded the save() method in SimObject to check for mounted objects and save them properly it shouldn't affect anything else the way I see it. It should still function as it does now as far as everything in the engine is concerned, but when you use the save method it would look for mounted objects and walk the set for you. Sound right?

Then it is up to the end user to set the canSave flag to false for things he doesn't want saved (since it's true by default). This would let us decide at design time what sorts of things we would want to save.

#20 @Richard,
When it saves a mounted object what would it look like in the save? When you restore the save objects get created in the correct order and get mounted in the correct order? It seems like there might be some functions that get saved with it as well.