Well, I’m done playing with Game Maker for now. Here is My quick evaluation.
For learning Game Programming
9
For learning what is required in a game, required recourses and how they are used
10
For learning objectized programming
9
For learning event driven programming
9
For learning map driven games
9
Really liked the sprite management tool
Really liked the multiple view on games
Really liked the ability to stretch the view on the game
Really liked the view following the player object
Really liked the built in room persistance (can I save and load room? I don't know)
Really liked the one file distribution (only need to copy it)
Really liked that you can set a ZOrder to the objects so you can move behind them
Liked the development environment
Liked the way the objects are structured and work
Liked the way to convert the game features into 3D mapping (Looks good on paper, could not try sample with my unregistered version)
Disliked the collision system and supplied methods to correct errors
Disliked that deviating for the proposed implementation method causes grief and weirdness
Disliked the code writing system (the objectized language is OK)
Disliked that I could not debug or print the value of a variable[edit you can debug and add watch but cannot set initial break point]. Not even in a message box (Not using code)
Disliked that there is no hint in the development environment about what variables and objects are available. Though there are object picker systems and variable viewer, there is no auto complete system in the code editor or a variable picker in the visual programming..
So, if you stick with the implied method for implementing a game then you are OK. Divert from it and there could be trouble (read on).
After playing around with my first game, I started to realise that most of the code that handled things was associated with the main character object. So, if you were to want to add new world objects to the map, you have to go into the character object and add code to handle it.
Also, to deal with weird interaction with objects, odd things were being done like turning off the gravity when hitting and repositioning objects and turning it back on when not touching an object.
This style did not agree with me. I wanted to create generic objects and add them to the map without the need to reprogram the main actor or any other actor for that matter. I want a bullet to kill what it hits, I want a wall to block any actor, I want a floor to support any actor. And so on.
So, I started to transfer code from my old Sonic actor to a newer more generic one. Created a floor object and added the collision event (in ObjFloor) to set the colliding object’s vertical velocity to 0. Not touching the gravity witch I planed to leave to 1g.
This is where I started to be disappointed. The collision event has no generic version so I had to add a Sonic specific collision event. Time for sub classing! I created a generic actor object, derived my Sonic object from it and added a Collide With ActorGeneric event in ObjFloor. Still, I lost flexibility as the floor object is now dependant on the ActorGeneric class. That’s OK, as long as the users of the object do derive their objects from it.
I derived ActorPlayer1 from ActorSonic, set the room with a floor (make with ObjFloor instances), set the rooms viewer to show 30% of the room, following the ActorPlayer1 object (cool)
This is where I saw how bad the collision and the way to handle it was.
The method to fix collision that were detected where not good. I could not reposition the colliding object properly. The collision event seems to be triggered only once so, If I misplaced the character and placed him still within the floor, the event would not trigger again. The vertical velocity would increase until my guy disappeared (It seems).
Plus, the code to move right of left was somehow nullified while the game was stuck in that particular conundrum.
Noticed that the world is drawn before you handle collision events, making my guy bouncy when collision was working as written. If I moved the guy one pixel to high, the gravity would bring him down, the world would be drawn and the collision code would trigger. If I moved the guy one pixel less high (in collision) the code would freak and my guy would freeze for a few seconds (not moving left or right or jump) and would disappear. No, I could not set the guy at the right place, there was no right place, either bouncy guy or code freeze.
I got fed up trying many kinds of way to fix this bug.
I’ll probably get back to it soon. I’ll keep you posted.
|
|
Bookmarks