making very large games (2,000 rooms plus)

[EnterTheStory (aka tolworthy)]

Hi! I've been developing a game in SLUDGE for several years (lesmisgame.com), but recently discovered a serious memory leak. So I'm looking at AGS instead - the size of the AGS user base is very reassuring! But how is AGS for very large games? My first game only has 140 scenes, but I plan to add another 50 or more every six months after the first release. AGS looks pretty exciting, but does anyone know:

1. Is there an upper limit for rooms, and does this affect playback speed?
2. Are there any known memory leak issues?
3. Can I do anything to make my game run faster, apart from reducing the screen size?
4. I have several sprites that have over a thousand frames each. Could these be automatically imported, or would I need to add each frame manually?
5. the 150 character limit - is this per screen, or for the whole game?
6. Is it always possible to write custom functions to replace built in functions?

Thanks in advance for any advice!

[Candall]

1. Is there an upper limit for rooms, and does this affect playback speed?
2. Are there any known memory leak issues?
3. Can I do anything to make my game run faster, apart from reducing the screen size?
4. I have several sprites that have over a thousand frames each. Could these be automatically imported, or would I need to add each frame manually?
5. Is it possible to create a complete AGS game in a text editor?
6. Is it possible to write custom functions to replace built in functions if the need arises?

1. There is a superficial limit of 300 rooms, but that isn't true, strictly speaking.  You can have as many rooms as you want, but AGS will only keep up with the states of 300.  If you want to save states in additional rooms you will have to do so by way of variables.  I hear that there is actually a stern limit to the total number, but I think it's above 2,000, or maybe right at it.

2. I believe that 2.72 is very, very stable.  I'm sure that 3.0 will be as well.

3. Game speed is directly affected by screen size and color depth, both of which can be set from an easy-to-use menu.

4. You can use a tiled import function to import sprite sheets as seperate sprites; you can also import animated GIF images as seperate sprites.  Know, however, that the total limit on sprites is 15,000.

5. I'm not 100% sure about what you mean here; you can't use a text editor to completely build an AGS game, no.  You have to use the AGS interface to import sprites and build views and loops.  There is a very nice text editing environment built into AGS for the purpose of coding, however, so you won't need an external editor.

6. Yes, indeed!  You can also write complete modules and plugins.

[EnterTheStory (aka tolworthy)]

Thanks for the quick reply!

I hear that there is actually a stern limit to the total number, but I think it's above 2,000, or maybe right at it.

I'm guessing that this could be bypassed by writing some code? E.g. one "room" could be a forest, and I could write variables to rearrange the trees? But 2,000 is probably enough.

2. I believe that 2.72 is very, very stable.  I'm sure that 3.0 will be as well.

That's good to hear. Am I right in thinking that there are enough AGS users making large games (or with good programming knowledge) that it's unlikley that a major memory bug would pass them by? With SLUDGE, the memory issue (assuming is genuine) is very major, but nobody noticed it until now, because the user base is too small so nobody happened to run into it.

3. Game speed is directly affected by screen size and color depth, both of which can be set from an easy-to-use menu.

So an 8 bit game be nearly twice as fast as a 16 bit game? Assuming that most of the large resources are in the form of graphics. And that would apply even if the graphics were stored asJPEGs and converted on the fly? Sorry if I'm talking nonsense here, I'm reading the manuals as I type.

the total limit on sprites is 15,000.

15,000 frames? Then are there other ways to show animated objects? For example, if I have an object like a roaring fire or waves on the sea, could I animate them in some other way instead?

5. I'm not 100% sure about what you mean here; you can't use a text editor to completely build an AGS game, no. 

