Are there speed implications for using six thousand characters?

[EnterTheStory (aka tolworthy)]

I'm combining my games into one file: currently I have 900 characters in 4 stories, and when I complete my goal of 100 stories I expect to have around six thousand characters. Many of will them re-use views, so with some awkward fudging I could reduce the character count to maybe two thousand, and have them change rooms and names as needed. Is there likely to be any speed benefit in doing so?

E.g. is there anything about the built in AGS code that checks every character every frame? Or (worse) built-in code that compares every character to every other one (i.e. so a small increase in character numbers would have a big impact on game speed)?

[GarageGothic]

I would assumed that AGS is coded sensibly enough to only check characters that are actually in the current room. So unless your own code runs through an array of all characters, I don't think there should be an issue.
Another thing that struck me though, have you taken into consideration that only rooms up to no. 300 have their states saved? Or perhaps you handle all objects and other stuff in global script?

Also be aware that you're jumping from one solution not tested by many (intense use of RunAGSGame) that turned out to be flawed to another one that hasn't been tried before (game of epic proportions), at least not with such an ambitious scope.

You're making quite a rash decision with a lot of downsides (files size etc.) and unforeseeable technical consequences. I realize that you want to keep some degree of Linux/Max compatibility, but if you're willing to sacrifice that, you'd possibly be better off writing or having somebody write you a plugin that makes it easier to modularize the individual stories. With a 20+ year business plan, it's quite risky to base it all on the unknown limits of a game engine you have no control over. Just saying, not trying to be pessimistic.

[EnterTheStory (aka tolworthy)]

have you taken into consideration that only rooms up to no. 300 have their states saved?

I've always wondered, what exactly is a room's state? I don't use room objects and seldom use room based variables, so that leaves character positions. But character.Room and character.y appear to be part of the character struct, not part of the room code. I may have to experiment...

you're jumping from one solution not tested by many (intense use of RunAGSGame) that turned out to be flawed to another one that hasn't been tried before (game of epic proportions)

Oh, I'm EXTREMELY aware of that  And I do appreciate the concern. But RunAGSGame had never been tested with multiple games, whereas changeRoom has been tested tens of thousands of times. From a computing point of view, my feeling is that 3000 rooms would not use any code that is not thoroughly tested in 300 rooms.

you'd possibly be better off writing or having somebody write you a plugin that makes it easier to modularize the individual stories.

Is that an offer?

But would't that introduce its own uncertainties? I'm willing to lose the Linux functionality, but would it really be more stable?

Also, the tester who discovered the bugs inferred that the problem was with Windows, not the game: the game played perfectly on some computers, and when it did crash it then worked perfectly after a few more attempts, suggesting the possibility that Windows was simply having trouble with AGS and shortcuts. If true, that would affect ANY modular solution.

With a 20+ year business plan, it's quite risky to base it all on the unknown limits of a game engine you have no control over.

True. But I should have definite hints within a few weeks if there are problems with extra large games. If I see new problems, and if no modular solution magically appears, then I'm really going back to basics: I'll have a real rethink, freeze all existing games, and start again with a completely new concept that is EXTREMELY simple.  

[GarageGothic]

I've always wondered, what exactly is a room's state? I don't use room objects and seldom use room based variables, so that leaves character positions. But character.Room and character.y appear to be part of the character struct, not part of the room code. I may have to experiment...

Any room specific settings (those that can only be adjusted while in the room) - background frame, on/off state of walkable areas, hotspots etc.

But RunAGSGame had never been tested with multiple games, whereas changeRoom has been tested tens of thousands of times. From a computing point of view, my feeling is that 3000 rooms would not use any code that is not thoroughly tested in 300 rooms.

I wasn't thinking in terms of simple function calls as much as memory handling, save game structure and such. I recall you had a nasty experience with a memory leak in the engine you used before AGS (was it SLUDGE?). Have you definitely given up on CJ fixing the RunAGSGame issues?

you'd possibly be better off writing or having somebody write you a plugin that makes it easier to modularize the individual stories.

