Time Throttle: Dev Journal 10

posted Mar 26, 2018, 11:28 PM by Good Idea Games

---I just found this old post that was in the queue, but never got published. Oops!--

Tonight's schedule is targeting 2 goals:
Bug fix: my player object gets stuck on walls.
New feature: laps, and fix scoring.
These should be straight forward.

Apparently it's very common for sprites to get stuck on walls in Game Maker, specifically if developers are using 'image_angle' to rotate their sprites. Which I am. Apparently this creates a situation where an image gets rotated such that the collision mask is overlapping another object's collision mask, and they get stuck.

The solution is to rotate the sprite separately from the mask (use a separate variable), and check whether the new position is colliding with an object before I move the mask to catch up.
Alternatively, in the event of a collision, I can also add a sort of 'bounce' to move the objects away from each other.
I'm going to find out which is simpler.
... 1 hour later...
None of the above helped, but I found by setting my player object as non-solid, the issue was largely alleviated. I'm going to accept the walls being just a little sticky, since this is a POC.

I also fixed my scoring.. it was an index access issue. player instances start at zero.

Object Stuck while Rotating!
This code block was hilarious. Somehow, when my object got stuck to an object, a little movement would unstuck me, but I would teleport to the same location of another instance of that object. Good Times!
Apparently 40% of the posts in some forum were about this problem, so someone wrote a handy guide!
-Setting my player object to my be 'solid' helped a bit.

Time Throttle: POC 3 Bug Fix

posted Mar 26, 2018, 11:17 PM by Good Idea Games

Here's a lesson for you: 
Don't modify a list while iterating over it.

I had an exciting bug in Time Throttle that would only show up when I tried to play the game with friends.
Sometimes a player would end up with a permanent boost to their speed and rate of fire. And some players would *occasionally* end up with permanently reduced speed and rate of fire. It was terrible, and it ruined every game demo I tried to run over the holidays.

These things are controlled by their player object's 'time_mod' value, so *clearly* there was something going on that was not restoring this value properly.

It turns out, while destroying a Time sphere, IF it's because the lifespan ran out, I was doing it wrong.

///When Lifespan runs Out, Destroy Time Sphere, Undo effects

