Specific requeriments for a TGB game

#1 Amanda Fitch supposedly fixed a lot of issues like this for her TGB game Grimm's Hatchery. I don't think she was able/willing/had time to share what those changes in fact were, either with GarageGames, or the community. But I guess if you are desperate you can try and contact her.

Personally I don't care much about this.. if they can't run my TGB game, chances are a lot of other games also won't run on their PC, and they will hopefully get the hint.. that they need a new graphics card.

#2 @Joe,

Thanks. I guess amanda is busy enough to share those changes with the community. But maybe you're right, I will contact her to see if she can help us -the whole community-.

I'm worried because I'm not the super programmer and I'm dealing with issues that i can't understand. I was running my game in 1.1.3 well, now it is in 1.5 and it is working but sometimes performance is choppy and the game freezes for some seconds.

I sent my game to a game portal and they are interested in see it once finished. But they run in a machine with 2G of RAM, graphics card and a fast processor, and the game crashes (when I test it in my computers and it was not crashing) :(

I'm sure that my game runs in most computers with 512 of RAM and graphics card, but it doesn't run in a 256 MB machine. So I ask why other TGB games runs in 128 RAM machines?

I have lots of questions that maybe some people is having, if somebody has answers to them please let me know where can i read about these topics:

Is there a limit of objects on stage TGB can handle effectively?
a limit of lines in a script?
if you have lots of animations performance is worst instead of if you have only few animations?
if so, where is a tutorial to teach how to unload assets from memory -I've read about unload in the docs, but that doesn't help me-?
Why my game is crashing if there are no code errors -I'm debugging using Torsion-?


Thanks

#3 Actually she turned over all her changes to GarageGames back in July.

forums.indiegamer.com/showpost.php?p=137266&postcount=184

#4 Thanks Stanley,

Where is that source code? Can't find it :(

#5 A lot of this probably comes down to general game optimization. If you are looking at tweaking optimization for CPU usage you can use the profiler (look up on TDN)... as far as memory usage goes a lot of this comes down to general game development. Search the web for optimization techniques and such.

There probably is some things you can do in the code to tweak for your specific game (keep in mind since this is so game specific it's hard for us to do in a general game engine), though a lot of it comes down to your assets, managment of them, their file sizes, etc...

Amanda added software rendering so it would run on machines with weaker video cards, though as far as I know she didn't do much other than that on the rendering side.

We got her code and as she said it would be too quick of a turnaround to put into 1.5. If she reads this, thanks very much. Obviously with her busy with her own games all she could do was send us her entire source code. Unfortunatley it takes time to go through someone elses source code and discern the parts that are relevant and then consider whether it's a general enough solution for us to put in an engine and be responsible for.

Many people make great modifications for their game, but when we do something we have to be very careful.

Quote:Is there a limit of objects on stage TGB can handle effectively?
a limit of lines in a script?
if you have lots of animations performance is worst instead of if you have only few animations?
if so, where is a tutorial to teach how to unload assets from memory -I've read about unload in the docs, but that doesn't help me-?

Test this yourself with your own assets. It's very hard for us to tell you how your game is going to run. It's also hard to just give an object limit since some objects are more complex than others, some are doing much more. Optimization is a very relative process. All I can say is do this yourself. Why not create test cases and record the results (grab memory usage and CPU usage, etc). Not to be harsh (you've done a great job), though this is part of getting a game published, unfortunately it's one of the hardest parts.

Quote:Why my game is crashing if there are no code errors -I'm debugging using Torsion-?

We can't really tell you why your game is crashing with out a -lot- more info. Try running a TGBGame.exe in debug mode, when you compile out a debug build in Visual Studios it will ask you for your project folder main.cs location so you can debug within a compiler. Thats the best way to determine crashing issues.

There's not just one reason an application crashes unfortunately.

#6 Thanks Matthew :)

Now I understand the point.

I have identified the problem that was causing the crash (it was not crashing in 1.1.3. but in 1.5). It has to do with a TGB bug in the handle of onwordlimit calling. I've deleted a non vital function that was spawning some fireflies and now it is working perfect!!!

Thanks

#7 Imstill interested in this issues... i've been tryin to put up a shooter together, most functions are workin as expected and all that, but the memory consuption its WAY TOO HIGH, i mean, my dev machine its an AMD Athlon XP 2000+ with 512 of RAM with an nVidia GFX 5200 w/128 VRAM... but whenever i try to run certain parts of the game (say, load the boss assets) the games EATS UP up to 800MB of ram (you know... starts to swap from virtual memory and all that) and goes all laggy... its really bothersome... so, i was wondering what do you have to do to keep the memory consuptiin to a minimum... i mean, C'MON!, in my test cases im loading just a few assets (i can share them just in case anyone wanna try), but the games goes wild and eats all the systems memory!!! when it shouldnt reallly.

im thinkin its because of some assets size (i've got a few big images... but only a few)... but still, its way too much memory for a couple large sheets.

#8 Hi everyone

I've been away from the forums due to the issues I've openely discussed here. We made large modifications to the script base of TGB, which lead to a massive RAM usage reduction. We also created managers for resources that work realtime. Basically we have a scene manager that given a name and an array of datablocks creates a scenewindow, a scenegraph, loads resources and the t2d files needed. When the scene is deleted, it checks if the resources are still in use and then deletes de datablocks for the resources not in use. We've built the game flow and resource usage around this manager. This assumes you have a well defined flow and datablocks needed and that you have optimized images.

I believe we cannot share the script modifications done to TGB script base, but we can share the managers. The problem now is that we are almost finishing our first game and time doesn't allow that i change all the classes so it fits the common TGB implementation, but with sometime we want to share classes and so on.

Regarding the problem with requirements. After almost a year with TGB I can say that it is not possible to create a complete commercial title if our scripting knowledge is based on the TGB tutorials. We have to script our game with the same dedication and attention we would give to a C++/API/SDK code. If the easiness of TGB leads us to think that we just have to throw some images to the editor and create some classes in the IDE, then we are going straight to disaster, assuming it's not just some levels game, but a commercial game.

#9 I agree with Ricardo.

Only skilled programmer can use TGB as egine for a commercial title. It would be great to add more flexibility to a resource management of the visual level editor (e.g., a separate datablocks management for each level). I have been a lot of work in order to use TGB as I wish (I own the indie license only and I haven't TGB source).

TGB is very nice rendering pipeline (thanks to TGB developers) but its environement need to be adjusted for more usability.

#10 Ricardo that would be really great of you to share with the community. I'd be interested in that code.

I agree on the tutorial issue. There aren't enough of them, and most are outdated. You just have to get your hands dirty, experiment, and always keep the reference open.

#11

Quote:After almost a year with TGB I can say that it is not possible to create a complete commercial title if our scripting knowledge is based on the TGB tutorials.

I agree completely. Though hopefully it's a solid starting point for you and others to launch into learning it. We could probably give people hundreds of tutorials and spend weeks on each and still not cover all they know to need to release a "complete commercial" title. Doing such is just plain not easy, no matter what your tool or tech. You will always run into the same difficulties and work of optimization and such. Obviously there's a lot more we can give in the form of tools and docs to help ease you into this, which hopefully we can in the future. Though if someone picks up any game engine and expects it's documentation to lead them from start to finish with a "complete commercial" title then they are already dooming themselves to be dissapointed. Hopefully in the future we can help address our image so we don't give that impression and instead give the impression of giving you good tools, a good engine, and good docs to help you start on that path. In the end I prefer this than leading people down the road to developing cookie cutter games anyways :) We plan to do better at easing people into it though, I will admit that currently we don't do that well at all, then again it is an amazingly difficult thing that most people dismiss as easy and I still have yet to see an engine to successfully do this to any reasonable point.

#12 @Joe Rossi and others that emailed me

We intend to release all we can to the community. Like I said the problem is time. The managers we created are working together with script changes we did, so I would have document somethings that need changing, for instance, the way the game handles datablocks.cs. It's a tough cookie since I would need to go through the common directory, which we completely erased and recreated.

Please understand that we are really close to give birth to our first baby. :) So we can't spend energy nowhere else at this moment and we can't promisse anything.

@Matthew

I'm sorry if it looked I think the tutorials are not enough. Actually I think they are (or were in the first version I had of TGB) more than enough to get anyone started. My point is blindly following what I learnt from the tutorials would not get the work done. It's difficult to explain it, but the bottom line is that even if you feel comfortable with the tool, be it TGB or any other, you cannot stop your technical evolution there. You have to go beyond the tool and learn more, do more. I'm not criticizing TGB when I say this. I'm criticizing me and my fellow game developers that at a certain point think the tool is bad because they get no results. More than often is more their lack of knowledge than the tool itself. I could babble about this for ours but in our case, when the project was reengineered by a knowledgeable programmer, it suddenly started to grow stronger and better and with what I learnt from him, I did the "delete common directory" thing.

#13 I'm worried about the comments about that only a skilled programmer can use TGB as egine for a commercial title.

What this mean exactly? I've think that TGB will have issues or bugs that will interfere with commercial quality and performance requeriments, but I guess that TGB is powerfull enough to fit that requeriments since I've seen some commercial games at big fish games and other portals.

This means only that docs are not so depth as a beginner will wish? I have been struggling my head and asking for help for lots of functions here, but my game is running as wish, the only problem is the memory compsumption but I guess that at the end lots of people will have powerful machines. Don't know. It's only that confussion will be present when you're working in an ambicious project.

#14

Quote:I'm worried about the comments about that only a skilled programmer can use TGB as egine for a commercial title.

What this mean exactly? I've think that TGB will have issues or bugs that will interfere with commercial quality and performance requeriments, but I guess that TGB is powerfull enough to fit that requeriments since I've seen some commercial games at big fish games and other portals.

I don't think it's a matter of skill programmer or TGB, it's a matter of skilled game developer and the tool he uses. Unlike other software engineering, game development leads to you to gather know-how on several key points outside programming. Asset creation and management is one of those and I bet that most of the problems people are facing regarding memory and performance is lack of knowledge.

I've read somewhere in these forums about an imagem with 7000's x 300's. I don't think that anyone with a bit of experience would use an image that big on a 2D game. I'm sure other solutions would arise that would prevent such an image. Artists have to know about space disk usage, memory usage, programmers about tunning and design patterns. Assume that producer and designer are either artist or programmer on a small team and you'll get the picture of the time and dedication you'll have to give to your own knowledge, not to mention your team's.

Regarding TGB's issues or bugs, they are manageable through that knowledge but all the titles I know about had source engine changes, but I assume some titles haven't. Still it's up to you to get the solutions to manage it with or without source code.

Quote:This means only that docs are not so depth as a beginner will wish? I have been struggling my head and asking for help for lots of functions here, but my game is running as wish, the only problem is the memory compsumption but I guess that at the end lots of people will have powerful machines. Don't know. It's only that confussion will be present when you're working in an ambicious project.

That information is not found in any game engine documentation. The objective of it is to get you started. You'll have to be curious about the engine you work with because whoever did the documentation had no idea of what you want to do with it. You have to wonder how does it do that? Where is it done? Does it fit my needs? If not, how can change it? If you have a memory consumption problem, it's probably because you are loading all your image and sound datablocks at load time. Will this be bad for a customer? Does it fit your needs or your customer needs?

Regarding your game production and development pipeline, there are fantastic books about it, often giving examples in C++ from algorithms to runtime asset management. As long as you understand it and apply the best solution you know to each problem you face, you'll have the best game possible. It is not fair to blame the engine when you use typical recursive algorithms for a puzzle game or non-event driven logic for a game with a massive ammount of entities or you load everything at boot for the casual market. Actually I believe that's the problem with over-ambicious projects: complexity in all production aspects, not the time they take to produce.

If you have a problem with memory consumption, make lists of datablocks you need for each scene. I'm going to "steal" this idea from our game. Something like $DatablocksNeeded [ nameOfScene ] = "train trees deadCat"; Then write a script object (let's call it MySceneManager) that loads and deletes scenes. Instead of using scenegraph.loadlevel or scenewindow.loadlevel, use MySceneManager.loadScene ( nameOfScene ) and it will load datablocks needed, delete the previous datablocks (we check if we still need it so we don't have to load and reload everysingle thing) and then launch the scene.

If it's still huge, check your images. What's the depth? Is it needed? What's the size? Can you scale it? and so on.

Hope this explains my point of view and helps you out with memory consumption.

#15 Thanks Ricardo for the valuable time you have used to this post! I will for sure keep your advice in mind.

#16 Thank you for your post Ricardo,

It's the good explanation of my thought too!

Quote:I'm worried about the comments about that only a skilled programmer can use TGB as egine for a commercial title.

Don't worry to much Isaac. TGB is great instrument to create your games. It is may be more complicated to create a comercial title than it seems at the beginning, but it is possible. I hope I will finish such game in several month.

#17 The truth is that I believe that TGB is the best engine I've used. I'm not a native programmer and I don't know anything about c++ (I never go beyond "hello word"...)

I've tried blitzMax and it seems pretty difficult due to the interface :(

and Flash... not game native.

So... I'm wondering when will a TGB upgrade be out... I mean, if there are some bugs, when they be fixed?

:)

#18 Isaac, there has been recent mention of some type of TGB bug update coming in the future. Every once in awhile you see posts with an employee stating, "that is fixed for our next TGB release." And I have heard something about a FileIO problem being fixed.

I am finding TGB to be really fun and manageable once I get familiar with things. I do find it difficult to sometimes find what I am looking for, but as I learn TGB and get more familiar with TorqueScript, I am actually searching through the class API documentation for some answers, rather than searching the forums.