Hi gang, sorry for not posting last friday (though honestly there wasn’t really much to talk about other than that Ato is still coming along…zzz)

Although it’s not like anyone really reads these because I don’t have 1,000,000+ followers and 50 million likes on my ebaumsworld and I don’t make enough money and I don’t-…yadayadayadayada-…

Pyramid Panic!

Escape the evil tomb of Rah! Collect treasures, like magical gold scarabs and the legendary sword of Rah. Avoid the enemies and score big big big cha-ching…????…????…………………????…

Download (windows exe)

It does not contain viruses, it was made in Game Maker 8.1. (click Start to play)

Controls

Arrow Keys – Move

Z – Use Scarab, scares mummies and makes them killable

X – Activate Sword

There is only One Level. I think there’s a time limit too

Insight

GMA taught me about making something cool…

This game can essentially be considered the final culmination of everything that has been learned from The Game Maker’s Apprentice book.

The biggest thing with this game was learning to take all of the different design elements, like pickups, enemy types, special abilities and combine it all to create a more fuller game experience (even though the experience may be short).

Movement system

Some of the biggest aspects that I remember the tutorial emphasizing was the grid-based movement system, much like old school RPGs where you’re locked into a grid even though there is movement. Essentially this is achieved (at least in the tutorial way) by initiating a variable, let’s say “canmove=true”. if we’re in a part of our grid that when rounded down makes it a whole number, canmove is set to true, however when it is not, then it is false.

if x mod 32 == 0
{
___canmove = true
}

The first if statement makes sure we are in a 32 rounded position, so every 32, 64, 96, etc spot on our grid will always work no matter how big our room is. (modulo essentially is just divide, but instead gives us a remainder value (super useful!))

When canmove is true, we can then have it check for an input, which in our case is one of the directionals.

if canmove == true //(we are still and awaiting to press a movement key)
{
___speed=0

___if keyboard_check_pressed(vk_up)
___{
______canmove=false; direction=90;
___}
}
else //(we are moving and cannot press a button until we hit a grid spot)
{
___canmove=false
___speed=1;

___if x mod 32 == 0
___{
___canmove = true
___}
}

This code might look complex, (though honestly this is a really tu-toriel (I’m sorry) way of doing this) but basically, whenever we are moving, we prevent any inputs from being read and still keep applying speed. However when we are in a rounded position, i’ll take the same code as before and make us then stop moving, allowing us ot read our next input. Obvious I cut the input section short (keyboard_check_pressed) and didn’t wright inputs for left,right and down but I think you get the idea…

I won’t go too much in depth, but there were other mechanics like the lighting system, scarab power, sword ability and (to me the most intriguing one) the mummy AI.

Lighting system

I think the lighting system was using a sprite of a circle, and we ran some fancy code to mask out a hollowed out circle, so essentially we made a cookie cutter template and instead the dough covers our screen and we made a round hole in the center. A pretty decent way to get cartoon platforming transition effects as well.

Scarab and sword power

Not gonna go super in depth here, the scarab when touched, adds +1 to a scarab counter for the global variable.

global.scarabcount += 1;

and if we use one we check to make sure we have one and just remove it from our inventory.

if keyboard_check_pressed(ord(‘z’)) && global.scarabcount > 0
{
___global.scarabcount-=1;
___alarm(0)=300; //activate our scarab ability timer!
}

The sword is actually very similar, except it tracks gold and is based on a held input state. The only different is I think it swapped a larger circle sprite for the light mask.

MUMMY AI

Hoo boy, I can’t really remember too well how the mummy AI worked, but I can still give my own insight as to how I think it was coded…

Basically the mummy object has 4 different states, “wander“, “search“, “chase“, “flee“.

When it is in wander state, it will just randomly choose a direction to move when it’s canmove==true. (see how it comes around again?). if it wanted to move into a direction but runs into a wall, it chooses a different direction. Now if we use a special command called distance_to_object(obj_player), we can grab the range from which the mummy and the player are and use this to change it’s state, which if it’s senses we’re nearby, it enters it’s search state.

When it is searching for us, I think it speeds up it’s movement slightly and will generally favor moving in a direction that could be towards us based on randomness. I believe if it happens to roll the right number when it’s canmove is true, then it’ll choose a move direction that would likely move it towards us. Which I think it also uses a direction check to then decide which way to go since it only moves in 4 directions.