if life_span <= 0   {
    //iterate through affected objects, and undo the time mod
    show_debug_message("Time Sphere "+string(id)+" has died of natural causes")
    //only check if the list has affected objects...
    if(ds_exists(affected_object_list, ds_type_list)){
        var i;
        for (i = 0; i< ds_list_size(affected_object_list); i++) { //ALT: remove i++.
            var object_instance_id = ds_list_find_value(affected_object_list,i);
            //Confirm that the affected object still exists...
            if (instance_exists(object_instance_id))    {
                 with (object_instance_id)  {                                        
                    //remove object_id from list of affected objects                    
                    //restore object physics motion
                    phy_speed_x *= (1/other.time_factor)
                    phy_speed_y *= (1/other.time_factor)
                    phy_angular_velocity *= (1/other.time_factor)
                    //image_speed *= (1/other.time_factor)   /*note: this causes player sprites to flash*/
                    //restore object's time_mod
                    time_mod *= (1/other.time_factor)                    
            //NOTE: affected objects do NOT need to be removed from the list, since the entire list is destroyed.               
    //Destroy List and Object
    //Note: affected object list destroyed in 'destroy' step

In the case above, the first object affected by the time (object [0]) would be handled just fine. This is why my solitary troubleshooting didn't detect the bug. But as soon as you add more affected objects (players in particular), shit gets real.

Let's say object[1] is another player, now with a hefty speed boost. 
I enter my for loop, with i==0, I delete object[0] from the list, and restore it's physical properties. Then I increment i.

UNFORTUNATELY... object[1] is now the first item in the list. It's object[0].
And I go to town on object[1]. I delete object[1] from the list, and restore it's physical properties.
Iterate over every object effected by a time sphere, and fully have the objects that were in the thing won't get their rightful properties restored.


BUT! Now with this fixed, I can focus again on tuning the game play, because even though Time Throttle has been "complete" for 3 months, it's only been "playable" for 14 minutes.

Implementing Input Dog

posted Dec 5, 2017, 3:22 PM by Good Idea Games   [ updated Dec 5, 2017, 3:23 PM ]

Time Throttle has some major issues with its controller input. Most significantly, the menu can only operated by game pad device ID 0, and apparently if it gets unplugged, Windows reconnects it as Device ID 1. Long story short, if I unplug a gamepad, I have to reboot to play Time Throttle again.

Input Dog is a Game Maker asset that should address this.

To familiarize myself with this asset, I'm going to start by importing it into a blank project, and walk through it's intended functionality in this article.
I am pleased to say that input dog works right on import, though as I type this, the little dogs are moving around and my controller vibrates every time I hit 'm'. Apparently it doesn't care whether the associated application is in an active window or not.

Configuring Input Dog
Input Dog starts by opening the 'rInputManager' room, which creates a unique InputForPlayer object for each player in the game.  This loads a pre-defined configuration for each player, where named game functions are mapped to one or more inputs. 
For example, in the screen shot to the left, you can see that player 1's game function "bark" is mapped to N, or gp_face3.
The actual game effect of "bark" is defined as a part of the Example Dog object.
Input Dog then transitions to 'rExampleRoom' where it loads an Example Dog (player) object for each player, and a mouse-clickable button to transition each player to a special room for configuring their controls.

Off the shelf, these controls are limited to a single keyboard command and a single joystick command. 

Input Dog appears to assign game pads to players on launch, and each player can only accept input from a single game pad (though interestingly, a single game pad can control multiple players). 
Input Dog seamlessly accepts input from both X_INPUT and DIRECT_INPUT devices, which means immediate compatibility with more devices.

This is already structurally similar to Time Throttle, where player craft are immediately playable in the configuration menu.

Like in Time Throttle, player controls are defined as part of the player object itself.

I should be able to replace my current gamepad button checks with inputdog function calls, and even without understanding how inputdog works under the hood, I suspect for most functions this will just work.

To Be Continued...

Time Throttle: POC 3 Complete!

posted Nov 22, 2017, 5:25 PM by Good Idea Games

Riding the hot wind of my successful POC2, I jumped straight into POC3: Feature Parity within Game Maker's Box2d Physics Engine.

Using the physics engine solves a bunch of problems with POC2, like object collisions feeling unimpactful player craft handling feeling 'floaty' and player pawns getting stuck to walls. It also opens a lot of avenues for novel game play, where I can introduce props and objects with interacting physics effects, like gravity wells, chains, oil, etc.

And let's not forget that it will also make it easier to implement player-built craft! 

So this is something I want. Baddly.

I've been spending a few hours on this migration every day, and the biggest hurdle I'd faced so far was implementing Time Throttle (go figure). Game Maker's Box 2D physics engine is *very* particular about the way it allows you to interact with physics objects, and cutting the frame rate of the game does not work.

At this moment, I am 90% of the way there. I am able to 'simulate' a global slow by iterating over all objects in the game, and applying an appropriate value to each object's 'time_modifier' variable. This variable is then used within each object to dictate it's motion and behavior.

For example, when the 'time_modifier' variable changes by X%, a proportional force is applied to the moving object, slowing it's motion by X%. When the 'time_modifier' returns to normal, that change is tracked as well, and likewise a force is applied to the object to speed it back up. There's a little more going on, but that covers it pretty well.

All in all, it's generating the effect that I want!
Except... my cannon balls aren't inheriting the functions that change the 'time_modifier', and without that... there's no change to the motion.

It's an issue with inheritance. I'll get it sorted soon, and then I'll post a new video.
Actually, since I just wrote that down, I went to my cannon_ball object to check it's inheritance, and sure enough, it was NOT inheriting step events from its parent. So that would pretty much do *exactly* want I described. So... now I have that problem solved!

And following that, I performed a little code clean-up, a few bug-fixes, and VOILA! POC 3 is Complete.

Time Throttle: POC Milestone

posted Nov 13, 2017, 9:22 PM by Good Idea Games

This weekend I reached a new milestone with Time Throttle.
It's Fully Playable, and it's FUN.
Here's a short video showing off what's going on in a match...

Of course I have a lot of work left to do... All of the VFX are just recycling the same smoke and flame objects, I don't have all my sounds in place, and the game only works while supervised. There's a lot that can go wrong. For the love of god, don't unplug a controller after the game starts. My game pad support is so janky you basically have to reboot ;^).

But it WORKS.

Time Throttle: Dev Journal 16

posted Nov 7, 2017, 11:16 AM by Good Idea Games

I ran into an issue with engine noise that I can't explain, so I've posted to a few forums for support.
Once I get that sorted out, I can move forward on SFX, but for now...

So my proof-of-concept is almost complete, BUT.. the time throttle isn't *really* working.
Don't tell anyone, but it's just a series of hacks that give the appearance of time throttling.
In reality, left trigger reduces the game's frame rate, which *literally* slows down time in the game.
This is pretty Okay, as long as I can keep the game's frame rate smooth.

The right trigger is supposed to be a local acceleration... it applies to your pawn, and a small area around it.
This isn't doing that at all. In reality, I just up the player's speed, acceleration, reduce their cool-downs, and up the pitch of their sound. I mean... technically I'm doing all the things that an actual time-speed-boost would do, BUT... I'm not creating an AOE around the player that can speed up bullets.
I want that.

So it's back to the drawing board for the Time Throttle.
The Time Grenades *are* working, and produce the desired effect...
Any object that enters one has it's active properties effected by a certain 'time factor' and when they leave, the difference is restored. They even stack nicely!

So... what if left trigger creates a grenade effect that's centered on the player, and just happens to be large enough to cover the entire screen? It should work.

With some simple (read as 2-days) augmentation of the grenade, I updated the code to allow the time_factor to change dynamically based on player input, and continuously augment the motion of those affected objects. 

The tragic draw-back is that this much activity is overloading my desktop, and driving the game down to like 10 frames per second. 

I'm going to do some optimization and troubleshooting before I move on.

Time Throttle: Dev Journal 15: SFX

posted Nov 5, 2017, 3:53 PM by Good Idea Games

The time has come to implement Sound Effects to Time Throttle, and it's been interesting.

The first thing I did was implement background music, and tie the pitch to the game frame rate.
My global time manipulation mechanic is a hack, and just reduces the game's frame rate. By doing it this way, it was extremely simple, and produces *all* the side effects that I want... a general slowing of everything that the game does. It's a terrible solution, but I'm still running a proof-of-concept. If the game is fun, I can do this in a better way.

After that, there were a few simple SFX to implement... cannon fire, grenade fire... 
These were also simple. My audio wizard Lara Barden put together some SFX for me.

Next, for the engine noise I needed something special. And Stupidly complicated. It took me more than 3 hours to get it working right. This was dumb, and for a POC that will have like 4 players, it was a waste of time... but I learned a lot. 

The sound of a VW engine is special and unique, since my POC vehicle is a rocket powered bug, I needed to capture the unique sound of an idling air-cooled bug engine. I ended up ripping the sound from a youtube video, and breaking it up into different loops using audacity. I have one loop with an uneven pace, and one loop with an even pace. Then, I set the two sounds to play in order, a random number of times each. It worked out perfectly, and I created an idle engine sound that doesn't sound like a single looping track!

Next, I have a rocket engine. So I created a rocket engine loop (youtube+audacity again) that plays when the player is applying thrust to their craft. This did *not* work.

After a few hours of troubleshooting, I had to turn to reddit for help.

Time Throttle: Dev Journal 14

posted Nov 1, 2017, 10:13 AM by Good Idea Games

I've reached a major milestone!
My core game loop is complete. The game can start, play, end, and return players to the selection screen again. Hooray!

I've also implemented basic bullet trails for time throttling and background music with tempo tied to the time throttle as well!


Upcoming features: full SFX, additional vfx tweaks.

Time Throttle: Dev Journal 13

posted Oct 26, 2017, 5:11 PM by Good Idea Games

Things have come along nicely for Time Throttle in the past week.
I've got the memory hole patched up, and gameplay-wise, the POC is complete!
... But I still have a bit of work to do before it's ready for sharing.

I need to implement a menu system so players can load in, set the game mode and track, check the controls, and set their colors.
I need to augment the victory condition so it honors the players' choice.
I need to generate a Victory menu, so the players can see their performance after the match.

I still need to implement sound. the game is completely silent at the moment.
I need to implement additional VFX for player craft, forward thrusters need to generate smoke and trails as well.
And most importantly, I need to implement sound and VFX for the global time slow.

And after that, it's bug fixing!
This is really coming together.

Time Throttle: Dev Journal 12

posted Oct 15, 2017, 10:10 PM by Good Idea Games

Things are getting interesting!
I've implemented the first of my necessary VFX, flame and smoke.
This was important, because I need some on-screen effects to slow down, to give the appearance that time is slowing, not just speed.

This means that my flame and smoke need to be 'objects' that can store the data necessary to receive and recover from a time modification. And consequently, this has shown me that I'm not properly destroying my data structures, and when I create 120 new objects per second (smoke+fire) I have a massive memory leak. This means the game doesn't recover the memory it's used, and the footprint just steadily increases.

It has to be fixed.

Also, my flame and smoke sprites are too small and symmetrical for any animation to actually be noticedm so the desired effect of animation slowing down isn't happening. But I can fix this.

Also, I have a local speed boost on the right trigger, but it doesn't get undone... so using it permanently boosts your ship's clock time, reducing cool downs to ~0. Good Times!

Here's a video!

1-10 of 60