ZackBellGains #3

Hello world,

I hope that you are making the most of your day! Today wasn’t the most exciting of days. I did a lot of travelling because I wanted to be home for at least a portion of Easter weekend. I want to take this entry to talk about making and maintaining contacts, opening doors and creating opportunities, and how that first bit leads to the latter.


It’s Not What You Know. It’s Who You Know
I am sure you have heard that before, and it is no less true in the games industry than it is anywhere else in the world. A successful developer is likely good friends with other successful developers, actively communicates with popular YouTubers, streamers, and journalists, and is only one or two contacts away from a connection with a publisher or other means of potential funding. Who you know can make all the difference because in the world of indie games, the volume of your voice and the breadth of your reach is often more important than the quality of your game(s) when it comes to keeping a small studio afloat (sales are typically limited by your lack of marketing prowess).

It may seem like common sense, but it is in your best interest as a developer to be kind to everyone that you come in contact with. This goes for people whom you meet at conferences to the seas of faceless avatars met online. There may come a day where you need someone and having more options than you could possibly consider is an amazing problem to have.

Know When To Say Yes
“Know when to say no” is a common word of advice among my peers. A lot of these developers are also living paycheck to paycheck while juggling a game and/or studio during their long evenings alone. More and more I am feeling that it is important to continually analyze who you know and what options you have on the table so that you can also consider each of these options. There have been times where I needed more money, felt completely doomed, and had a dozen job offers to choose between if I WOULD HAVE JUST STOPPED PANICKING LONG ENOUGH TO ASK. A lot of developers have impostor syndrome and a lot of people with impostor syndrome underestimate the number of fellow developers who would absolutely love to collaborate with them.

Right now I am going through a bit of this myself. I am stressed out, some things are going incredibly well, some things appear to be crumbling, and some things feel fragile, but worth fighting for. I took a few days this week to slow down and connect with the people close to me. I met with one of my business partners and mentor, Robert Bowling (Infinity Ward, Humble, etc), and discussed my options regarding our startup. I met with my friends, Jesse Freeman (Amazon) and Austin Ivansmith (WayForward) to discuss the different contracting options that I have available to me. I also met with Ryan Swarner, my very first partner in the games industry and discussed the status of the project(s) that we are working on. Having these conversations with these people was great for morale and gave me a renewed sense of direction. I strongly suggest that you do this sort of thing often!

Moving Forward
Alright, so what were the results? It isn’t quite that simple. I certainly have a lot to consider. I can tell you that Ryan and I are collaborating again. We have a project in the works that will be published by Spaceboy Games. We are also discussing the future of Frog Sord with Fellipe and a few potential contractors. I am working hard on my project that sent me down to Los Angeles and I will able to speak about all of that a lot more in the near future! There are a whole bunch of very exciting options on the table and it is an exciting time for me, in general. I am hoping to be more descriptive with these entries soon, as well as start streaming the work that makes the most sense for that setting (likely INK 2 development). Let me know what else interests all of you, and I will work it into my routine!

Until tomorrow,

ZackBellGains #3

ZackBellGains #2

Hello world,

I hope that you are making the most of your day! Early yesterday, I decided to begin an articles series called, ZackBellGains. Within these posts I will detail my life, my work, and my progress as a human being over the course of the next year or so of my life. I am going to be making these posts EVERY SINGLE DAY! I have recently been fascinated with the idea of documenting my life and what something like that might mean to my future kids and my potential grandchildren someday.

Today I made an unofficial announcement that I have begun the development process of a follow-up to my 2015 Steam title, INK. To further celebrate the news, the original game will be on sale for $0.99 (80% off!) over the course of the next two weeks! If you haven’t played the game, please consider checking it out. If you have, consider shooting me an email or a tweet in regards to what you would like to see from a sequel! I have never made a sequel to one of my games, so I am a bit nervous, but I will tell you why I decided that this was a good idea.

