Packaging makes game slower?

#1 @Clint

This reminds me a lot of my game! I've been working on a 4-player, Spacewar kind of game. I actually switched from a dynamically zooming camera to one with zoom levels, because people kept getting disoriented when ships moved too fast and it kept zooming in/out over and over.

I haven't tried to look at why your demo is running slow yet. but if you have a bunch of echo's in there, that could slow things down a large bit. I found AI with echo's really slowed down my game. I also found out that a lot of schedule mismanagement can make for some big slowdowns.

I took a look at your AI. It seems a little more simple/practical than the one I tried out. I'll have to poke through it some more later and see if there are some things for me to learn from it. AI is definitely an important piece of my game that's lagging. :)

#2 Hey Chris!

Thanks so much for downloading my game and giving it a look. :) If you happen to run it, I'm interested in knowing if the packaged version runs any slower on your machine than the source code version.

You may be interested to know that I just got a new version of the AI done last night -- I've improved their tracking ability and they can now accurately "lead" their targets most of the time. I also implemented damage and teams, so now the ships all swarm and can do team-based combat against each other autonomously. I put myself on the team with the disadvantage, and it's actually a really fun fight to try and beat the other team. :)

It's always really nice when the game you're writing starts actually getting to be fun to play. :)

Regarding the zooming camera -- yeah, it is a bit disorienting. I think a star background would help with that, and I also want to give smooth panning/accelleration to the camera movement. You're right -- it is too disorienting at the moment.

Thanks a lot for your reply! :) I look forward to seeing your game as well. :)

I've got sortof-plans for turning this game into a demo for a semi-realtime multiplayer cooperative space-combat game. Have you given any consideration in your architecture about making it network multiplayer?

The biggest hurdle in me making this game networked multiplayer is that one can't currently run two copies of TGB at the same time on the same machine. :-\

Cheers!

--clint

#3 @Clint: Since you have TGB Pro you can compile out a DEBUG build of the engine, you can then run the regular "Release" build to start the server and then a DEBUG build to connect to it. You just cannot run two Release builds on the same machine at the same time :)

#4 Hah, that's a pretty good trick, Matt. :) I'll have to try that. Last I checked I was having compile issues with TGB, but now this gives me some motivation to get it rolling again. :)

Thanks!

--clint

#5 @Clint

I'd definitely be interested to see what you come up with. Perhaps we'd be able to mutually benefit each other by sharing our findings. :) Plus, I always like to see what other people do with similar concepts to what I'm working on. I think it ends up making all parties do a better job.

I only ran the packaged version of your game, and it sure enough ran pretty choppy. It was still playable, just not super smooth.

If you managed to get a good enough network multiplayer, I'd be really interested in seeing how you did it. Right now, I've pretty much canceled any plans to put networking in my project. I'm trying to get a complete game done first. I'm the lone programmer/planner. I've got a couple gals that do level art for me time to time, and a guy who I've had do music for me before. So we're a small group. It's a crunch for me to try and complete a game on my own in my spare time! :)

#6 Not that this has anything to do with frame rate, but I tried playing you're game, I love the Ai, physics, camera, all of that stuff. I just felt like it took way to long for the player to turn around and that made the game a little bit frustrating. But I think if you sped up the turn speed you'd have something really fun on your hands.

#7 @Chris

Okay, great! :) I'm not sure if I'm going to get network multiplayer done, but I've been trying to at least keep some amount of provision for that as I lay out the data structure. I'm not building the functionality in yet, but trying to make it so that I won't have to refactor too much.

@Sam

Thanks so much for the feedback! Wow -- that's really encouraging! :) I think I'll implement that -- great suggestion.

Cheers!

--clint

#8 Just thought I'd chime in and report that I'm getting slower speeds on my packaged build as well. My game is based off of the MiniPlatformerTutorial, and I'm running TGB 1.1.2 on a Macbook.

Edit: With 2GB of RAM and a 2GHz Core Duo.

#9 Hey Walter -- thanks for the update!

It's mixed good and bad to hear that other people are getting the same symptoms that I am -- it's nice to have confirmation that I'm not crazy in imagining this thing, but it's also sad because then it's more likely to affect more people.

It's also interesting to hear that you're running on a Mac -- I'm using TGB 1.1.2 on Windows XP Pro on a 1.70 Ghz Pentium M with 1 gig of ram.

I'm interested in knowing if anyone else has seen a similar problem with their games.

Cheers!

--clint

#10 @Clint, Walter

Hey guys, sorry for the temporary edit, seems I jumped the gun a bit when posting. This is infact not a 'bug' but rather a side-effect of using the levelbuilder in conjunction with the way your game scripts are written. It has nothing to do with framerates, but rather with how you are simulating the physics.

