What I Learned Building My First GameSalad Game

JEG2

I have published my very first game to the arcade.

Don't get too excited, it's just a snake game clone I'm calling Desert Snake. It was the first standard exercise that I thought of that wasn't one of the templates.

I'm a total game building newb and not a designer. The end result reflects that, of course. Still I learned some things with this exercise and I thought I would write about those details here in case it helps anyone.

For context, I should probably note that I'm a non-game programmer. I approach GameSalad from that viewpoint. I know the motto is "No Code," but that's silly in some ways. Creator is just a visual programming language. I really wanted to see what I could and couldn't get it to do.

So here's what I learned…

Successes

I made a ton of rookie mistakes, but I would say that I did get at least one bit pretty right. I wanted to see if I could get the game to not care about resolution. I position objects in the game relative to the Display Size and I run the wall around the board using a Display Size aware building process.

I had a few reasons for trying this. First, I wanted to know if it would be viable to prepare a game for various sizes without rewriting it. I'm sure it gets more complex with games that do more than mine, but I what I did wasn't too tough.

I also used the building process to feel out if I could do something like procedural generation in the future. This was pretty different from my standard programming. Normally I would write some loops and use fancy code. While that's somewhat possible in GameSalad, I feel like it fought against me when I tried to work this way. Instead, I had an easier time using a visual process, with actors moving around and spawning other actors. I didn't mind this strategy once I figured it out.

Another "success" sure looked like a failure for a while. I wanted to make sure my game used some data structures, so I could see what GameSalad could be pushed into doing. I decided to queue moves for the snake mainly in service of this goal. (You can quickly push up, then left, and it will execute those moves as it reaches the proper points in the grid.)

My first attempt at this was to use tables and I definitely when down swinging. I think they main issues were:

• Tables are harder to debug due to their behind-the-scenes nature
• There are some bugs in tables that I ran into (I'll try to reduce these to small examples and submit them)
• I tried to make it way too complicated

Defeated by tables, I decided to build a kind of linked list out invisible actors. Again, I took a beating. The process I tried kind of worked, but I quickly got into some scenarios where I had to know the exact timing of certain actions. Will the system run this step now or add it to a queue of things to do. This could work for some applications, but it gets hairy quickly if you can't be sure of what happens when.

I buckled at this point, pulled down a snake game template, saw that tables were indeed the answer, and attacked it again in a manner more like what I saw in that example. This works, but it has some minuses that worry me. For example, the tables in my game grow infinitely as a level is played. This is probably fine for the few numbers used in this case, but I'll want to keep refining these techniques, if possible.

Failures

Most of my failures are about game techniques that I'm just not familiar with yet.

I tried using physics to move things around, but this ended up causing me fits. I wanted a grid based movement. In the end it got easier when I just handled movement myself.

Collision detection was a big help, but I didn't plan for it well at all. My snake would run into his own body segments when turning corners. This is why the snake ended up so small and with awkward gaps. I was compensating for my bad planning.

You live and learn though and I do think I will handle at least a few of these things better in the future.

I hope this is helpful to anyone else that's learning.

If anyone sees obviously silly things in what I have said, please correct me or tell me which manual I should go read. I love to learn.

Thunder_Child

Testify !

Socks

@Thunder_Child said:
Testify !

Lol

Socks

@JEG2 said: . . .

Good write up, and well done getting a working, playable game completed.

Looking back on my first experiments with GameSalad I'd say my most obvious mistake was using overly convoluted programming to achieve simple tasks, I recently opened an old attempt at a game where you move your player around the screen by steering it left and right as the player moves forward, you'd think that was an easy enough task, and it is, but my programming was stupidly complex with all sorts of weird and wonderful pointless checks and toggles and conditions that are - in hindsight - entirely unnecessary.

That's the one thing I've learned over time, the more I've used GameSalad, the more and more simplistic/straightforward my programming has become.