I was just thinking of my experience with Sludge. At the start I used all the standard commands (make screen region, say, move, etc) but over the months I've written alternate code that encapsulates the original command and also does other useful stuff (e.g. my "Say" allows an entire conversation to be included in one string, by calling as function that breaks up the string, assigns the parts to wheoever is standing nearby, and then calls "say"). I'm hoping the same thing can be done with AGS, so if I want to bypass a standard command or method, I can. For example, I don't want to have to click on separate buttons or navigate a menu every time I have to enter X and Y coordinates!

You can also write complete modules and plugins.

I'm just exploring those now. Very interesting indeed!

[Ghost]

Re speed issues; as far as I know these pop up if you have a lot of objects and characters on-screen at the same time, while the actual number of rooms/objects etc affects only the file size.

The idea of using one room as several rooms by re-arranging trees (or other elements) is interesting and sound. It should work without trouble.
As a matter of fact, you can easily make hotspots and objects have different responses by just adding one variable to your script; I think you idea will work fine.
But: 2000+ locations? Really? What are you going to script???

[GarageGothic]

3. Unfortunately you can't use external JPG files from within your game. The graphics all have to be imported into AGS which compresses them using its own lossless format.

4. Actually with the soon to be released version 3.0 it's been doubled to 30,000 sprites.

5. While the engine's own dialog editor has limits for how much text it can display at a time, Strings don't have a character limit. However, at least in v. 2.72 the script editor window has a limit  on how many characters you put on a line (around 500 I think, you can add line breaks, but they will also turn up in the printed string).

[Pumaman]

I'm guessing that this could be bypassed by writing some code? E.g. one "room" could be a forest, and I could write variables to rearrange the trees? But 2,000 is probably enough.

There is a limit of 1000 rooms, however each room can have multiple background images and you can change the active background at run-time, which allows you to simulate having multiple rooms within a room in appropriate locations.

