Messages

Thanks. I'll do that.

The 2000 characters and 35 line limit was from another thread on GUIs and String.Format - can't find the link now, sorry.  2.72 allowed GUI label text to include 2048 characters, and I don't know if it was increased.

Could extreme usage of String.Format or a GUI label cause a game to freeze?

Once every few months someone comments that my game freezes when my "recent dialog" screen pops up. It uses this code:

Code: ags

String memoryDialog[115]; // records every line of dialog as it is spoken
String dialogText; // temporary
function updateDialogLabel(int line) // adds lines from "memoryDialog" to the end of  "dialogtext"
{	String text ="";
	if((line >=0)&&(line <101)) // elsewhere the contents of memoryDialog are looped after line 100
	{ if(memoryDialog[line] !=null)
		dialogText =String.Format("%s[%s", dialogText, memoryDialog[line]);
	}
}
function showMemoryDialog()
{ int line = memoryDialogBot -8;					// start 8 lines before current line
	dialogText ="";
	updateDialogLabel(line);
	int i =0; while(i<9){ line++;updateDialogLabel(line);i++;} // adds 9 recent lines 
	dialog0.Text =dialogText;
	if(memoryDialogBot >5)dialogUp.Visible =true; else dialogUp.Visible =false; // up and down arrows on the GUI
	if(memoryDialogBot <memoryDialogNow)dialogDown.Visible =true; else dialogDown.Visible =false;
}

I know there is a limit of 2000 characters and 35 lines, but I think it's unlikely I reach those limits. Is there anything else about this code that shouts 'potential freeze'?

Thanks! I just PM-ed you.
@hedgefield - you are very kind! The first few games had some teething problems, but I think I'm finally getting there. Hopefully games will come thick and fast after this.

EDIT:

Just a note to say I've uploaded an updated version. If you're looking at version 4, version 5 has a number of fixes.

Thanks! I'm very grateful. Any suggestions for improvements are welcome. I just PMed you.

- Chris

My new game, The Count of Monte Cristo, could do with some testing - any volunteers? I'm also looking for suggestions for how to improve it, so any feedback at all is welcome! PM me and I'll send you a link.

Thanks in advance.

you can, with a reasonable amount of safety

"reasonable amount of safety" makes me nervous

I have done this..extensively..in most all of my modules since I discovered that this works. I've never had anyone complain about me doing it.

That is reassuring. Assuming that the cause of any problems would be apparent to the user.

Thanks.

This thread says a String parameter can have a default value, e.g.

Code: ags

function myFunction(String optional =0)
{ if(optional !=0){ runCode();}
else{return;}
}

Apparently this might, in theory, be potentially dangerous. Why? What might possibly go wrong? I'd like to use it in deeply embedded mission-critical functions, and I can't afford to take any chances.

Brilliant! It works! I am forever in your debt.

My translated games work fine, except for this code:

Code: ags