Now for the mummy to enter its chase state, we need to use !collision_line(x,y,obj_player.x,obj_player.y,obj_block,0,0), this simulates vision for the AI. Don’t fret too much if this looks super complicated, all it’s trying to do is check if there’s a wall between itself and the player. obviously it wouldn’t make much sense for it to see us through the walls, so we use this function to check for that. Combine this with a distance check to the player, and if it’s close enough and there’s no wall between us and the mummy, the mummy will chase us! Oh noes!! Now it tries to choose directions that will likely move towards us Aaaah!!

uhhh…okay…

So what about the fabled flee state? how does this happen? How do? What do? How is? Why was? Who could? When should? Who what where when how?

So whenever we activate our sword ability, we run some code to tell all mummies to enter flee state and set their flee alarm to a certain value. From the player’s side this is what it might look like…

if keyboard_check_pressed(ord(‘x’)) && global.goldcount > 0
{
___global.goldcount -=1;
___if instance_exists(obj_mummy)
___{
______with(mummy)
______{
_________RUN LIKE HELL (you get the idea…)
______}
___}
}

This code snippet just simulates what it might look like (again this is just tutorial level coding and not advanced Einstein rocket science elitist code).

Anyways that was definitely super technical and anime, but I hope maybe this gave you some insight as to how some this very last Game Maker’s Apprentice game was made. As you may know, this was only the stepping stone to bigger and more challenging prospects. I hope that by sharing this, you’ll see that I came from a background where I had absolutely no clue how to program, I didn’t understand how to logically code/script games and through carefully studying tutorials and open source code, it eventually got me to where I am today…

…a guy who still makes games and isn’t making any money

A guy who can make teh vidya gabens.

I will likely continue sharing my old works, abandoned projects, test code, game projects I studied that I learned from…you name it!

Hope you enjoyed the read!

-Brandon

www.tinywarriorgames.com

Youtube

Twitter

Discord

It’s a me a brandon letsa go.

Tic-Tac-Toe

…

It’s tic-tac-toe

What else is there to say?

Download (windows exe)

It does not contain viruses, it was made in Game Maker 8.1.

…

No but really what’s the deal with this? Why would I make such a deep, intricate and complicated game from following the Game Maker’s Apprentice tutorials? If I recall correctly, this segment taught me about using scripts and A.I.

Scripts are useful files you create that can help streamline things like duplicating huge blocks of code for more redundant functions.

Example: In Ato, all enemies share the same “launch” state, which means they all pretty much use the same state script to make them properly have the same rotation and behavior. By using a script I don’t have to copy the same huge chunk of code and possibly risk human error.

Scripts are simply a means of giving you power to organize your code and create your own functions for doing stuff like position checks or A.I. behaviors, etc.

Frog Hop had a gigantic (and terrible) script that checks whenever you collide with an enemy and then goes through a list to find the one you specifically collided with to check for things like their attacks, if they’re protected, special status etc.

In terms of A.I…

A lot of my games like Frog Hop just have the A.I. utilize timers to change their sprite and attack timings, sometimes they have collision rectangles if you’re in range of an attack. Things like running into a wall also have to be checked for turning around, especially depending on the animation (because if you had an enemy turn around when touching a wall, you’d have to turn it off depending on their animation such as an attack (otherwise they’d flip back and forth while attacking).

The A.I. in Nameless get a bit more complicated with using path-finding from the A* Algorith (A Star). I’d have to check if they have vision of you and if they don’t, they rely solely on the A* pathfinding to navigate to where they last saw you/where they heard a gunshot. I’d say the A.I. in this game was a bit more complicated than Frog Hop. Since there was a lot more to check in terms of going into certain states and exceptions when stunned or hurt. Actually, probably the most difficult part with coding this A.I. was actually their dimensions, since most top down games have characters with even dimensions vs having tall sprites.

Now if you want to marvel at complex A.I., take a look at none-other-than Franchise Wars. Programmer, Austin Huebner did an excellent job on the A.I. when it path finds it’s way through the map and check for things like properly positioning itself to attack. (The example below does not demonstrate it but uh….yeah)

I can’t really remember too much about the Tic-Tac-Toe AI other than that depending on certain circumstances it picks a random spot sometimes to at least simulate human error, otherwise if it knows it can score the last point it will go for it. So basically it’s designed to be extremely smart and make the best move, but randomness is also applied and will sometimes make a dumb move (if it’s not a winning/blocking move).

Tic Tac Toe can only go so far with A.I. behavior (which is probably why the tutorial wanted to teach it through this game type). Since really if you wanted to make the A.I. super easy, you’d just make them make really stupid moves that don’t block, don’t line up or give them a chance at score (or just make them purely random). And to do impossible difficulty you just remove the randomness.

enjoy,

-Brandon

www.tinywarriorgames.com

Youtube

Twitter

Discord