Just released my first game GeoLander, some thoughts about the project and the GameSalad
Zulfikar
Member, PRO Posts: 11
I just released my first mobile game created with GameSalad, GeoLander. It’s a modern retro-like tribute to the arcade game classics! GeoLander is now available for Android on Google Play. Go check it out and tell me what you think 
.
https://play.google.com/store/apps/details?id=com.zulf.geolander
Some first impressions about the GameSalad and also some tips for the other newbies (most of the tips can be found from other posts too).
Pros:
- Very easy to learn and use
- Has everything you need to create 2D games. No need to improvise or code your own solutions. Just add objects and adjust their attributes, rules and logics
- Creating simple 2D games with this tool is very fast, it'll only take you a couple of hours
- Visual and clear editor, brings me back to the Visual Basic times
- Object-oriented approach
- No need for the boring "bottom level" coding. That is of course a pro only if you don't like the bottom level coding like I don’t
. - Adding in-app-purchases and adds couldn't be made any easier
- Publishing your game is very straightforward and fast, at least for the Android
- I would assume that the GameSalad would be a great tool to educate kids to code
Cons:
- Some strange bugs or features that made me waste hours (couple of them are mentioned in the Tips section of this post)
- If something isn't supported by the tool then you can't do it. You can't add your own code or core functionalities
- Debugging your project is very painful since the GameSalad doesn't have a decent debugger
- Editor could have better mass editing tools and functionalities
- APK file sizes tend to become pretty big since the GameSalad seems to add every "library" or functionality into your project, even the ones you didn’t use
- I couldn't publish to Arcade since it made my game corrupt (fonts and some gameplay functionalities)
- GameSalad’s website gives you the picture that they don’t develop this product anymore. Lots of pages with very old or wrong information (version updates, games of the month etc.). If the product is still actively developed and used I think they should update their website also. It gives quite bad first impression at the moment
Tips (things I learned the hard way during the process):
Read these optimization tips by @AcceleratedGames before you start your project: http://forums.gamesalad.com/discussion/46652/31-optimization-tips/p1 Some of those tips are great (for example 1, 2, 5, 6, 19, 22, 26 and 29), some of them seems a bit superstitious to me.
Timers aren't precise and they have a lots of other problems too. There's a great post by @domenius about the timers which helped me a lot when I tried to tackle the problems I had with timers: http://forums.gamesalad.com/discussion/44707/timers-are-for-chumps-gs-optimization-tips/p1 In GeoLander you get a time bonus that is added to your score after each level. For this purpose I needed a precise timer. Well the timers aren't precise. Depending which level you played the timer could give you 1-3 second different results between almost identical runs! Luckily I found the domenius’s post and found a solution to this problem. There is a much better way to get a precise timer than using timers. It is to use actor’s self.time attribute. I warmly recommend that everybody should read the post linked above and stop using timers if possible.
For some reason you can't save variables in your initial scene. Save attribute function doesn't work in the initial scene. I resolved this problem by moving the save attribute function to the second scene. In GeoLander you can change your initials in the first scene. If you exit the game immediately after this without proceeding to the second scene they don't get stored because of this. You need to press start and enter the second scene to get your initials stored. Of course you could solve this problem also by adding an empty initial scene that directs your game immediately to the second scene. Maybe I’ll add this solution to the GeoLander later on.
Collision shapes don't work. They don't work at all, at least not in the Windows client. I even tried GameSalad's own examples but nope. I needed a triangle collision shape for the ship in GeoLander since the ship is triangle shaped. How I managed to resolve this problem was that I spawn two invisible rectangles (the ship’s wings / and \) that constantly follow the ship. They use rectangle collision shape. They read the same input as the ship and fly in sync with the ship all the time. Quite a dirty way to resolve the problem but I couldn't come up with a better solution. Hope they'll fix the collision shapes soon.
Placing actors or letting them move too far from the visible are will cause crashes or at least so it seems to me at the moment. So you should always kill or handle your actors when they leave the visible area and you don't need them anymore. If you let them move too far this will cause crashes or other strange things to happen. Also don't place you actors too far from the visible area. This also seems to cause random crashes.
Comments
Fantastic. Reminds me lander game on a Apple IIe i had.
I agree on most of your comments but I have not noticed some of those bugs.
I ordered an android phone so I can play some of these games. Will play and leave a review when it arrives.
Looks great.
Some of those bugs you describe are really strange, have never encountered them. Are you on the latest version?
@Zulfikar Nice looking game, professional and very well done. Thanks for going to the trouble of writing up the Pros, Cons and Tips.
I agree that the website is woefully out of date and makes a bad impression.
But then again, so is mine... and I'm a web developer! 
Agreed, the whole GameSalad 'community' / cookbooks / website / blog (and so on) is woefully out of date, doing exactly what the OP alludes to, making you wonder whether there is actually anyone left in the office or if the software still being developed / still viable or whether they have stumbled across a product that closed its doors in 2014
I would assume the new update in fall would come with new documentation? But logic doesn't always apply here.
Yep, hard to say.
Thanks for the comments everyone! I should have the latest version of the GameSalad on Windows 10 (can't check it right now since I'm on the road). Think I'll try to reinstall the GameSalad and see if some of the bugs dissapear. The bug with the collision shapes is the most annoying one...
All of the other bugs / features I mentioned above are quite certain except the last. The crashes (the game freezes on the phone) on Android devices stoped when I took care that nothing goes too far from the visible area. All the crashes were on Samsung's S6 or S7 devices. I have one precise bug report on Google Play. The crashes might have something to do with the adds also, since the crashes started when I put adds to the actors that were huge (I was too lazy to resize them in the first place
).
About the timer problems I had. I have a table which contains each levels target time. My first implementation was that I read the level's target time from this table at the beginning of a level and started to decrease the target time by 0.1 every 0.1 second. This way the results in some levels were totally weird. Sometimes you got about 1800 time bonus and if you would reset the game and try again the same level you would get about 2000 time bonus with almost identical run. That means two seconds difference. So there is something wrong with the timers. This weird behavior stopped immediately when I changed the every 0.1 seconds functionality to a level target time - the actor's self.time. Better solution anyways since you can do that at the end of the level only once instead of every 0.1 seconds.
And about the GameSalad's website, yeah, outdated webpages can really hurt your business. Made me think long and hard before I decided to purchase the pro version since from the webpages you get an impression that this is a dying product. Luckily these forums and GameSalad's Facebook and Twitter channels contained some up-to-date information to prove that the GameSalad is still alive and kicking
.
Just to confirm here, when you say visible area, do you mean the camera view, or the active scene area?
In my case both, since I used the same sized camera view and scene area. Can't be more specific because I haven't tested is there some difference if I enlarge for example the camera view. I didn't need that functionality in GeoLander and it seems I got the problem solved by fixing that nothing goes too far "off the limits".
I'm just trying to figure out what might be causing this bug. If others can replicate it, we can report it to the GS team.
There is a big difference between the camera view and the scene size. No, the camera cannot be bigger than the scene, but the scene can be larger than the camera view, so you can, for example, scroll around or integrate several "screens" into one scene and for example navigate menus without having to load between scenes.
What can be happening, potentially, is as the actors leave -- they get automatically destroyed by GS -- memory is not released and it builds up.
When making sure nothing goes to far "off the limits," do you destroy those actors, or "park" them just past he edge?
The camera can be bigger than the scene.
I think there might be two separate problems. First is related to the moving actors and second is related to the huge actors which contains adds.
Problem 1, moving actors which are spawned on regular intervals, for example once in a second: I destroy them with simple rules like if self position Y < -100 destroy this actor. Before I added these rules the game started to lag on the editor. I can try to make a simple project to test if I can replicate this problem next weekend.
Problem 2, huge actors with adds: The freezing of the app happened on scenes where there aren't moving objects. I've seen the freezing two times myself on my friends' Samsung phones. Both of these times the scene had a huge static actor (touch area) which also contained the show add on top bar function. Seems I got rid of this problem by making the actors smaller.
I've never had an issue with timers at all ?
I wouldn't be so quick to give out general advice like that, these ideas tend to persist for years, someone could say that using the colour green on an actor is more processor intensive than using red, and even though the idea might be nonsense you will still hear it repeated years later !
What were the issues you were having with timers ?
Again, I've never had an issue with custom collision shapes at all, they work perfectly for me.
Again, another one I've not come across ?
What are these other strange things that happen ?
Can you take a screenshot of the timer rule that caused this issue ?
What is a 'level target time' ?
Yep, it's sad to say, but that's exactly the impression I get too.
This really should be two threads.
1)your great game
2)your experiences with GS
I think it's good for honest feedback for the GS team. They won't respond but honest experiences are very helpful.
Timers. I've used them hundreds of times. My games are really just timers with some images thrown in. I find they work well. (I don't use timers with tables though).
I use timers with and without tables all the time, never had a problem. My A* pathfinding system writes and reads to tables frequently: it is set to every 0.001 sec, and manages absolutely fine.
Nice Job!
This thread is getting out of hands, true
. Anyways @Socks here's the screen shot of the timer rule.
The first after 0.1 seconds timer isn't necessary. I started to be desperate with the problem so I tried to add it to see if it fixes the problem. It didn't. Using self.time did fix the problem permanently.
The rules in the picture worked perfectly fine 99% of the time but during the tests I noticed the problems mentioned above. And those problems were totally random. Sometimes the timer worked just fine in the same level and some times not. Restarting the app always fixed the problem. And the level target time I mentioned before is only an integer value I read from the custom table, for example 41 seconds. You can see that part of the code in the above picture also.
And then the collision shapes... Here's a video I just made to show you the bug with the collision shapes:
http://www.viittavaillevalmis.com/wp-content/uploads/2017/02/collision.mp4?_=1
So any ideas how to fix this? A definite bug?
There are also other posts which have information about the problems people have had with the timers (one I linked before) and the collision shapes:
http://forums.gamesalad.com/discussion/93960/custom-collision-shapes-not-working
Lastly the strange things that I encountered when placing objects too far or when not destroying them are mentioned above in this thread. I try to do an example video of the lagging which I encountered when not destroying the actors properly later on.
Hmm, might be wrong here, it's possible GameSalad manages these conversions, but I remember it being finicky in the past.
You say the time in the table is an integer. I assume that game.TimeLeft is a real number?
You are deducting 0.1, so you need to be working with real numbers, not integers.
If you don't mind me asking: what is the reason you are loading this number from a table? Just looking at the screenshot it doesn't seem like a necessary thing, but of course, I've no idea how it's set up. (P.S. I don't think this is the issue, I load, multiply, compare, etc. numbers in table cells all the time, just curious.)
Each level has a different intro text, target time and score limit (level specific general information). That information is stored in one table to keep the things more organized and easier to update.
Timeleft game attribute is a real number, yes. In the table the column "target time" is an integer. I haven't had any problems in updating the timeleft game attribute's initial value from that table.
Makes sense!
Previous issues with timers were highlighted when timers were super unreliable. That's not the case now. You might have been finding a fringe case where the timers were going wrong, but it's not the standard for people to expect. I'm betting the other cases you refer to are years old threads.
The custom collision thing on PC I've seen before, but I primarily use Mac so I've never had reason to look into it closely.
I do this all the time, never had an issue. Again, might be a PC thing or it might be something else in your logic causing the problem (most likely).
Never had this one happen either. Actors will be destroyed if they go too far off the scene (500px) but I've never even heard of actors going too far off and causing crashes. Are you able to provide a test project that demonstrates this? Would be fascinating to see it!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Same here, I must have done hundreds of projects where actors go zooming off the screen (beyond the 500+ pixel death zone) and have never had any issues at all.
Just for completeness . . . you can move actors 500px beyond the scene, for example you could have a rule that says when mouse button is down change x position to 10,000,000 - otherwise change x position to 512 . . . and it will jump between the two positions as you press your mouse button (without being destroyed).
And by the same token you can hide/store actors off the scene anywhere you like, so when an actor is not needed you can store it at x=10,000 and it will not be destroyed. It's only when an actor moves while outside the 500px area that it's destroyed.
Can't replicate this. Would need for me to play the old version of the game for hours with Samsung S6 or S7 phones. However I have Google Play's automated ANR technical report on one of the freezings. If somebody wants it I can send it to you, can't make any sense of it myself
. No reported freezings or ANRs after I fixed the actor sizes but as I stated before could also be something else... like the banner ads. Common to the scenes that i saw freezing two times with Samsung S6 and S7 phones was that they had huge static actors that went way out of the screen and camera size and banner ads in them.
What about the custom collision shapes video I linked, any comments on that? Is there some logical reason for that to happen or is it a plain bug and the custom collision shapes doesn't work at all in the PC client? You said you've never had any problems with the custom collision shapes so am I doing something wrong in the video? All the other bugs / strange features don't bother me anymore since I found a way to tackle those, but the custom collision shapes persists...
When you say static...
How did they move out if they were static? Is it a moving background, or what? Maybe if you give more details...
If it's that rare of an occurrence, it could just be the buildup of memory that causes the crash. It's hard troubleshoot issues that can't be replicated.
I think all of us commenting here are on a Mac, so it's possible it is a PC bug. Nothing you do in the video seems wrong. Definitely worth reporting. I suggest reporting the issue to the GS team, write to them using the chat bubble on the forums, that seems to be the only reliable mode of communication at the moment.
I got two different problems with the actors going far out of the screen and camera areas, sorry if I explained it a bit unclearly.
1) The game started to lag when not destroying the actors that move out of the screen (the actors fell from the top of the screen with increasing speed).
2) The total (and random) freezing of the game in the scenes which had huge static actors with banner ads in them.
If I can replicate these problems I start a new thread, no need to go through these problems anymore in this thread
. Thanks for the comments and some new information.