Good Idea Games
Time Throttle UI Tuning
Time Throttle is in alpha! Not feature complete, but playable, and I want to start collecting feedback from others. But first, I need to improve my user interface. When I built Time Throttle's menus, it was firmly in the proof-of-concept phase. I needed something very simple that just worked. Now I'm a little beyond that, and I need something slightly more professional. Not much... just enough that players will see the menu and know how to use it. I'm not a professional UX designer by any measure, but I've read 'The Design of Everyday Things,' and it's full of good tidbits on User Experience design. Also, this lovely article gives good insight into the choices another designer made while tackling a similar problem. |
The Beauty of Documentation
I'm in the process of transitioning to a new job, and there's a lot of uncertainty associated with that. When I am feeling uncertain about my level of control in my life, I take a lot of pleasure in activities that allow me to create order and structure. Things like Lego, Minecraft, Model-making, and this week, Documentation. I'm looking to integrate a few powerful opensource resources into Time Throttle and future games, and that means I need to understand them. To this end, I've been leveraging Gliffy to create annotated flowcharts of the various assets I want to implement. InputDog, by Messhoff PhysicsBasedBlockShips, by Orseoste7o RelicHunters by RogueSnail |
Time Throttle Dev Journal 14: Time Throttle Immunity
When you work on a project for a long time, you become blinded to... basically everything around you. I had a buddy come over to give me an outside perspective on Time Throttle, what makes it work, and what makes it fail. I've been working on Time Throttle for almost a year now, and to be honest, I'm still not satisfied that the mechanic is what it needs to be.It's *supposed* to be a way for all players to participate in real-time 'time manipulation' but to be honest, the impact still doesn't feel strong enough. This is probably because Time Throttle is begging to be implemented in a bullet-hell style game rather than a racer. I'll have to play with that idea some more. My buddy suggested that maybe the Time Throttle effect should be *stronger*, AND make player craft immune to it. As-Is, with Time Throttle slowing down everyone, it's sort of a sum-zero game. Unless you manage to use it to avoid collisions, you come out of using Time Throttle exactly as you would had you not used it at all. Making Player Craft Immune to Time Throttling was a night-and day shift in the power and utility of the mechanic. We then spent the rest of the day implementing code that would allow Time Throttle to act as a local-only effect, rather than a global effect. That was for science, and the verdict is still out on whether this is an improvement. I plan on altering the projectile motion and implementing some arena hazards that will make the Time Throttle more important. FOR SCIENCE. |
Time Throttle Dev Journal 13
For the past year I've been using simple graphics on Time Throttle, because I wasn't sure what visual style I wanted to go with, but my tastes are starting to settle. I'm a huge fan of 1996's Rocket Jockey (and I *really* home that Burn Ward's upcoming Rocket Jockey Reboot manages to see the light of day). This was one of those games that was absolutely formative in my youth. It left a big mark that makes me want to design games that give players this sort of an experience. I've recently fallen in with a rough crowd of post-apocalyptic die-cast car modders (imagine taking off-the-shelf Hotwheels, and modding them to look like they belong in a Mad Max film), and there's something extra fun about playing with toys. While I never had a chance to play the Micro Machines game on PSX, I understand that it remains one of the jewels of the top-town racing genre. Long story short, I want to try to capture the essence of playing with toys by making a game environment that feels like a high-end miniatures game being played on the kitchen table.  Here's a top-down photo of 'Red Rocket', one of my custom diecast models, done in the style of Time Throttle. I'm hoping to find a proper way to incorporate high resolution miniature photography into my game, to give it that playful, imaginative feel. |
Side Project: Menu Code Adaptation
At the moment, Time Throttle's menu and control configuration is abysmal. This is intentional. I put something basic in place so I could spin up a quick beta just to test whether the game concept was viable. Now that I'm satisfied with how the game plays, my crappy menu and controller interface won't cut the mustard if I want to share a demo. Rather than building something from scratch, I'm looking at lovely menu from Open Source game: RelicHunterZero, for code I can use. RelicHunterZero is a local multiplayer game with support for up to 4 players, and the only feature it lacks is the ability to rebind gamepad inputs, and for individual players to select different control configs. That's a small task, and maybe I can contribute my efforts back to the RHZ project! http://www.roguesnail.com/relic-hunters-zero-open-source-how-to-download-and-use/ |
Time Throttle Dev Journal 12
Getting my wheels spun back up with Time Throttle, today I spent some time on more superficial visual behaviors.
All of this is just procrastination though... what I really need to do is the tedious, uninteresting work of building a menu system that lets players change their control config and sound options. Unfortunately, that's a bit of work, and I'm not sure if anyone will ever *play* this game outside of my own living room, so spending the time on that seems... wasteful. UNLESS... I build it in a way that lets me recycle the menu and config system for future games I build! |
Time Throttle Dev Journal 11
Life has occupied me with other things as of late, so I haven't spent much time iterating on this, or my blog. Here's what I'm working on: Getting Time Throttle to a point where I can share it with others! Major Issue for today... Performance: Too much smoke. Smoke is an animated, time-effected object intended to draw attention to time manipulation and time bubbles. Unfortunately, each piece of smoke has to be a complete object with a large collection of variables that govern its motion in order for time manipulation to effect it. Consequently, if I am creating too much smoke, the game speed drops to become unplayable. I have dynamically changed the quantity of smoke delivered, based on the game's frame rate. Then I started tweaking the vfx for flames, to get them to behave in a more reasonable way. I also discovered that I failed to save my changes after repairing the bug that was causing time spheres to permanently alter objects. Fortunately, since I documented my solution in a blog post, it was simple to repair. Hooray. Here's a video of the current status! https://youtu.be/2e-rRTi24R8 |
Time Throttle: Dev Journal 10
---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. References Reddit: 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
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 ds_list_delete(other.affected_object_list,i) //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 instance_destroy() } 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 not 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 half the objects that were in the thing won't get their rightful properties restored. Whoops! 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. [EDIT: fixed some typos] |
Implementing Input Dog
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... |
1-10 of 67