Having said this, some of the largest games made with AGS (eg. Al Emmo, King's Quest 2 VGA, Tale of Two Kingdoms) don't come anywhere near 300 rooms, let alone 1000. If it ever started to pose a real problem for anyone, the limit could probably be raised.

That's good to hear. Am I right in thinking that there are enough AGS users making large games (or with good programming knowledge) that it's unlikley that a major memory bug would pass them by?

There's always the possibility of there being bugs in the engine. However, AGS has been around for over 8 years now and I'm not aware of any serious outstanding issues at the moment. The release of KQ2VGA a few years ago actually helped a lot to fix the remaining issues with AGS at the time, because of its wide audience.

So an 8 bit game be nearly twice as fast as a 16 bit game? Assuming that most of the large resources are in the form of graphics. And that would apply even if the graphics were stored asJPEGs and converted on the fly? Sorry if I'm talking nonsense here, I'm reading the manuals as I type.

Potentially, but what you might gain in runtime speed you'd lose in time fiddling with palettes in the editor. Additionally, the Direct 3D Accelerated driver in AGS 3.0 doesn't support 8-bit modes so you wouldn't be able to benefit from the performance improvements that it brings.

On the other hand, the choice between 16-bit and 32-bit colour is up to you. 16-bit is likely to be faster, but 32-bit offers alpha blending and nicer gradients.

15,000 frames? Then are there other ways to show animated objects? For example, if I have an object like a roaring fire or waves on the sea, could I animate them in some other way instead?

The current limit is 30,000 sprites. As with the rooms limit, no game made so far has approached this limit so it's not something I would be particularly worried about.

I was just thinking of my experience with Sludge. At the start I used all the standard commands (make screen region, say, move, etc) but over the months I've written alternate code that encapsulates the original command and also does other useful stuff (e.g. my "Say" allows an entire conversation to be included in one string, by calling as function that breaks up the string, assigns the parts to wheoever is standing nearby, and then calls "say"). I'm hoping the same thing can be done with AGS, so if I want to bypass a standard command or method, I can.

You can write your own methods, but you'd need to change the calling code. That is to say, you could write your own Character.MySay method that encapsulates the Say command, but you'd need to change your other scripts to call MySay rather than Say.

5. the 150 character limit - is this per screen, or for the whole game?

Not sure what you mean by this. If you're referring to a limit on the number of characters that you can create, it has been completely removed in AGS 3.

Coming from a SLUDGE background, I'd recommend you skip 2.72 and go straight to the AGS 3.0 beta, which you can find in the main Technical Forum. It is more scripting-oriented and probably easier to get to grips with for you than 2.72.

[Candall]

Hmm, the use of so many frames per animation is an admirable goal to be sure, but it's also somewhat counter-intuitive to the "retro" nature of this community.  AGS was built to allow emulation of the old-school Adventure style.  Part of that is tight conservation of resources.  To partially answer your question, there are indeed other methods of introducing more animation to your scenes, one of which is the use of animated backgrounds, the frames of which, to my knowledge, are not numbered among your Sprite Count.

However, you can only have five frames per backdrop.  Now, a good animator can make a beautiful looping seascape with only five frames.  Same goes for a smoothly animated fire.  This would obviously rob you of any sense of randomness to the wrath of the sea and flame, but the truth is that those of us so firmly bolstered to the old ways see a real beauty in that forespoken conservation.

I honestly can't even imagine a single object moving to the tune of a thousand frames, though I would love to.

Sorry about the misinformation regarding Sprite Count, Pumaman.  I was referencing the documentation contained with the 2.72 release.

[EnterTheStory (aka tolworthy)]

2000+ locations? Really? What are you going to script???

It's always been my dream to have a game where you can wander around and become part of classic novels and major ideas. The first version will contain Victor Hugo's Les Miserables (see lesmisgame.com). The next version will add to the same game world, and let the user play through Tolstoy's War and Peace. Then 6 months later I will add Dante's Divine Comedy, and so on. The first version has 140 rooms, the second will probably add another 100, the third will add about 80, and so on. I've been working on this since 2000, though have only been putting in serious daily time for the past year. In the first ten years I expect to add at least 1000 scene, probably a lot more.

An earlier version of this game had 5000 working scenes already, but the graphics were not good enough, so I started again with more modest goals. You can see a video of the earlier version here: http://youtube.com/watch?v=o0hTnFF97po  

[Ashen]

You'd probably be better doing them as seperate games, IMO. You could make a connecting, front-end game, and link them using RunAGSGame. Might take a bit of creative working around - but almost certainly less than trying to cram tham all into one huge game. (And would have the added bonus of making them individually playable - wouldn't have to download every sinlge update, just to play though one.)

[EnterTheStory (aka tolworthy)]

I honestly can't even imagine a single object moving to the tune of a thousand frames, though I would love to.

I have several animations in my game that contain more than 1000 frames, usually crowd scenes. In Sludge there was a problem with removing background characters, so I found it was easier to pre-render the entire crowd. Also I use sprites instead of video, to avoid codec problems (the opening sequence looks like video but is actually a 1500 frame sprite).

I'm hoping there are other ways to do this in AGS, because some of these sprites have large transparent areas, and this creates HUGE, HORRIBLE memory needs. I'm dsure there are better ways to achieve the same result, and I'm encouraged by the seeing so many amazing modules and plugins.

You'd probably be better doing them as seperate games, IMO. You could make a connecting, front-end game, and link them using RunAGSGame.

If I can do it seemlessly I will, but the major selling point of the game (eventually) will be that you don't download a particular game, you download an environment. In it you can endlessly explore and stumble across amazing stories. It's my guarantee that eventually people will want to buy it, because every version will be bigger and richer than the last.
There is no danger that the size will get too big. As more stories are added I will be reusing more and more resources. I think the game will expand more slowly until in ten years' time it is something like a 600 MB download, though by then I hope to have a regular publisher.

Strings don't have a character limit.