In short, I had enough solid content and fresh ideas that were eventually cut from the first game (due to timeline and budget) to justify giving it another shot. I will break down what I have in mind! Please let me know if there is anything else that would excite you as a returning player and/or anything that you think might attract new players and broaden the target audience!

Game Modes
INK 2 will be developed by ZackBellGames with sound design and OST by Vincent Rubinetti, and published by Spaceboy Games. I have broken the game down into three distinct gameplay modes! As things develop, I will expand upon each of these, but for now I will introduce you to the gist:

Arcade Mode is the bread and butter that made INK the success that it was! This mode is level after level of fast-paced, twitch platforming while unearthing your surroundings using the ink spurts of the player character’s double-jump. This means more levels and more mechanics! I am taking a look back at player feedback and I have decided to remove the boss battles from this mode because RNG has a negative impact on the speed running community’s view of the product. This mode will be built for speed running, equipped with a timer, quick-reset, windowed mode, and a recorded ghost of your best time that you can race through each level again and again.

World Mode is the experimental iteration of INK that I briefely mentioned in the postmortem that I published on Gamasutra in 2015. A lot of the more interesting mechanics that I had prepared for INK were contradicting, and grinded against the speed running nature of the game. These mechanics were typically more puzzle-influenced and/or more combat-heavy. I have decided to present this portion of the game as a compact, highly-polished metroidvania adventure. Explore this new world of INK and discover new abilities, enemies, and bosses along the way! I think it’ll be a lot of fun and will attract a different kind of player.

Battle Mode is simple. Play INK with your friends in a mode that can most easily be described as a 2D variation on Nintendo’s Splatoon. I will detail this segment of INK 2 in time, but I can promise you that these turf wars will be a ton of fun!

I am going home to Seattle for Easter weekend with my family! I will likely begin to tweet INK 2 progress GIFs very soon, but for the next twenty hours or so I will be driving (ugh). If you are enjoying these entries, are looking forward to INK 2, or would just like to support me and my team, please check out HackyZack on Steam or the Humble Store. Thank you all so very much!

Until tomorrow,

ZackBellGains #2

ZackBellGains #1

Hello world,

I hope that you are making the most of your day! Recently, I have had this itch to make big moves, open doors, and tackle opportunities that come my way. So much so that I feel like the journey is worth documenting. Since the development of INK in 2015, I have stuck to a brand built upon accessibility and transparency. I’d like to take this year to really stretch that concept and record my daily routine. I hope that this will be even the slightest bit interesting and/or inspiring for a few of you, but at the very least, it is great for my self-awareness. With that being said, welcome to ZackBellGains: a blog about my life, my business(es), my goals, and my growth.

I am going to back up a bit here and fill you in on the last month or so. On March 28, as Spaceboy Games, we launched our first commercial product, HackyZack. Our team partnered with the great people at Humble Bundle to distribute HackyZack on Steam and the Humble Store. Within two weeks of launch, I announced my sporadic relocation from Seattle, WA to Los Angeles, CA. I had no plans, no lease, and essentially just picked a date, grabbed some clothes, and drove twenty hours south.

I have been living in southern California for ten days now, bouncing between cheap hotels, juggling Spaceboy Games with an additional startup, and feeling out where I want to be headed with all of this. For the time being, I am creating an educational platform for aspiring game developers from the second floor of the Respawn Entertainment building (Titanfall, Star Wars, etc) in Chatsworth, CA. It is 5:00AM and I have been sitting at my PC since about 6:00PM last night. I suppose you could say that I am homeless until 9:00AM when the apartment complex opens and allows me to finally move in. It turns out that finding an affordable room on a whim is somewhat of a chore. Who knew?

I am going to be making a lot of changes, working very hard, hitting several roadblocks, and floundering to successfully pivot along the way. Feel free to follow along, subscribe, ask me questions, and so on. I am an open book and incredibly excited about what the next few months may hold.

Until tomorrow,

ZackBellGains #1

GameMaker: Debug Logger

Hi everyone,

