Game Maker & Collision Fun

Hello my readers!  From now on, I’ll be updating the USCF blog each Sunday with development progress on Fight the Darkness. Cheers!

Last week I purchased Game Maker Studio Professional, and since then I’ve been stumbling through the free tutorials. Now that I’ve got a little hands-on knowledge with the engine, I’ve been working on a prototype of FTD. For the prototype, I’m just making one level, using the layout from last week’s diagrams.

roomComparisonProgress

Right now, I have the prototype built so that the player can control the “Light” character and open doors. Unfortunately, the player character likes to ignore the collision on walls (despite the walls having collision), so I’m going have to find a way to fix that. What’s interesting is that the player character ignores wall collision, but responds to the collision of doors (both open and closed). While I want the door’s collision to impede the player character’s movement while closed, I’m going to have to find a way to switch off collision once they’ve been opened.

progress003

Also, the player character will take keyboard input from the player in any WASD direction, but they never stand still. I think this might happen because I have one of the actions in the Light object set to fixed movement, as opposed to free movement.

I haven’t implemented the other four characters, the Darkness, or the glyphs yet, as I’m still learning Game Maker as I go. I really wish I could accomplished more mechanically this week, but the collision bug is tripping me up in particular.

I guess it’s not all that bad, because working on one feature at a time allows me to check for as many bugs as I can, fix those bugs, and save that version before I go adding any new features. It also allows me to pinpoint at what point exactly a bug appears and what feature is instigating the issue.

Back when Comrade Quest was in development, there were times when multiple features were added to the game and many bugs appeared. It caused a lot of headache for my programmers and designers because it was difficult for them to get a reading on what feature was causing an error. Granted, when you’re working on a team and you have deadlines to meet, sometimes adding multiple features at once is a must, but I try to keep additions incremental when possible.

It’s way ahead of my pipeline development-wise, but I’ve been contemplating FTD’s aesthetics. I’ve thought about rendering the game in pixel art similar to the old Pokemon games, but I also would really like to emulate the style of Kikiyama’s Yume Nikki. I want FTD to have a surreal, nightmarish aesthetic to it, and both styles could work quite well.

yumenikki

creepomon

Honestly, I know I can’t spend too much time thinking about the art direction at this point, because I get so wrapped up in the visuals of the game sometimes that forget about the game. For now I’ll just keep all that on the back burner.

As far as what I’d like to get done this week for FTD, I’d like to get all the collision kinks worked out and the other characters implemented (not necessarily their abilities, just the ability to control them and switch between them). If I get all that done I’ll move on to getting the Darkness and game timer implemented.

Well, That about wraps it up this week for the dev blog. Until next Sunday, USCF signing out.

Post commandeered by the US Claire Force