Wednesday, October 3, 2012

Game Maker: Physics Engine and Globals

Physics Engines are one of the greatest things that a developer needs when making a game (especially a platformer game). It makes collision detection vastly easier and creates smoother transition and motion that looks more normal. But there are so many engines out there and half of them defunct. Finding a right one, then hooking it up to your project, and making sure it works correctly is no small task.

For Fallen, I have to link up a physics engine to make collision detection easier when the sprite moves and jumps on platforms and slopes. The built in functions to do this are too jagged and sloppy and are just simply horrible and convoluted to do anything useful. Thus I had to hook up a physics engine to my game. That is where the problems started.

When I first started looking I came across an engine called GM Physics. It seemed promising and the initial reviews for it were favorable. I hooked it up and looked at the demos to see what to do with it. The demos has no comments explaining what each function did and when I looked online to find out, there was no documentation of any kind. This proved problematic as I had no idea what to do with a library that didn't tell me what it could and could not do. I spent a good 2 hours trying to find something to help me with the engine, but to no avail. It was when I came upon a forum when I found out that the developer had stopped development some 2 years ago and had many internal bugs that were not going to be fixed any time soon. I had to give up my search with GM Physics and try again.

I started my search again and came upon an engine called Extreme Physics (http://www.maartenbaert.be/extremephysics/). I found out that the developer has not given up on it and is still coming out with updates for bug fixes. This was my first good sign. There were some good reviews on it too, and the fact that there was a page of documentation explaining what the functions were called and what they did. The explanation and the documentation is poor in my opinion, but it was better than nothing and what I've seen from Game Maker, it is the best I'm going to do.

I hooked it up and followed the demo on how it did collision detection for hitting into boxes. I was initially stuck since when I hooked up the bounding boxes to the player and the platform box, the player always started out knee deep into the floor. Upon inspection and a few hours of agony, I was able to figure out that the way I set up the bounding boxes, was wrong. When I made the box, I set the width and height as the right numbers, but the x and y coordinate was wrong. I set is as 0,0 which should make sense if the way it sets it up is like any other language sets up a box. However, this apparently offset the box down and to the right since my player would get stuck down in the ground and get stuck to a wall if he jumped to the right, but not to the left. The way I had to fix it was to set my x and y as half the width and height. This fixed my problem and my player can jump on platforms very smoothly. I really hate when developer don't explain details like this and assume that you should know. Its okay for developers to stray from convention and what other languages do in a similar situation. But you have to explain why you strayed and how the new way works to avoid people spending hours figuring you weird convention out.

Starting to feel that I have this collision detection down, I started to work on the player walking up and down ramps. This requires the use of a bounding triangle. The way that I did it was by creating a polygon and attaching it to the ramp. I created the polygon as the documentation and the demo instructed. I even attached it as the demo showed. However, that was not enough as a error showed that said the polygon was not convex. I thought this impossible, because a triangle only having three sides would only be convex and never have a vertex that defiled the meaning of a convex polygon. Instead of fixing it, I decided to take a break already spending several hours just that day figuring out two different engines and running into many brick walls.

When I had finally came back to the problem, my initial guess was not that it was or was not convex, but that I just built it in the wrong order. Past experience has showed me that when you build a polygon, that if you construct the vertices in a counter-clockwise way, then the side that would be culled would be facing towards the camera and that in order to get the right way showing was to construct the vertices in a clockwise way. I thought that this may be the same reason too, but for some reason didn't pursue it. About 30 minutes passed of playing around with values with no result was when I decided to construct the vertices in a clockwise manner. To my thrill it worked, my player could walk up and down ramps now. However, the motion up the ramp is still jittery and I believe I can fix it, I just need to play with the values a bit.

Hooking up the collision detection took a vast majority of my time, but when I wanted to take a break from it (after I got the platform and ground working), I decided to add two different rooms that were part of the level. In order to do this I needed to keep track of what the previous room was so that the player could end up in the right spot in the next room and facing the right direction.

I created an exit trigger (just a square), that would start the event to transport the player to the next room. If this was regular code,then each instance of the object I created would have a global variable that showed what room it was currently in so it would be easy to set up the player. At this point, my interpretation of how variables worked was based on how other languages did it. There are three ways to set up variables  in Game Maker:

  1. global.varName
  2. var varName
  3. varName
My initial misreading of the documentation was that to var and global.varName was the same way to set up a global variable while varName was a local variable that would only exist for that function (script). I also initially thought that a global variable was only global for the object. Then when I did obj_name.global_var did I figure that that didn't work. So I decided to create a getter method that would return global.varName. Game Maker didn't like that either and would always throw a bug when I did it like that. I spend a good hour online trying to figure out what to do when I came across a youtube video explaining variables in Game Maker. It was the moment that he said that global.varName would create the variable that was global to all objects in a game did I realize that I had it all wrong. 

I went back to the documentation on variables to see what else I got wrong, when I figured out that varName was global to the object and could be called like obj_name.varName and that var varName was only local to the script it was in. After this realization, using variables and being able to pass them around became significantly easier. I will have to go back in my code sometime and change around variables that were initialized under my false presumptions to something that actually fits convention and good programming style. 

I have now figured out that Game Maker has changed the game on many things with programming from what they normally are in more C based languages. I now just wonder how many more surprises I will face.

No comments:

Post a Comment