function rm(String st) // used for finding room numbers from names
{	if(st ==GetTranslation("London streets"))        return 3;

How it works is this: if a hotspot has the name of a room (e.g. "London streets" is room 3) the game can use "rm(name)" to return its room number. I also list room names in an array of recently visited rooms. This works fine in English, but in other languages it breaks. So I tried this:

Code: ags

function rm(String st) // used for finding exits from names
{	if(st ==GetTranslation("London streets"))        return 3;

But get the following error:

Code: ags

misc code.asc(369): Error (line 369): Type mismatch: cannot convert 'String*' to 'string'

Any suggestions?

That's excellent. Many thanks!

I think this is what you're looking for:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=41636.0

Thanks for the link, but I can only find 3.2 there - is there also a link to 3.02?

My computer recently died and I'm busy rebuilding a new one. I need a copy of 3.02 for compatibility reasons. any idea where I can find it? Thanks in advance.

I like the idea how you link the games to eachother etc!

Thanks! Originally the games literally connected. If a game was in the same folder you could literally walk back and forth between them. But that caused endless problems, as nobody has ever tested RunAGSGame under such extreme conditions. It worked 99% of the time, but  with a game that relied so much on connections a typical use would involve maybe a hundred switches between games, and so would be guaranteed to crash eventually. So I reluctantly had to change it so you can only move between games via the opening bookshelf. That seems to be stable.

The games still share the same cast, same locations, etc. - e.g. you can see one end of a street in Les Miserables and the other end of the same street in A Tale of Two Cities, and characters in Dante's Inferno do sometimes refer to Les Miserables. So now it shares the same game world in the sense that Marvel Comics or Star Wars stories share the same world.

Incidentally, by ending the unlimited back and forth between games it makes them much easier to make, and less confusing for the player, so it's probably for the best.
But the real test will be the story I'm working on now, The Count of Monte Cristo: literally half the scenes and characters are reused from other games. I'm going for a theater concept, where the same actors and props are used in different plays. This should allow for a new story every two months by next year, and possibly even a new story every month within ten years.

it seems to be dead now...

In keeping with the spirit of the AGS boards, Les Miserables: the game of the book is now freeware. Click over to http://enterthestory.com/ and look for the red "FREE" label.

The game sold well for a first game, but one of the composers who provided live music did so on the understanding that the game would be free one day, and now it is.

Over the last couple of years (and particularly since upgrading to 3.x) players have reported some minor bugs, and these should all be fixed now. As a first game the underlying code is pretty complex, so there may be still some rough edges but nothing too serious. I hope someone enjoys it.

Oh,and I'd like to upload it to other places beside my own site. Any suggestions? It's 135 MB if that's relevant. And if anyone else wants to upload it to their site you don't need to ask permission, I'd be flattered.

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.

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.  

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)?

How large is your compiled game? It shouldn't take 30 seconds before the preload.pcx comes up, I'd be interested to see what exactly is making it take this long.

EDIT:
I created a new test game, of a more realistic size: 115 MB when compiled (includes 85 MB of code modules*). When starting the game for the first time, nothing happens for 20 seconds, then the preload screen appears  for 2 seconds, then the game starts.  My computer is a bog standard 1.6 GHz XP machine with 500 MB memory. I tried splitting media files into 10MB chunks. Curiously, this created
sandbox.001 10MB
sandbox.002 1MB
sandbox.exe 104MB
and took even longer to load than before.

NB this is using a 24 bit Preload.pcx in a 16 bit game. But according to the help file:

simply save the image as PRELOAD.PCX (must be the same resolution and colour depth as the game)

The PCX format normally only exists in 1, 4, 8, and 24 bit depths. Does this mean that preload.pcx should never be used in a 16 bit game?

*50 modules, each with 1000 functions in 10,000 lines (of 500 characters each). It took over 10 minutes to compile - perhaps the large number of functions is an issue?

Actually I should give RunAGSGame another shot.

I'll stick with it if I can't get the "all in one" idea to work, but I'm starting to fall out of love with it. Specifically:
(start RunAGSGame tangent)
1. It was never designed for what I'm doing with it.
2. I seem to be the only person using it on a large scale.
3. My "many games as one game" concept requires very complex code.
4. I am not a top class programmer.
Result: RunAGSGame (and its implications) take up about one quarter of my time, with no end in sight. The latest bugs, though minor, are incredibly hard to track. I think it's time to cut the Gordian knot.

Ironically, the problem has led to the solution. Earlier this year I moved from 2.72 to 3.x because RunAGSGame and translations files were incompatible. I've moaned about it plenty - it added at least two months of full time work - but 3.x can handle giant games whereas 2.72 could not. My other reason for not doing a giant game at first - the time needed to compile  is less of a problem, as with four games under my belt I'm able to do a lot more coding in-between compiles.
(end RunAGSGame tangent)

Really the only major problem I can see is loading time, and even that won't be a serious issue: loading times will grow slowly, and I can always warn people in the installation file. It's not the end of the world.