Messages

I'll say it's okay, so just start it here when you're having the next round.

Maybe there're such characters in your "My Documents" folder? As recent versions of AGS would create save games (among other things) there, so it may cause some problems. What language are your Windows in?

The path problem seems to be fixed in the newest (not-released-yet) version though. You may try 3.2 Final 5 and check whether your problem persists. (Right, V3.2 is not officially released yet, but I think it's stable enough for one to upgrade to in case there is some problems from previous versions. Always back up the game files before upgrading of course.)

["Me is hangury!"]

"Me is hangury!"



Jon Arbuckle is away from home, but he has forgotten to feed his adorable kitten. Now, the starving kitten is on his own, looking for a way to open teh only edible piece of relic at home...

Help the kitten fulfil his quest, be it successful or not.

Guidelines:

• You can draw your own versions of the sprites if you do not want to use the supplied ones, as long as it is about a fluffy animal that purrrrs, who tries to open some sort of food sealed in a container (so it's not limited to a tin of tuna; it can be a box of biscuits, a bottle of pickles or whatever you can think of).
• It is not necessary for the animal to succeed at the end. He may fail. Hilarity takes precedence.
• You can add any objects to act as tools, or if you're imaginative enough, you can also do it without adding any objects.
• No size, colour or frame limits.
• You may modify and animate the supplied sprites or draw and animate your own sprites, within the guidelines mentioned above.
• All entries must be posted in this thread by or on the 28th of July 27th of May.
• The host of the competition will judge the winner, mainly on aspects including creativity, funniness and skills.
• Excessive cuteness RECOMMENDED.
• Have fun and be gentle to cute animals!

It depends on what kind of '3D' games you're after.

As the name suggests, RunAGSGame() is for running another game made with AGS only.

So basically it depends on what you can do with AGS.

AGS is not designed for 3D games but with some scripting or plugins you can do some '3D' effects to some extend. There're a couple of threads about making 3D stuff with AGS. You may try to search for them.

Did you ever read my tests? The behaviour of DynamicSprites is a bit confusing. It seems that memory is indeed freed automatically, BUT in some cases the sprite numbers are still valid, so worst case scenario is that if you don't delete sprites when you dispose them things might get corrupted (or maybe, nothing fatal would happen at all), so unless there is some clarification it's still recommended to have them deleted first.

Otherwise, I'm not quite sure why there is a Delete() in the first place, as setting a pointer to null seems to get rid of the sprite anyway. (All right, maybe, it is introduced as a measure so that the sprite is guaranteed to be deleted, in case say, two or more pointers are pointing to the same spite, and so destroying just one of them won't get the sprite removed.)

Oh great. It was fun.

I have an idea for the next one. I'll do some preparation and start a new topic when it's ready.

Stay tuned!

[Result:]

All right. I just have a little test with my idea as posted above.

Test 1
In Enters Room after Fade-in of a room, create a DynamicSprite from an existing sprite, save the sprite number to an integer and then set the pointer immediately to null. Finally, create a graphical overlay using this sprite number.
Result: The game crashes (it won't crash if the pointer is not set to null), so it seems that when you destroy a pointer by setting it to null the engine would destroy the sprite accordingly (memory usage not checked though, so it may still be possible that there is a memory leak).

Test 2
Continue with what has been done in Test 1, but without setting the pointer to null, add some codes in on_key_press() so that it will create a graphical overlay using that saved sprite number, with the sprite number saved in a variable declared outside of functions, and the DynamicSprite pointer declared inside the Fade-in event (so that point is completely destroyed after the function ends).
Result: The game crashes again, as expected.

So, far it seems that the engine is able to dispose of orphaned DynamicSprites automatically. HOWEVER:

Test 3
Continue with what has been done in the previous two tests, but instead of setting the pointer to null, it's now destroyed by creating another DynamicSprite with another existing sprite and have the pointer assigned to it (and with this pointer declared outside of functions to keep it alive).
Result: The game does not crash, either when you then make the overlay with the sprite number immediately, or make an overlay later when pressing the spacebar. However, the sprite is displayed as the legendary blue cup instead of the originally specified sprite. So, it seems that the DynamicSprite is sort of destroyed, but somehow the sprite number is still valid, unlike in the previous two tests.

So, the results are not very consistent and for safety's sake, always Delete() unused sprites for the mean time, until CJ can explain on the actual behaviour of the matter.

AGS could so do with a "switch...case" statement.

Beware that this may make people misinterpret as 'AGS can do so...'.

CJ did make MANY games in the past, just not AGS games.

Wait... 7 years and no masterpiece game?! What have i been doing -_-

Awwww well... 

Why? I have mentioned I am not familiar with this and am not sure about the real behaviour (and I'm just too lazy to find out), but from my interpretation of the manual it's not automatically deleted (unless it has other cryptic meanings).

I just have thought about it, maybe one reason for this is that sprites can also be referenced by numbers. If say you assign a DynamicSprite to say an object or a frame in a loop (by using DynamicSprite.Graphic) and if the sprites are deleted when the pointers are destroyed then the game can crash, though it's really a bad habit to still let the game take reference to a sprite by number if there isn't any pointer to it anymore, as this would mean the sprites can never be deleted.

To test the real behaviour, one suggestion is to save the sprite number of the created sprite to a variable, and then destroy the pointer (either calling CreateBlah() again or setting the pointer to null). Then try to display that sprite using the saved number. If the game does not crash and the sprite can still be accessed, that means DynamicSprites indeed won't be deleted automatically and then we need to take extreme care that we have top Delete() them every time we have to dispose them.

[IMPORTANT:]

But the manual itself states:
(bla bla)

Note this from the entry of Create():

IMPORTANT: This command loads an extra sprite into memory which is not controlled by the normal AGS sprite cache and will not be automatically disposed of. Therefore, when you are finished with the image you MUST call Delete on it to free its memory.

I'll say the manual is quite confusing. I actually am not sure whether a DynamicSprite is destroyed automatically when no pointer is pointing to it, but from my interpretation of this paragraph it is a 'no'.

Edit: Okay, Monsieur beats me to it and I didn't read it.

OMG It.s.just.that.easy? Awwww

I was talking about pre-Ezboard era, got it?

Well, the 2 working in-game screenshot thingie is a rule in this board, so as not to have lots of threads of unprepared and to-be-cancelled attempts. So, unless the game is small enough, 2 screenshots are essential.

Yes.

I'm not quite sure how many in-game rooms this game would contain, but if it only has a few (and that's what I think so) it should be okay to have only one screenshot.

This game seems to be fun.

I've never tried, but I think this could still work.
However, from what I have read in the manual, it seems that a DynamicSprite won't be destroyed automatically when no pointer is pointing at it any more (unlike Overlays, which are destroyed once there is no pointer pointing to it). This would make DynamicSprites a bit hard to use, as you have to call Delete() first whenever you need to assign a pointer to another new sprite (more troublesome is that if the pointer is null calling Delete() will crash the engine, so you have to inconveniently check the pointer whether it is null before destroying the sprite). Careless handling of DynamicSprites (i.e. forget to call Delete() before assigning a pointer to a new sprite, or declare a pointer within a function and have the pointer destroyed after the function ends) can cause memory leak, so I'd expect the above codes would work as intended but would also cause a memory leak at the same time.

Too bad because of the stupid robot.txt, pre-Ezboard threads cannot be retrieved anymore.



...Wait! There weren't any competitions back at the time.

Note also that many games don't come in physical media these days (or, you can choose between buying a boxed copy or a downloaded version), so they don't come with a printed manual. To me, reading a printed manual is different from reading an electronic document (be it text file, pdf file, html page or whatever), drastically different. It's not like you have something on your hand that you can flip the pages any time you like. And honestly I'd rather play a stupid but interactive tutorial than reading an electronic doc. Of course, it's also good if the game provides in-game instructions to do stuff.

All that means is that gamers have gotten dumber and more shiny-object-oriented.

Unfortunately this IS true. This applies to computer users themselves. Compare modern OSes to "ancient" ones and you'd know why.

There is nothing wrong with lengthy "stupid" tutorials, as long as it fits the audience the game is aimed at. There're still games designed for serious hardcore gamers, but usually it is a commercial decision that publishers want to earn more from a larger audience (especially consider the cost to develop a game of a certain scale nowadays; compare it to the past where certain "large" games could be all done by just locking a few nerds in a basement working for hours). A better design is, if you want to serve both general players and hardcore one, give them a choice, like with a selectable Professional mode or just make these dumbed down sections skipable.