The doors
The next major hurdle with Paradroid was implementing one of the most iconic parts of the game which was the opening and closing of the deck doors using simulated proximity checks when any droid approached them. Just like the automatic doors, you find in shops which detect a person coming into the sensor area and open until the area is clear. The doors in Paradroid were designed to work the same way for both the player and AI controlled droids.
The first idea on how to do this in the code was to use the same tilemap I built for the wall collisions and to adapt it to also trigger for collisions with doors, terminals, lifts and the charging stations. With a controlling object handling all of the collisions within the game loop. Not a hard thing to do but it did end up being much more complex than I felt it actually needed to be.
The better idea was to place a hidden object in the area that was to act as the switch to open the door and this would be triggered by the player or an enemy droid when they collided with it, even though, to the player, nothing would be seen. When I first started coding the map and droid handler system for this game, I was using Unity and it turned out to be actually a lot easier than in Game Maker Studio. Unity has built-in events for collision start and collision end areas so that made it very simple to start the door opening and closing at the correct times.
After we switched development systems to GMS, I started hunting around for a way to do this again but soon found that, while I could work out the collision start – there is an event for collisions – there’s no actual event tied into it. A timer was out of the question because either the player or an enemy droid, could still be in the door when attempting to close it. For example, if the player is being pursued by one of the more security conscious droids. While it could make an interesting gameplay mechanism, it’s not what this game ever actually had.
After a bit of RTFM – read the <cough> manual, for the uncool kids – about events in Game Maker Studio, and a question or two shot out to Mike Daily via Twitter, I went with a solution that works on four different events that are attached to one Object. Not as scary as it may sound if you’ve never used Game Maker Studio before.
- When a collision occurs between an object and the “hidden object” a flag is set. The door hidden object is shown below as a circle with rectangle going through it. In total there are actually three types of door objects. Horizontal, Vertical and what we’ve come to call “Stupid door” – mainly because it doesn’t seem to actually serve any function. *collision_event*
- At the start of every frame, the Door object has a flag set to say I’m not being activated. It doesn’t actually say that because doors can’t talk. I’m sure you get what I mean, though. Right? Erm, yes. Ahem. *begin_step*
- At the end of each frame, a check is then made to see if both of the previous flags have been set. If they have then we set another flag which activated the code that does the animation of the door this collision is linked to. *end_step*
- Finally, in the frame event, we check if the door we’re looking at is animating, and what direction the animation is using (open or close). We then play the next frame of the appropriate animation. The extra collision tiles are added, or removed, depending on the doors direction *step*
- Once we have played all animation frames we then set the third flag back as the door has finished animating.
- The door affected naturally is made to stay in the open state until the collision state does change.
It does sound a bit complicated when you write it down but, believe me, its a lot harder trying to explain it, than actually getting the code in place and working!
As you’ve only seen still images until now, below we have a video showing the doors opening and closing as the player droid is moving around. A lot of work for something most people will barely notice, unfortunately. But there are people who do and will appreciate that the effort has been put in to make sure it’s working right.
Going Down – conceptAlpha
November 28, 2017 @ 3:26 pm
[…] the doors all working, as I explained in the previous post, the next logical step was giving the player the ability to move around the whole of the […]