Pumaman begged us to post the following in a forum. So do this.
We sent Pumaman a PM:Dear Chris Jones,
we are programming a game (Steuk) with AGS Editor .NET (Build 3.0.2.44) v3.0.2, June 2008. The first Demo Game is already finished. We think it is a fantastic programm to build own adventures.
But now we reached the first system limit: the „controls on each GUI“. So we had a look on the system limits and we think the „script GlobalInts, the „script GlobalStrings“, the „imported sprites“ and the „controls on each GUI“ are a serious problem.
Our game is not just a click & point adventure but a mix of rpg and click & point adventure. You can also fight there and increase your level. All the game has a lot of animations, so 30.000 Sprites are very few. Our Demo Game takes just 5 Minutes with Walkthrough and it already needs about 600 imported sprites.
The finished game will have a play time of min. 6 hours without walkthrough. And because of the fighting system, we will need many more controls in a GUI and variables. So the limits are really a problem.
Our game works only with AGS Editor .NET (Build 3.0.2.44) v3.0.2, June 2008. We tried higher versions, but then many things doesn't work anymore.
You can download our Demo Game at Specky-Online.de → Projekte → Steuk. It is in german language.
Now we beg you for incresing the limits, the best would be to unlimit it. We would be very thankfull if you could do this for us :)
Yours sincerly
Specky & Miori
Pumaman answered this:QuoteQuote from: Miori on 22 Apr 2009, 21:55
But now we reached the first system limit: the „controls on each GUI“. So we had a look on the system limits and we think the „script GlobalInts, the „script GlobalStrings“, the „imported sprites“ and the „controls on each GUI“ are a serious problem.
Firstly, please don't PM me with Technical questions -- post them in the forum instead, where people can back you up and increase the importance of the suggestion.
GlobalInts and GlobalStrings are obsolete, and you should not be using them in new scripts. Use the Global Variables pane instead to create global variables -- this does not have a limit to how many you can create.
Thanks for your feedback about the Controls On Each GUI limit. I will look into it to see how easy it would be to remove.
Cheers,
CJ
Now our answer:Thank you that you want to look after the „Controls On Each GUI limit“. But what is about the Sprite Limit of 30.000? Could you remove that too? If you could not we see no possibility to continue our game :(
I've run into the Control limit twice, once on two different games. The first (an RPG stats screen) was easily worked around by putting a unclickable, invisible-background Gui ontop of the another with clickable controls. Then match up the Visible calls so that both guis are seen at the same time. The other game's gui went through a redesign, since I realized I was being too stupid and didn't need that many controls.
My final verdict: Yeah, more controls would be nice. I think it's popped a few times in the Wishlist threads. But I don't think it's priority. I'd much rather have more features and capabilities.
~Trent
PS-
QuoteWe tried higher versions, but then many things doesn't work anymore.
That means you probably got scripting problems. You should fix that, since you seem to be such a serious project.
What is the limit of controls on a GUI?
Quote from: Hudders on Fri 24/04/2009 16:58:48
What is the limit of controls on a GUI?
30.
In case this turns into a discussion on raising other limits as well:
From the manual
40 objects per room
100 local messages per room (excluding script)
299 state-saving rooms per game
300 inventory items
30000 imported sprites
30 controls on each GUI
500 dialog topics
3000 dialog-script messages
30 options per topic
20 screen overlays at a time
500 script GlobalInts (not including your own variables)
50 script GlobalStrings (not including your own variables)
5 background frames per room
20 mouse cursors
unlimited characters
unlimited views
unlimited GUIs
unlimited loops per view
unlimited frames per loop
~Trent
Quote from: Miori on Fri 24/04/2009 13:44:53
But what is about the Sprite Limit of 30.000? Could you remove that too? If you could not we see no possibility to continue our game :(
Are you sure that this would be a problem for you? So far I don't know of any game that has got close to the sprite limit, and that includes the full-length adventures that have been made with AGS.
Yes we are sure, because all characters, backgrounds,objects and so on will be full of animations and additional the fighting system, the many monsters that wanna be animated. We are really worried that 30.000 imported sprites won't be enough.
Quote from: Miori on Sat 25/04/2009 01:01:09We are really worried
30 THOUSAND is quite a lot...unless you've actually
reached the limit, I think it's a fair size...oh and just FYI, backgrounds don't count toward the sprite limit.
If it's really an issue, you could possibly even do some of your sprites dynamically.
I'm not sure about this, but you could probably get an extra 20 Thousand (assuming you keep 10k the same) by using RunAGSGame(). You could create a template of your game, create a new project from it, and change what isn't needed in that section of the game.
~Trent
30,000 is enough to develop all the Adventure games i known (even comercial ones) Even Final Fantasy VI had around 24K sprites.
Jp
If you're gonna be like most RPGs, a reuse enemy sprites, but rename and recolor, you could use the .Tint controls, which reduces the amount of 'duplicates' you'd have to import.
~Trent
Quote from: JpSoft on Sat 25/04/2009 19:02:12
30,000 is enough to develop all the Adventure games i known (even comercial ones) Even Final Fantasy VI had around 24K sprites.
Jp
It's no matter for us what other games have, but if you say FF6 has 24k sprites then i am sure we will need more. The most games i know a poor of animations and FF6 is one example for this. But that's okay. FF6 is from 1994.
But i think today's games should be more animated. For example if Specky should push a button that is over his head he jump to press it, not like Zak McKracken, Maniac Mansion and all the old adventures where the character only stands and suddenly the button is pushed.
The backgrounds will be very animated too. And if you are in a city and a fight starts then the room doesn't change. Only the people you see in the background will react to the fight and they stay in background. And there will be many people on the streets of Cocoyo (capital of the planet spooly). If you play our demo game you will see that Specky has already there many sprites. Everything he does has many animations and this will stay so all over the game and Specky will change his outfits several times and all other charakters too. And like i said very much background animations like birds in the forest, the flying clouds, rain, snow and so on... + many fighting animations
30k imported sprites are definitive to little for our game „Steuk“. :o
Quote from: Trent R on Sat 25/04/2009 20:53:19
If you're gonna be like most RPGs, a reuse enemy sprites, but rename and recolor, you could use the .Tint controls, which reduces the amount of 'duplicates' you'd have to import.
~Trent
Thank you for that tip, but our monsters all look different. We don't like this clichéd recolored monsters. Only 'cause it looks like a retro game it doesn't has to be like a retro game ;)
Our game should not be so inanimately it should live :D
I hope Chris Jones (Pumaman) can help us :P
I suggest you notify CJ again, once you've reached 29,000 sprites. I'm sure increasing the limit shouldn't take any longer than it will you to draw another thousand sprites.
Quote from: Miori on Fri 24/04/2009 13:44:53
Our game works only with AGS Editor .NET (Build 3.0.2.44) v3.0.2, June 2008. We tried higher versions, but then many things doesn't work anymore.
You should know that any changes to limits that go into AGS will only be applied to new versions, and not to 3.0.2. So, if you want to take advantage of them, you're going to have to get your game working in the new version.
I can feel your pain on this as my game is also stuck in 3.0.2 because I was taking advantage of a bug that allowed high-res fonts in low-res games. And there are a number of new features that I would love to be using, but I just make do.
Quote from: Miori on Sat 25/04/2009 22:04:18
But i think today's games should be more animated. For example if Specky should push a button that is over his head he jump to press it, not like Zak McKracken, Maniac Mansion and all the old adventures where the character only stands and suddenly the button is pushed.
I feel the same way, and am putting in animations for nearly every action in my full-length game as well as tons of sprites for room animations. I have one room with 511 sprites of background animation. The room seen in this video (http://xiigames.com/2009/03/28/resonance-developers-diary-video-2/) uses only 161. Plus, four playable characters = lots of sprites. And still, I don't think I'm going to wind up knocking on thirty thousand's door. I
might hit half that, but I doubt it.
I took a look at your demo, and I don't see anything that would indicate to me that this game would be any more likely to hit the upper limit than any other AGS game. Of course it is just a demo. If you do hit 30,000, though... more power to you! Hopefully, you can get updated to a new version with a higher limit.
Quote from: Miori on Sat 25/04/2009 22:04:18
30k imported sprites are definitive to little for our game „Steuk“. :o
I hope Chris Jones (Pumaman) can help us :P
I won't be doing anything with it right now, but let me know if your game reaches 20000 sprites and at that point I will look into what would be involved in increasing the sprite limit further.
@ Vince Twelve
The “high-res fonts in low-res games“ was also our problem. We tried a newer version but it didn't work but now we took the newest version (3.1.2.82) and it adjusted all graphics we just had to adjust the font size :)
511 sprites in one room that's impressive and we watched the video. It looks very beautiful. Our Demo is really very short and shows max. 0.1% of the game. We also know that if we develop a game in the end the finished version will look much different than the demo game. So we are tight just as the other people how the game will be in the end. :P
@ Pumaman
That's okay, we just wanted to know wether you can do this, if we will need it. The only problem at the time is the control on each GUI limit. It is the reason we can't continue the fighting system. If we reach 20.000 sprites we will contact you again ;)
30 controls per GUI is a limit than can be easily solved. You can just add as many GUI´s as you need. Actually, the minimap in the RTS im working have 3 GUIs in the same position of the screen, and the main GUI to control the game have 4 different GUIs. In mi opinion, there are some limits more difficult to solve (for example, objects per room)
Jp
I wouldn't mind an extra 10, if it can be added. But surely it can be worked around very easily... not that hard to do Miori.
~Trent
Another possibility would even be to use virtual (rectangular) bounding boxes for your controls. You could then check the mouse (X, Y) position to determine what interaction to run. But realistically, especially now that there's no longer a limit to the number of GUIs, it shouldn't even be a problem to just spread the controls across multiple GUIs if 30 controls is too few.
Quote from: Miori on Sat 25/04/2009 01:01:09
Yes we are sure, because all characters, backgrounds,objects and so on will be full of animations and additional the fighting system, the many monsters that wanna be animated. We are really worried that 30.000 imported sprites won't be enough.
Holy ***. There are commercial games that don't use that many sprites for all their animations- Diablo 2 can cope with far less, and that's a full length game with a not too small cast of beasts and characters! I'd relax, 30.000 IS a lot of sprites...
For animations in backgrounds you could resort to using "cycling backgrounds", they don't count against the sprite limit. So for some flickering candles and the like, no custom views, but five backgrounds.
[edit]
Checked your site and had a look at your spritework... With that style you *could* simply decide to make a paletted game and use palette cycling to change the colour swatch of a certain character, couldn't you? That way you could have one "piggy merc" in x colour swatches, representing "different" monsters. (Again, a trick done to death by Diablo 2). Faster than "tint" and mabe with a few more possibilities...
BTW, I totally dig those pigs. Reminds me of S.W.I.N.E. for some reason... ;)
To quote SSH, not even Quest for glory didn't reach that limit.., but I guess sprites don't have to do with what people want to do. Wondering how come only 6 hours with so many sprites..
- This applies for the total number of Sprites in AGS. -
One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().
Each .exe having the basic redundant global sprites (like the main character's, the GUI's, etc...), and the sprite slots left are for the local exe.
So technically for N AGS executables you have : (N*30'000)-((N-1)*TOTAL_GLOBAL_SPRITES) slots.
Example : 5 AGS executable, main one included, with 700 global sprites you'll have : 147'600 sprites for the whole game. Jinkies! Who needs that many?!
Of course this depends how the game is designed.
For instance :
I'm designing a game with six distinctive worlds. I could split the game into 6 exe and one world for each respectively. And I go from one world to another using RunAGSGame().
This is a theory I didn't try yet with RunAGSGame(). I'm not even sure if it could work.
I don't know how the global variables are managed, if I every .exe can share the same variables (if it isn't possible, I could use a external temp file - or I design a game that doesn't need to share variables and that all events are local).
Quote from: Nefasto on Mon 27/04/2009 16:39:01
One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().
That's what I said above! ;D
But who know's if it'd work, but wouldn't be that hard to throw together a test.
~Trent
That would work, and the save game files would even properly load the correct executable file so that wouldn't even be a problem either.
Sprites that would have to be shared would of course be GUI sprites, player character sprites (and any NPCs which would appear in that executable's rooms of course), and any inventory items which could possibly have conceivably been acquired at this point (i.e., if the room can only be entered once then any inventory gained after that point (from another executable) wouldn't have to be included in this executable (and so forth)).
So I would say that the RunAGSGame idea is probably the best idea for averting these system limits without a lot of work on Chris' part having to change this limit for a one-off situation. Realistically most authors would never come close to this limit.
Further, I can personally attest that RunAGSGame runs very quickly and smoothly...in my tests it's extremely comparable to just loading another room...
Quote from: JpSoft on Sun 26/04/2009 21:31:51
30 controls per GUI is a limit than can be easily solved. You can just add as many GUI´s as you need. Actually, the minimap in the RTSI'm working have 3 GUIs in the same position of the screen, and the main GUI to control the game have 4 different GUIs. In mi opinion, there are some limits more difficult to solve (for example, objects per room)
Jp
I forgot to mention that you could use characters as objects if you want, even when this solution could be very painful to implement.
E
Quote from: Trent R on Mon 27/04/2009 18:23:32
Quote from: Nefasto on Mon 27/04/2009 16:39:01
One of the actual solution I would try to go around the issue of the System Limit Problem with sprites (if I have to) is to split the game in many executables and use RunAGSGame().
That's what I said above! ;D
~Trent
Oh! You're right. Sorry. Somehow I didn't see it. =P
If these limits were all dynamic values it would place the burden on the game developer (where it belongs) rather than the engine author to maintain a reasonable balance between content and performance. It would also completely eliminate the semi-frequent requests for extensions to x limit and would allow games that use much less than the current static limits to be more efficient (unless these limits are already dynamically allocated memory within a preset upper limit, which is possible!).
I agree with what Progz says but realize it may not be practical to eliminate thes elimits at this point. Perhaps, instead the limits could be specified in a configuration file that is read by the editor on startup?
Most of the limits that remain in AGS are related to the file formats that AGS uses and the way data is persisted between rooms.
If it was just a simple matter of configuring a limit in the editor and allocating memory based on that, there'd be no point having a limit at all -- it had may as well be unlimited. This was the case with things like the Max GUIs, Max Characters and Max Views limits, which have been removed from recent versions of AGS.
The ones that remain are more tricky to deal with which is why they're still there.