I went round and around with people on Twitter today. We were tossing around a bunch of ideas for convenient helper scripts and things that we did to make our lives easier in GameMaker. I thought that I would take the opportunity to write about something that can make your life a hell of a lot easier! A debug logger! In short, the debug logger will allow you to print information to the screen and each entry will allow you to specify different properties like how long it is drawn on the screen, whether it is pushed to the top or drawn in-line, its draw color, maybe whether or not it is indented, and so on (anything that you’d like, really).

For starters, you can probably tell by that last bit that this feature is very specific to your project, so your debug logger might not have the same set of properties as mine does. I will do my best to explain things in a way where the code remains modular and manipulable without becoming overly complex. As usual, contact me if you are in need of extra help! Continue reading “GameMaker: Debug Logger”

GameMaker: Debug Logger

Developing Your Platformer: Tips&Tricks

Hello Patrons,

It has been a long week! Spaceboy Games just launched its first game on Steam as an acting publisher. We worked together with Mike Studios (Philippines) to bring High Noon Revolver to PC, Mac, and Linux! Alongside that, I have been hard at work on more #Fara development (overworld traversal code, mainly). With that being said, I thought that I would take a break from all of my top-down design and visual effects to talk to all of you about developing a high-quality platformer. This entry will be theory-based (i.e. I won’t be supplying you with any sample code), however, I feel that if studied attentively, this guide will help take your 2D game(s) of the platformer genre to the next level.

A Not-so-broad Look at the Platformer Genre
Alright, so for those of you who have been following me for awhile, you probably get a mental image of the kind of game that I am talking about when I talk about platformers. The term ‘platformer’ is an incredibly-inclusive umbrella that covers everything from level-based, side-scrolling games like Super Mario World, to open-world, exploration titles like Castlevania. I happen to enjoy a sub-genre of platformer that one could describe as fast-paced, with micro-levels, and a focus on simple, but deceptively deep mechanics. This would include games like Super Meat Boy (Team Meat), INK (ZackBellGames), and HackyZack (Spaceboy Games). Because I self-proclaim that I specialize in this area of the genre, I will be focusing on features that apply to these types of games today.

1) A hardcore platformer is no place for realistic controls. The best platformers have what I call duct-tape physics. Duct-taped together because the physics could not exist in any system. They are often inconsistent. Not inconsistent in the sense that they are unpredictable, but inconsistent meaning that values may change given different scenarios (acceleration, friction, and speed(s) may change depending on whether you are on the ground or in the air, for example).

2) The pacing of these games is generally fast. Fast is relative and shouldn’t be hard on the player’s eyes. As you increase the game’s overall speed, consider zooming the camera out to adjust how much screen distance is covered over time.

3) Again, speed is relative. Consider whether or not your game would improve from also having the option to walk rather than run.

4) Allow for practically instantaneous acceleration, as well as friction (be able to stop on a dime) when the player is grounded. Slippery controls are a no-go at high speeds.

5) Include the ability to jump variable heights! If the player is still moving upward while the jump key is released, cut the player’s vertical speed by a fraction. This allows the player to have a higher jump arc when holding the jump key for longer periods of time.

6) To further the player’s ability to nail more a precise jump height (particularly in situations where the player must squeeze into a tight gap the size of a single tile), some developers choose to add an additional frame or two to the player’s hang-time when their vertical velocity is zero. Remember to check that the jump button is still being held down at the very peak of the jump (when the player’s vertical velocity is zero or has already passed zero back into positive values), lock vertical velocity to zero, and don’t allow the player to fall any further for another frame or two. That added hang-time does wonders for making the highest of jumps more feasible!

7) Typically, to determine whether or not the player can jump, you check two things: if the jump key was pressed, and if the player is grounded. One way to make your controls feel more responsive here is to add an input buffer for one or both of these requirements. For example, check if the player is on the ground during this frame *or* if the player was on the ground during the last frame. This case is very common when a player is trying to clear an abnormally wide horizontal gap and has just barely ran off of the end of a platform prior to tapping the jump key. This can be taken even further by also checking if the player will have made contact with the ground during the next frame, which can be determined by evaluating the player’s velocity (you can choose to only use this case when the player is a few pixels or less from the ground to better conceal the buffer. The illusion of responsive controls fails when the hand-holding becomes visible to the player).