Is that an offer?

Sadly, I'm not adept enough with C++ to make such an offer quite yet, but I am working on several plugin features that could eventually prove useful to larger game projects. (Making no promises of completion, but one thing I'm working on is implementing a resource file format that allows storing external folder trees in a single container file and accessing the individual files from within AGS. Another is support for the JPG-like lossy image format PGF which should cut file size of hi-res games quite a bit).

But would't that introduce its own uncertainties? I'm willing to lose the Linux functionality, but would it really be more stable?

Depends on the implementation and the complexity of the plugin really. The most simple solution could be a simple launcher program (an .exe rather than a plugin) that just replaced the RunAGSGame functionality with actually quitting one game and starting another one based on a data file written from within the game. That's such basic functionality that not too much can go wrong. Of course more ambitious solutions have more factors to deal with.

Also, the tester who discovered the bugs inferred that the problem was with Windows, not the game: the game played perfectly on some computers, and when it did crash it then worked perfectly after a few more attempts, suggesting the possibility that Windows was simply having trouble with AGS and shortcuts. If true, that would affect ANY modular solution.

Now I'm confused, are we talking the shortcut issue or the RunAGS issue, or are they one and the same? Are you sure that the problem has been investigated thoroughly enough to warrant such a massive design change instead of identifying the actual cause first?

True. But I should have definite hints within a few weeks if there are problems with extra large games. If I see new problems, and if no modular solution magically appears, then I'm really going back to basics: I'll have a real rethink, freeze all existing games, and start again with a completely new concept that is EXTREMELY simple.

I wish you the best of luck, would hate to see this coming back to bite you in the ass years from now.

[EnterTheStory (aka tolworthy)]

I recall you had a nasty experience with a memory leak in the engine you used before AGS (was it SLUDGE?).

Yes. That's since been fixed, but I couldn't afford to put all my plans on hold, hence the move to AGS. I miss some things in SLUDGE (the greater flexibility due to doing everything as text, or more reliable floors since they're made with lines, not pixels), but in most other ways AGS is better.

Have you definitely given up on CJ fixing the RunAGSGame issues?

I can't expect CJ to spend a huge amount of time refining obscure features that almost nobody uses. And even if he did, bug fixes only happen during upgrades: and every upgrade has as many costs as benefits. E.g. AGS 3 can handle language changes (hurrah!), but creates blank loops in views so characters randomly disappear (boo!); it allows views to be edited (hurrah!) but removes the ability to batch edit sprites (boo!), etc., etc. If RunAGSGame is fixed I may lose something equally valuable.

I am working on several plugin features that could eventually prove useful to larger game projects.

I'm impressed!

are we talking the shortcut issue or the RunAGS issue, or are they one and the same?.

I can't be sure. All I know is that all serious bugs occur when loading games. I can't reproduce all the bugs on my machine, though after half an hour of testing I managed to find a lone similar event. It happens more often on other computers, but on mine it's like looking for a needle in a haystack - it could take literally weeks to narrow down exactly what is happening. All I know is that all the current bugs occur when starting games, and most of my past problems have begun with RunAGS. It's entirely possible that all of this comes down to something I have done, but the key issue is time (see next point).

Are you sure that the problem has been investigated thoroughly enough to warrant such a massive design change instead of identifying the actual cause first?.

It all comes down to timing:
Time taken to create one game: 3 months
Time taken to fix problems relating to switching games: 3 months
Time needed in track current and future bugs relating to switching games: 1 out of every 3 months???
Time needed to combine all games, removing all need for switching: 1 month

To that I would add, after mulling over your comments:
Time needed to fix unknown bugs relating to giant game:
Time needed to make all games stand alone: 1 week.

I spent last night thinking through what you said, and all the pros and cons, and I finally decided to give up the dream of directly linking stories. Stories will still be conceptually linked - you will see one end of a street in game A and the other end of the same street in game B - but to walk from one end of the street to the other you will now need to close game A and start game B. With the benefit of hindsight I think it's the only sane solution.