How many rules are too many rules?
jhaas
Member Posts: 233
I've noticed that as I add rules to my game, it can begin to have an effect on the on screen movement. The animation has little glitches as if there is more logic to perform than can be done and refresh the screen in the allotted time.
Is this due to too many rules on my part or will this correct itself in the final compiled iPod version of the game. As in interpreted code vs compiled?
Right now all my animations runs at 12 fps.
Is this due to too many rules on my part or will this correct itself in the final compiled iPod version of the game. As in interpreted code vs compiled?
Right now all my animations runs at 12 fps.
Comments
i've had those same glitches that you speak of as i made my way through different iterations of my behavior setup, before i got it working satisfactorily.
i found that those glitches were conflicts in the rule setup i had. i had to do the ole' fashion traceing variables through the rules, at least until they enable the debug console ...hint, hint, and codemonkey helped by explaining some of the movement conflicts that exist between behaviors. once i sorted out the movement behavior conflicts it behaved as expected with no glitches whatsoever.
as a matter of fact, the working rule set i ended up with is almost three times bigger than what i started with. so i know the amount of rules doesn't effect the run time as much as what they are doing.
codemonkey put out this link in the wiki describing how to avoid or find those conflicts...
http://gamesalad.com/wiki/how_to_know_which_movement_to_use
hope that helps...
my bad jhaas, you didn't fully explain the nature of your glitches in the first post. this sounds like it could be something going on in the background related to your continued replay.
try this, increase the number of lives significantly and just keep playing the game to see if you get the same sluggishness over time. if not, that might narrow it down to something with the replay.
i have had the problem that the graphics of some of my actors are getting unsharp or darker everytime i replayed my games...
so i have found out that i have to destroy these actors before changing to another scene... some of my actors simply spawned again when replaying while the original actors were still alive in the scene...
cheers
SDMG
Another user controllable actor has a small walk cycle when pressing the left or right arrow keys. This version does not have a replay and I'm letting the program just run.
Using the Mac activity monitor I noticed the "Real Memory" usage of game salad climb from about 80 meg to over 190 meg in about 15 minutes.
Is this something to be concerned about? Is memory not being freed properly through the spawn/destroy cycle and the animation cycles?
I've noticed the same behavior on the more advanced version, only it happens much more quickly due to additional scoring and status graphics.
I'd really be curious to see if this is a behavior of the simulator only and will not persist in the iPod device testing. Right now I'm concerned that this memory issue is causing the sluggish glitch behavior and has little to nothing to do with my specific project.
I just checked the memory usage again and it's over 240 megs and growing.
Suggestions?
yeah, i don't think it should be snacking on that much memory.
question, are you running your test from the 'scene' editor preview or from the 'game' preview? i don't even know if it will even make a difference, but you might want to repeat your experiment to see if the memory consumption continues in both previews.
you could also try disabling or removing your player actor and seeing if the spawned ones create the memory buffet by themselves.
I'm not sure what you mean by "scene' editor preview vs game preview. By scene do you mean hitting the green preview button at the top middle of the screen? And by game preview do you mean web preview? Is there another option I'm missing?
the top middle green button is the game preview. when you are editing a scene, there is a pause and play button, side by side, in the top middle of the scene editor window that you can use to preview that specific scene.
you can isolate the cause a little further by either removing your player actor from the scene and running it, or running your player actor alone in an empty scene and observing the memory usage. that may help you narrow down what's causing the slow down.
Background jpeg image 480 X 320 48K
Nine animation png images 150 X 150 8K each
The animation behavior was placed on the actor to loop the animation images.
Ran the game preview for 5 minutes - Activity Monitor Real Memory went from 63 megs to 80 megs after five minutes of animation looping only.
Deleted actor and left back ground image only. Restarted game salad and ran the background image only game preview for 10 minutes - again memory usage went from 63 megs to 80 megs.
You asked me to try and determine what would cause the slow down. Based on this it seems that ANY logic and graphics of any kind will eventually bog down and cause the glitching slow downs I'm reporting. The more involved the game, the quicker the effects surface.
I'm not sure what else to do, I thought my game was relatively simple. I had a background music track, some animation, sound effects, but all on a static screen. I'm not sure how any game that has an execution time of more than a couple of minutes will avoid what I'm seeing. Does anyone else have an example of a game that can run for an extended period without suffering the same issues?
Now what I don't want to abandon the project, but based on the above I'm going to need to see how this performs on an actual iPod before I can justify any further work on this. Any chance I might be able to beta test the preview app?
great work jhaas tracking that memory usage. i think this memory usage is something that all the chefs here should look into on their games. it might help the head chef narrow down the cause of whatever it is that is happening.
sorry it's screwing with your game development. i want to stick with gamesalad too, because it shows so much promise. we'll have to ride out these initial bumps in the hopes that as the software matures it will be worth the wait.
When I said abandon the project I didn't mean dumping game salad - rather I meant holding off on such an ambitious use of graphics until the software (or my use of it) can handle it.
I'm totally sold on the software and it's potential - to give you an idea in here's what the game does...
(This is not a "look how brilliant I am" posting but a somewhat high level example of all the things I'm getting the game to do which could explain the bogging down I'm experiencing)
Every two seconds an animated bear flings a magic wand (complete with particle effect magic) When he does this one of 3 random sound effects is played.
Then the game calculates if a small "good" object or a large "heavy" object will drop from a random x position from the top of the screen.
If it is a "good" object the game randomly assigns one of 5 different images to a newly spawned "good" actor
If it is a "heavy" object the game randomly assigns one of 3 different images to a newly spawned "bad" actor
Meanwhile the controllable "bear" character via left right arrow keys has a small animation that plays as you try to guide him to catch the "good" items and avoid the "heavy/bad" items.
When he collects a good item - the score goes up, a sound effect plays, the good item actor is destroyed.
When he is clobbered by a "heavy" item - his image is changed to a face down image while one of 4 impact sound effects plays and the game holds for two seconds. The "bad" actor is destroyed and the game continues.
Round 1 is to collect 3 of each type of good item - as you collect the groups of items a small image of the completed object appears on screen.
Round 2 is to collect 5 of each type, and the odds of getting a bad item increases.
There are 3 lives, so once you get creamed 3 times game over. You have an option to replay on the "Game Over" screen.
That's what I have going on thus far, I want to add a few more scenes with different types of game play, but I've got to work through the performance issues first. (Or if it is a software memory issue - wait until the chefs have a solution).
It seems like a simple concept but it is a fairly involved blending of animation, random numbers and rules. The beauty of Game Salad is I got to this level of complexity in less than a week (working part time on it). And for a few minutes at least it works flawlessly.
I know we'll get there, and if my game example can assist the chefs, if they want to email me I can send them the game if they want to see if they can figure out if it's my use of objects or is a memory, resource issue.