8) The same input buffer can be applied to games with a double-jump. Often, a frame or two before the player makes contact with the ground, the player will try to jump. In the case of games with a double-jump, the second jump (if not already used) would be triggered. Otherwise, no jump at all would be performed without an input buffer. My recommendation would be that if you have a double-jump, go back to the previous point in this article and apply both the previous and next frame buffer. If the player is going to reset their jump and double-jump within the next frame (will be grounded during the next frame), reset their double-jump now and execute their first jump instead.

9) Take the time to implement the proper handling of overlapping inputs! By this I mean the case where the player is pressing both left and right, and/or is pressing both up and down. This issue exists in the first place due of common, *cutesy* little programming/math tricks where you can subtract one input from the other to cancel each other out (but that causes the player to stop moving briefly when you shift from moving up to moving down and have a frame where both keys are held). We can accomplish a fix in several ways, I am sure, but what you are essentially trying to do is change how you determine which keys are being pressed. Personally, I do this by taking time into account. If both left and right are simultaneously held; ask which one was pressed more recently. The more recent input action should take over. This can be tricky, so I will outline a simple example below:

// Initialize
_kLeft = 0;
_kRight = 0;

// Input polling
if (keyboard_check(vk_left)) _kLeft++; else _kLeft = 0;
if (keyboard_check(vk_right)) _kRight++; else _kRight = 0;

// Sample movement trigger(s)
if (_kLeft && (!_kRight || (_kLeft < _kRight))) {
} else if (_kRight && (!_kLeft || (_kRight < _kLeft))) {

In words, to move in one direction we check if that direction is pressed, as well as if the opposite direction is *not* pressed or the desired direction was pressed more recently than the opposite direction.

10) Alongside jumping, hardcore platformers also focus on tight wall-jumping. Programmers and designers alike often have a hard time find numbers that allow wall-jumps to look fluid across multiple scenarios.When it comes to wall-jumping, there are really two cases: the player could be climbing a single wall; repeatedly jumping away from the wall while continuously pushing back towards the wall (trying to scale the wall, vertically). The player could also be jumping away from the wall, horizontally, and over a far gap (often back and forth between two walls over a gap). These two cases are very specific and you can presume which the player is intending to perform depending on whether or not the joystick (or keys, etc) are pressed towards or away from the wall. Use this to craft two separate wall jump arcs! Imagine a wall to the players left, if the player is pressing left and activates a wall-jump, kick away from the wall and set an increased vertical velocity to propel the player upwards. If the player is pressing right and activates a wall-jump, skimp on that vertical velocity a bit in favor of horizontal speed; they are likely more worried about jump distance than jump height. Play with these two arcs and how they affect your ability to scale terrain in your game.

11) You may run into a common issue with one of your wall-jumps. When jumping away from a wall, the player naturally pushes off horizontally, and then presses the jump key. If they push away from the wall too early, the player leaves the surface, the wall-jump isn’t triggered, and they fall (often to their death). The solution offered in games like Super Meat Boy, INK, and HackyZack, is the subtle wall stick. When the player begins to push away from a wall, prevent them from doing so for a few frames (I believe that Super Meat Boy does this for 1/8 of a second). It should be just enough time for them to perform the wall-jump. Too long and the game begins to feel unresponsive.

12) Generally, games with wall-jumping also implement a wall-slide, which is really just the alteration of gravity while the player is up against a wall. This is often both the acceleration applied to the player’s fall, as well as the terminal velocity of the fall (fall slower due to additional friction caused by contact with the wall).

13) One common tweak to add to your wall-slide is how friction is handled. The adjusted variables shouldn’t be applied to a player that is still moving upwards along a wall. The player should be able to jump and slide freely up the wall after making contact, rather than being slowed down due to the wall friction that I mention previously. Only after gravity has taken hold of the player and the player’s velocity has dipped back into the positive again, that is when an added friction can be applied.