Is there a total string limit? Ignore this if the answer is in the documentation, I'll get to it soon enough.  In Sludge the limit is 65,500. Which seems a lot at first, but they soon get used up.  Sludge uses the same list of strings for everything. For example, I have 3,000 objects that require an average of 3 or 4 strings each (1 for the name, plus reactions to "look at" and "use" etc.) That's 10,000 strings used up before I even talk to a person! I'm hoping AGS is more flexible.

[Ghost]

You can see a video of the earlier version here: http://youtube.com/watch?v=o0hTnFF97po  

Impressive, really, and highly ambituous. Now I am intrigued...

[Khris]

You might need some custom save/load feature if you plan to continually expand an existing game.
A few changes to a game will usually render previous saves unusable, although there are exceptions. (Changing an in-game string won't affect saves, changing the size of an array will, e.g.)

Afaik, there's no limit to the amount of strings as long as they're inside scripts.
There used to be a global message system with a limit of around 500 or so, too, but I think it has been ditched as of 3.0 anyway.

About animating a huge amount of characters: in theory, there's no real limit other than CPU power/memory. It's possible to not use AGS-characters/objects but to "RawDraw" everything to the screen every frame. This'd only require structs holding character data such as coords and frames and a routine to update the screen accordingly.
This possibility has already been used in the occasional game, we've seen animated starfields, fireworks, shoot-em ups, jump'n'runs, even full, textured 3D games.
With some clever coding, it's possible to do almost anything in AGS.

[EnterTheStory (aka tolworthy)]

You might need some custom save/load feature if you plan to continually expand an existing game. ... Afaik, there's no limit to the amount of strings as long as they're inside scripts. ...  It's possible to not use AGS-characters/objects but to "RawDraw" everything to the screen every frame. ... With some clever coding, it's possible to do almost anything in AGS.

The more I learn about AGS (especially recent versions) the more excited I become! And I just had it confirmed that the memory leak in Sludge is real, it's not just down to my amateurish coding. Part of me thinks I should contact the developer and ask him to fix it, but to be honest AGS is looking so cool right now! Can I justify delaying the game by three months in order to port it to AGS? Can I justify NOT converting to AGS with so many great features on offer? This is going to be so much fun!

OK, one more techy question. How is performance affected if you have ten tiny characters on screen? What about twenty? I'm talking maybe thirty pixels high each. Or less. Has anyone done that before in AGS, or is it too processor intensive?

[GarageGothic]

Check out the Character Control Module demo to see an example of a LOT of characters moving around the screen without causing any slowdown.

[EnterTheStory (aka tolworthy)]

Check out the Character Control Module demo to see an example of a LOT of characters moving around the screen without causing any slowdown.

Thanks! I think I've probably asked enough questions. It's time to fire up the program and see what it can do first hand.

[RickJ]

tolworthy,

You would be well off considering using the RunAGSGame feature to implement your 2000 room game from what you've said so far.   You can transition seamlesly back and forth.  I have written a MinGame module that allows you to Call and Return from a game the same as you would a function.  If you are interested about the module just PM me.

[FSi++]

Only problem you could encounter is that AGS games do not work in Wine natively. The same possibly applies for MacOS (though I can't be sure on that). There are ports of the engine to those platforms (but MacOS port stopped at 2.71 and Linux port has some, er, compatibility issues).

[EnterTheStory (aka tolworthy)]

Only problem you could encounter is that AGS games do not work in Wine natively. The same possibly applies for MacOS (though I can't be sure on that). There are ports of the engine to those platforms (but MacOS port stopped at 2.71 and Linux port has some, er, compatibility issues).

Linux and Mac support are major pluses for me, but the 2.71 issue is a serious one. Is this situation likely to change? Or should I stick to developing with 2.71 for the sake of the Mac?

[Radiant]

I can confirm that 2.72 still works fine under Linux (assuming you don't use any DLL plug-ins).

Characters on-screen don't impact performance in any noticeable way. The performance hogs are some of the RawDraw functions, and using several large (as in, half the screen) overlaying things that are partially transparent.