You are implementing t2dSceneGraph::onUpdateScene to advance your physics and as it turns out the levelbuilder has multiple scenegraphs that it uses for various things such as the create panel and the editing scenegraph. So when you implement t2dSceneGraph::onUpdateScene instead of a named scenegraph it will be called many more times than it needs be in the levelbuilder. This of course goes away when you package the game since the level builder scenegraph is no longer present.

The Proper Way to use onUpdateScene
It is highly discouraged to implement a function on an actual class name if it's not absolutely necessary. Rather it would be better to give your SceneGraph a name such as 'AirLockedSceneGraph' and then implementing your update function like below.

function AirLockedSceneGraph::onUpdateScene( %this )
{
   // Do Stuff here.
}

Changing your code to look like this should fix the problems that you're seeing in your game (It does, I tested your game over here) -- Looks cool!

Thanks for bringing this up, and as a side point, what could we have done better to let you know about this when you were getting started using TGB? Did you find an example of ours that implemented it in this fashion?

Best Regards,
-Justin

#11 Hey Justin!

Quote:Did you find an example of ours that implemented it in this fashion?

Yes -- I read it in one of the tutorials, but I suppose it wasn't an official GG tutorial so much as it's one of the primary community-developed tutorials on TDN. It was one of the first tutorials that I read that really got me off the ground with using TGB. Mini Platformer Tutorial. In it, all of the methods for the scene graph are done with class-specific identifiers. It tells the user to do things like:

function t2dSceneGraph::onUpdateScene()
{
     if (isObject($pGuy))
          $pGuy.updateMovement();
}

That "if (isObject($pGuy))" line was actually a fix that I added in there to prevent log files from filling up when I was in design mode. It seems that having a named scene graph would indeed be the proper fix for that problem too. Is it possible to name the scene graph through the designer? Or do you have to do that in code? (Edit: I now see where it is possible to name in the designer -- thanks!)

I actually hadn't ever heard that you could use an instance name instead of a class name -- that's really incredibly handy! I've used a lot of programming languages, and I've never seen that sort of thing done.

So anyways, because both Walter and I had code based on the MiniPlatformerTutorial, we both used that same t2dSceneGraph::onUpdateScene() technique.

I really appreciate you taking the time to dig through this and figure out my problem (as well as the feedback about the game itself)!

You guys do amazing work over there at GG -- I'm a big proponent of free and open-source software (I use it whenever I can), but every dollar of mine that's gone into the Garage Games store is well spent for service like this.

You and you work is very appreciated! :) (that applies in both the singular and plural senses of the word "you")

Respectfully,
clint

#12 Yup, thanks for the info, Justin!

I guess one question I have is, how do you reference things through their instance name in the script? I've given things both a class name and instance name, but referencing things through the instance name never seems to work. If I want to reference something specific, I've just got to give it a unique class name, and then assign it to a global variable in the script.

#13 Justin, you're amazing! :) That fixed the problem. :) Here's a new screenshot:

along with an updated binary and source. The source isn't cleaned up very well yet, but the AI has been drastically improved to use trig in calculating the correct angles to properly lead their targets. It makes things much more challenging! To even things up a bit, I gave the player 3 yellow teammates, pitted against 4 red enemies. See if you can keep your team's score ahead of the enemy's! I know I had a hard time with it, and I don't think I ever managed to build a lead of more than 2 or 3 points. :)

Anyone can feel free to use whatever they like from the source or game (including graphics). I'm still leaning towards polishing this up more into a fun little game and opening it up as a multiplayer game example project that people can learn from and contribute to.

Cheers!

--clint

#14

Quote:how do you reference things through their instance name in the script?

This question should probably be in its own thread, but I'll take a stab anyway ;)

All you have to do is put the name of the object instead of an ObjectID (without % or $, maybe that's your mistake). For instance, if I have an object named "bob", then I could write:

bob.setPosition("0 0");

Edit: Also, I added a note to onUpdateScene in the TGB Reference doc that should prevent and help people with this problem in the future.

#15 Ahhh. That is a *huge* help. Thanks, Tom.

#16 @Clint

I looked over your new AI. I have to say I found it useful! I tweaked my AI based on a few observations I made looking at yours. The adjustments made it a much better AI. :)

I'd love to package my game and put a demo up for people to try out, but it's only successfully built once and that time it crashed when I tried running it. :(

#17 @Clint Herron: Glad to see the tutorial helped you get off the ground, and I'm sorry about the problem. I noticed it myself and had no luck diagnosing the problem. I built TGB from source and tried to debug it to no avail so I'm glad we got this sorted out. I'll go update the tutorial if no one has already.

#18 Hey Dan,

No worries about the problem! I'm glad that we've all learned Torque better through this, and your tutorial was the best one to really pick me up off the ground and show me how to work well within Torque. Thanks for your amazing work! :)

--clint