14) Consider giving extra properties to horizontally moving platforms if wall-jumping is a prominent mechanic in your game. When you are wall-sliding alongside a moving platform, have the player stick to the platform while it is moving *away* from them. Wall-jumping both towards and away from a platform that is moving away is very uncomfortable and essentially strips the player of their wall stick. Another option is to add a similar jump buffer for “was on wall during previous frame”.

15) The friction applied to the player within the air is often referred to as air-resistance. Your chosen air-resistance is one of few variables that often up for great debate among platformer developers. Games like Mario or Megaman have a higher friction value when the player is in the air; often comparable to the friction while grounded. This makes it just as easy to turn around and change direction while jumping. Super Meat Boy on the other hand, has a very low air friction. If you are running and you jump, you maintain your jump arc regardless of whether or not you let go of the joystick or arrow keys. In Meat Boy’s case this is coupled with a proper terminal velocity that allows you to weave in and out of obstacles as you rise and as you fall. Pay attention to your air-resistance options and what these values mean for your style of gameplay.

16) Terminal velocity is the player’s maximum fall speed. The terminal velocity of object’s in your game plays a major part in how *floaty* your controls will feel. A low terminal velocity means that you will have more control over the player as you fall, but falling too slow feels weird to a subset of players. Play with your terminal velocity and how it compares to your air-resistance. These two things are what make these hardcore platformers feel the way that they do.

17) Platforming in tight quarters is often less enjoyable than platforming in large, open areas. Again, this is where meat boy shines. If you want to keep things indoors and keep the challenge up in the players face, consider adding some oil to your corners. This is a technique used to nudge the player, by a pixel or two, around tight corners. One example could be running and jumping out of short tunnel. Rather than bump the player’s head on the way out, you can push the player outward and upward if the clip is subtle. This also works for jumping up onto platforms. If you are one or two pixels short of a platform, you can push the player up and over. This will take some tweaking, but will feel completely natural when implemented properly.

Lesser Notes
That just about covers my technical tips & tricks for polishing your platformer controls and mechanics. I will quickly outline a few other things to take note of (in lesser detail).

– Never forget to add player feedback! Every action should have a reaction. When you jump, spawn particles, when you land spawn particles. Squash and stretch your character on big impacts. Gamepads still have rumble! SCREENSHAKE!

– Typically, the closer to a square your player is, the better this type of controls/mechanics will feel. An exaggerated wall-jump tends to look pretty bad with multiple-tile tall characters (compare Super Meat Boy to Megaman X).

– If your game is difficult, cut your respawn time in half. Cut in half again!

– Avoid tutorials where possible. Teach the player through solid level design.

– In the same way, introduce mechanics in a structured way. First, introduce the mechanic within a somewhat safe space. Then use it in a few more difficult scenarios. After the player is comfortable with the mechanic, combine it with previously introduced mechanics.

– Remember that your difficulty curve needs subtle dips after extreme challenges. Players appreciate an opportunity to feel like they have improved. If your palms are always sweating, you don’t feel that you have grown.

BOOM! That’s it for tonight, everyone! I hope that these different points will help you in some way. I revisit the games that I mentioned and a lot of these tips when I am designing non-platformers, as well. Find new ways to apply different techniques to different kinds of games. If I missed anything, please share!

Thank you all so much for your continued support,

Developing Your Platformer: Tips&Tricks

GameMaker: VFX Part 1

Greetings Patrons,

I will be breaking different series of articles into separate installments. This will allow me to hit different skill levels, explore a broad range of techniques across each category, and market these articles in a strategic way (often Part 1 of a series will be public/free to entice new users to sign-up to continue to receive future installments). These series may not always be sequential, so please do continue to suggest content (VFX Part 2 may not be next week’s article, for example).

Visual effects! I get asked about my approach to visual effects all of the time. I get asked about particles, sprite squash/stretch, shaders, etc. I will cover all of these topics at some point, but today I am going to focus on basic dust and smoke particles, how I use them, and a few tricks that you can use to make them more interesting and appealing. I will attach a sample project that includes a room to play around with, as well as all of the code (well-commented) necessary to create these effects.

