Many n00bs say "oh, i need higher limits" for games that never materialise, but QFG2's stats were postted by Erpy on the agdi forums the other day:
Quote
Total sprites: 12859/30000
Sprite folders: 163/500
Total views: 428/600
Total GUI's: 50/50
GUI buttons: 226
GUI labels: 156
GUI sliders: 9
GUI textboxes: 13
GUI listboxes: 6
Inventory items: 103/300
Characters: 119/300
Dialog topics: 376/500
Dialog messages: 924/3000
The only two things I find a little bothersome is the GUI limit, as I've had to manipulate several GUIs for completely different needs, and the views limit. The views limit is annoying but easier to overcome, and is rarely to cause conflict. 500 views total in 2.72 ain't it?
But nearly 13000 sprites? JC... I'm a little over 3000 sprites deep and I have trouble navigating the sprite manager...
wow. thats weird. the only limit i am anoyed about is the one for the controls on a gui. and the gui numbers. thats a pain.
These limits are of course mainly gone in AGS 3.0+, you know...
30 controls per GUI and 40 objects per room are the only limits i had troubles with in the past. Also, i believe that must not be very difficult to allow AGS to understand that if you type PlaySound("footsteps"); it search for footsteps.ogg, footsteps.MP3... and so long, to give a more intuitive manage of the sound resources in the game.
Jp
What if I wanted to make a game with 301 individual grains of rice in the character's inventory, each with its own unique sprite? What then?
Thanks to these crazy limits, 'Rice Quest: Quest for Some Rice' can never be.
Well, you could make the first grain "item" a GUI button and an own cursor mode... :P
Yes, most of those limits are gone in AGS 3. I'd agree that probably the next one that needs fixing is the 30 controls per GUI, which I will investigate for a future version.
Actually while I was making my MAGS game I hit the limit of 15 walkbehinds and 49 hotspots in a room. These weren't really a problem, I just had to adapt to them. Like the hotspots were of same name you I could combine them and then make a room coordinates check in the interaction functions to make them behave differently.
My game hits the limit of if/else for one function, dialog request. I´ve got about 100 of them and I cannot start my game until I delete some of them. Is there any workaround how to solve that?
Make dialog request call some other sub-functions?
or Chris could add the switch command. One 'switch' could replace all of these 100 if/else.
Quote from: Lt. Smash on Thu 31/07/2008 17:42:05
or Chris could add the switch command. One 'switch' could replace all of these 100 if/else.
Then you get 100 case/breaks.
Quote from: SSH on Thu 31/07/2008 16:54:56
Make dialog request call some other sub-functions?
Yes, but still: I am in about 50% of my game so with sub-functions I can have maximally 100 dialog_request parts... And it is still too few... :'(
Maybe I just didnt get what have you written...
function d_r_A(int p) {
if (p==1) {
..
}
if (p==2) {
..
}
...
if (p==50) {
...
}
}
function d_r_B(int p) {
if (p==51) {
..
}
if (p==52) {
..
}
...
if (p==100) {
...
}
}
...
function dialog_request(int p) {
if (p<=50) d_r_A(p);
else if (p<=100) d_r_B(p);
else if (p<=150) d_r_C(p);
...
}
It's hard to believe though that somebody really needs that much seperate run-script X's.
What are you using them for? Maybe there's a way to simplify things.
Can´t you make some standard GUIs???
One thing I did in a test game was have a function to completely change a the appearence of a GUI, changing buttons color,text, position, disabling views of sliders, etc.
You may Optimize it a bit if you are Tidy...
My solution would be the same as KhrisMUC's, except I'd put a return in at the end of each block to avoid doing unnecessary tests:
if (...)
{
//blah
return;
}
else if (...)
{
//blah
return;
}
//etc
Actually the return's aren't necessary since you're using an if-else chain there, which will already skip any other tests once one condition is met.
Quote from: JpSoft on Thu 24/07/2008 10:58:42
30 controls per GUI and 40 objects per room are the only limits i had troubles with in the past. Also, i believe that must not be very difficult to allow AGS to understand that if you type PlaySound("footsteps"); it search for footsteps.ogg, footsteps.MP3... and so long, to give a more intuitive manage of the sound resources in the game.
Jp
Well, there's an fmod plugin that allows you to use script names for music files.
Quote from: KhrisMUC on Thu 31/07/2008 20:37:18
It's hard to believe though that somebody really needs that much seperate run-script X's.
What are you using them for? Maybe there's a way to simplify things.
An optimized Switch() statement, perhaps. I'd actually be interested in learning how to optimize lots 'n lots of sequential ifs in AGS.
There are two standard ways to optimize a large switch statement.
1) For a mostly contiguous block of numbers (eg run-script numbers such as 1, 2, 5, 6, 7, 8, 10, 12, 13, 14) a compiler would generate a jump table (with null table entries for the missing numbers). The execution time of the code this produces is independent of the number of cases, i.e. it's O(1). Unfortunately this isn't available from AGS script.
2) For sparse distributions of numbers, the compiler makes up a binary search to the appropriate value, which would look something like this (here with contiguous numbers):
if (p < 10)
{
if (p < 5)
{
if (p < 3)
{
if (p == 1) Do(1); else Do(2);
}
else
{
if (p == 3) Do(3); else Do(4);
}
}
else
{
// do 5-9 as above
}
}
else
{
// do 10-20
}
This code executes in a time dependent on log(number of cases), i.e. O(lnN).
You could write a C# script that would make the shell of this code for you and then you'd just have to fill in the implementation of the various cases.