Kicking Up Some Dust
Alright, so first thing’s first: we need to create some dust. You can use GameMaker’s built-in particle system if you’d like. It isn’t bad-, but I happen to use objects for my particles. I don’t run into efficiency issues, so you probably shouldn’t worry about it. Using objects gives me a certain amount of control over how my particles act (as well as allow for collision and things like that), and I also just like the work environment better and find that coding particles is a pain.

We have some creative freedom here. There is a lot of different things that we can do with our dust particles: collide with objects, accelerate, apply friction, apply gravity (y-axis? z-axis?!), and so on. For now, I think I am going to ignore any kind of collision, but we *will* implement a fake z-axis that allows our dust to be able to rise and fall. Perhaps we will have some form of collision with the z-axis “floor” after all.

For those who haven’t seen any of the GIFs from my Fara series of projects, I am using a fake z-axis to simulate depth. Adding this to a top-down game is actually quite simple. Objects are given a couple new variables: _z (position), _vz (velocity), potential gravity variables, etc. From there we just need to know that the floor is _z = 0 and anything that isn’t grounded has a _z that is less than zero.

Alright, so not very exciting yet. You can change the variables for different effects, but this *does* include all of the variables I would use for a typical particle. So what else can we do with this? The first thing that I notice is that without a frame of reference, the z-axis is useless. A shadow on the ground could fix this! If you don’t know how to use surfaces, this is the time to learn! I draw all of the shadows cast by objects to a single surface. This way the shadows can be transparent without overlapping improperly.

Hey, now that’s more like it! For each room in the project I created a new particle type to show off the progression. oVFXDust0 is that first example and oVFXDust1 is the example above. The only difference is a code block added to the end step event. That code draws a shadow to the surface held by a controller object used for shadow casting. You will note that I have halved the radius along the y-axis to further simulate depth.

What’s next? The technique used to draw overlapping shadows is helpful and allows a layer of objects to be drawn at a particular alpha value without overlapping improperly. We can apply this same technique to the particles themselves. This will allow the particles to be drawn with transparency and will also make the shadows more visible beneath them.

This is starting to look like dust! I also think it is a good stopping point for part one. As you probably noticed, I didn’t write much actual tutorial text within this article. Instead, most of the content is within the sample project, included code, and comments. Let me know if you would prefer a more step-by-step approach. I have yet to really monitor if I have programmer followers, designers, etc, so I am not sure what all of you would prefer. I want this to be an open thing where you can communicate with me about what you want, what you like, what needs to be changed, and so on.


Until next time,

GameMaker: VFX Part 1

First Games, Marketing, Publishing, and Postmortems

Hello patrons (and non-patrons),

I have to begin with a disclaimer because this article is in addition to the two articles that I have committed to delivering to my patrons each month. Additionally, I am making this content public because I believe that it is very important and I would like to combat the spreading of false information regarding the topics at hand. With that being said, I hope that you enjoy this and learn something. If so, consider becoming a patron if you are not one already. Thank you.

The Luck-Based Business Plan

Wow, so there is a lot to cover here. To avoid reiterating the situation that influenced me to write all of this tonight, I will supply a few links to the original blog entry: Here, here, and/or here. Each of these links depict the same post, but the comments sections shed a lot of light on the situation and differ from portal to portal. Also, prior to saying anything seemingly negative about Poncho, the developers of Poncho, or the publishers of Poncho, I would like to state that the purpose of the article is NOT to bash on anyone or their abilities. The purpose of this article is to assist in avoiding a situation where new developers are scared away from a thriving industry and a strong community due to one group’s horror story.

ss_01e61119526baa5c31d23e35ec1d5b570d63a592-1920x1080(Poncho – screenshot from Steam storefront)

Continue reading “First Games, Marketing, Publishing, and Postmortems”

First Games, Marketing, Publishing, and Postmortems