Dueling Devblogs

Welcome to Dueling Devblogs, the blog where two good friends and game devs each make games as a way of discussing their outlooks on design philosophies. For more of our background and all blog posts you can visit - www.duelingdevblogs.com

Both our games are being made in Game Maker 2, so we wanted to involve the YoYoGames community in the process!


Prototyping


Week 1
Gabes Game
Really pure ideas are hard to come by. Ideas that don't feel forced or gimmicky, but like an intuitive way to experience gaming. For example: I love how in Mairo, you fight Goombas and Hammer Bros using the same skills you have developed for platforming: movement is combat. By the time you've really sunk your teeth into the game, your fingers are pumped full of muscle memory because, aside from the occasional flower, you have been doing nothing but running and jumping the whole time.

I'd like to make a game that explores methods of movement as combat. A game where, instead of getting hulking armor, you're developing a skill. Rep after rep you perfect your muscle memory, culminating in epic battles that really feel epic because you've become an actual badass. Don't like mastery in games? Well, you quitters can go back to your "outside" and "relationships".

My first idea was to make a platformer where holding down an action key enabled you to defy gravity and move faster for a short period of time, as well as damage enemies.




I do think this could make a decent prototype with more polish put into it. The issue that I came to was that making the dash happen instantly after clicking the action key felt too jerky to control strategically, but giving the effect a taper or lowering it entirely felt lackluster. Ultimately, it's not intuitive enough. It doesn't feel like that pure, Mario, natural way to experience gaming.

When attempting to find a more elegant method of combative movement, I came up with this:




Wall jump to attack. Its god damn Mario 2.0! Wall jumping requires muscle memory and deliberate timing from the player, but skilled players can dance through the air like ninja-lemurs. So, what if that momentum became defensive and combative? The giant boss monster launches three missiles at you, you jump off one, sending it crashing into another. That jump brings you face to face with the final missile, you wall jump off its nose casting it into the heart of your nemesis!

For the next week, I'll mostly be polishing this movement engine. Its going to be really important that movement is completely intuitive. The player needs an unusual amount of control while in the air to be able to hit fast moving projectiles, which poses an interesting challenge when attempting to make normal platforming feel fluid. Feedback is welcomed with open arms, let's make a game together!


William's Comment: I definitely dig the idea of marrying movement to combat in this way, though when you originally pitched the concept to me I had no idea what you were going for. Seeing the example up there of the player sending a projectile into the boss's face REALLY changed the way I was picturing it beforehand.

What I'm most excited for, however, is not the combat that you have set up. The best parts of Mario games were never besting enemies, they were traversing levels with strategically placed hazards. I think the most interesting thing as you move forward will be seeing how you develop gameplay to move from a player rockin' through a level, and seamlessly defeating enemies as part of the same motion without much change in pace.

Hmmm, combining movement, level navigation, and combat... that reminds me of something...


Hell yeah!
Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.

 

Hey guys, I'm William, the second half of Dueling Devblogs. This week I released the first post for my game, check it out!

Drawing a Game From Nothing: Concept Art

Week 1
William's Game

When making a game, there's highs and lows. For people who like a challenge, that might be bug fixing. For people who like world-building, that may be in crafting Easter eggs or cutscenes. For people who like money, it's when the game ships.

But for people who just like to create, it's in the design process; and nothing says design process quite like concept art.

Spoiler: Click here to read the first part of the post!

Concept art is funny to me, because it's usually the first step in any project I start, but it's also probably the most expendable as well. Most typically, if you have an idea for a game totally cemented in your brain and it's already good to go and you don't have to convey these design ideas to other people working on the game then concept art is actually kind of redundant.

But what concept art does it does well: concept art is a grinding wheel for the hatchet of your imagination. You always have to understand that you don't have eyes inside of your brain, so spilling your ideas out onto paper and then taking them back in with your actual eyes might result in you realizing that this idea only worked in my head oh my god what was I thinking this is stupid.

And it's important that you catch that before you start developing a game rather than halfway through when it's too late to make changes without spending months redoing what you've already worked on. That is a right pain in the ass.

So I like to get right into the basics of the game's rules and design right away with concept art, and that's what I did for this project!

Figuring the game out

Okay, so I drew the movement style I want to go with: kind of a Binding of Isaac style twin-stick shooter setup. I usually like to make my games either platformers or arcadey, and since Gabe is making a platformer I decided to go with the arcadier approach by going twin-stick. Robotron 2084 is, after all, one of my favorite arcade games and Binding of Isaac is what I would consider a perfection of that kind of gameplay.

But now I really need to get a grasp of what kinds of gameplay nuances I'm going to include. Do I want for the player to fire projectiles like a madman, charge up shots, use ammo, etc. etc. etc. Well, I kind of need to know what kind of game I'm making. I drew a skeleton as a fun point of reference guy, but what if I follow that idea?

Skeleton is turning blob monster there into a bag of bones for a disguise! So now I've somewhat forgone the arcade-style idea of a simple twin-stick shooter and am now focusing more on an Escape from Castle Wolfenstein feel (the original Muse Software game, not the id FPS game). Escape from Castle Wolfenstein is a bit rougher around the edges than Binding of Isaac, but I consider that a good thing: Wolfenstein has lots of flawed-but-fun concepts that I can improve upon, whereas trying to compete with Binding of Isaac would be a futile uphill battle.

If this is going to be a stealth game, combat is going to have to be very deliberate. Why on Earth would you choose to be stealth if you can just rain bullet Hell on your foes? So the standard attack will require the player to stop, making them vulnerable, charge for a second, then unleash an instant bolt which will immediately hit what is in front of them; having the attack lag on a moving projectile would be way too annoying to handle. By allowing the player to get an instant shot off after waiting a second, this will encourage players to sneak to a location where they can charge and shoot an unsuspecting enemy. An additional second of recoil will add to the frantic nature of trying to get in and out of a situation where you might have a lot of enemies around.

But what if the player hops into a disguise? Can't they just walk through the level with impunity then?

The disguise is impermanent, but in case a player ends up with a rotten disguise in the middle of a room full of enemies the busted up disguise can act to absorb one hit so you have a head start in getting the Hell out of Dodge. I've considered making it so the player can't grip weapons when they're in disguise as well, which would create interesting trade-off for meta game where the player can choose to go non-lethal while in a rotten disguise so they can tank an extra hit.

So all of this would be all fine and dandy if the game only has one or two types of enemies. But I want to include a lot of variety, and part of that will be enemies that don't go down in a single shot. You could risk taking pot shots at them with the pistol, but maybe I can also have a temporary weapon that allows the player to tank through certain portions of the game- to break up the stealth tension with occasional bouts of raw POWER!

And that's where the machine gun comes in. The machine gun would do everything that a machine gun should do: blow away enemies with ease. But the machine gun would also need to be used very tactically: instead of picking up ammo for a machine gun, you just have to pick up a new machine gun. They don't come with tons of ammo and you can't exceed the amount you start with. It's also not exactly an instrument of stealth, though you have a machine gun so who gives a crap about stealth?

And there you have it. No, really, that's just about all that you really need for the gameplay portion of the concept art when you're first starting out. I just decided a bunch of the gameplay with invitations for meta that I can improvise on as I make levels and design enemies.

 

Spoiler: Click here to read the second part of the post!

Style in Concept

Well that was all of the technical aspects of the game that I want to have laid out before I begin developing. What about a visual style? That should be more interesting right?

Absolutely! If drawing the same thing over and over again in different ways is interesting to you, you freak.

I'm fairly certain that any tattoo artist would probably agree with me that trying to make a skull interesting and have unique character is asking to fight a losing battle. Skulls have been done to death. They have the benefit of having distinct characteristics that immediately give away that they're a skull, but the concept is so tired that it's just so difficult to make something with its own charisma. I still can't wrap my head around how Toby Fox managed to create two different iconic skull faces in Undertale.

After a while, however, I started to get a feel for what direction I wanted to take the art in.

Once you get into that mode of refining a concept, eventually you land on something you'll be more than comfortable working with.

With a skull much larger than the rest of the skeleton, he's got a cutesy look to him which is only enhanced by turning his nose-hole into a heart. But with the bones as thick and bulky as they are, he doesn't look totally frail either. It almost comes across like a carapace rather than an endoskeleton, and I'm totally cool with that.

I also tried to concept some blob monsters, but those need a lot more work before I'll be happy with them.

I think the blob monster with the big eye might be the one I'm the happiest so far. The thought of the monsters having big ol' eyes for faces which get replaced by a skull face when used as a disguise just tickles me.

All work and no play

Finally, I'd like to leave you with this helpful tip that is pretty important to remember about concept drawing: even when you make your concept art as doodly as I do, it's still art, and artists can have moments of breakdown or block. If that happens, you just have to draw through it. It doesn't matter what you draw, but you've got to draw something.

No matter what it is, just draw until you start to feel inspiration again.

Even if it doesn't make a lick of sense.

Gabriel's Comment: William and I once made a little something called Four Play. It was a four-way breakout game. You controlled all of the paddles at once by moving the mouse. We both thought the idea sounded like an entertaining little project, all the way up until it was playable. When we could actually play the experience, we found that there was no intuitive way to control the paddles and aiming was a chore. Like touching the stove, or bowling, the idea was functionally less fun than anticipated.For the first time, in Dueling Devblog history. I respectfully disagree with William's method.

Fun is a hard thing to pin down. It's elusive and as William so eloquently put ~ "...you don't have eyes inside of your brain, so spilling your ideas out onto paper and then taking them back in with your actual eyes might result in ... this is stupid." Prototyping is game design doodling, it's a method of discovering what is functionally fun.

What if the body snatch mechanic, in practice, doesn't feel fun? The time spent on the body snatch mechanic artwork becomes less valuable. All of that said, all of this has value. Shaping theme and style takes time and all of the above work contributes to that. Further, William's personal projects consistently feature tight and engaging gameplay. I've always felt like he has a better grip on what's practically fun while coming up with ideas. So history would suggest, his skill in design allows him to make just about anything fun with enough tweaking. I can't wait to jump into some blob dudes!

Let us know what you think, who do you agree with? How do you get started on your games?​

Want more immediate posts from us? You can follow William on Twitter here and follow Gabe on Twitter here.

 

Week 2


Gabe's Game​

Much like the process of reproduction, in game design there are a few fundamental pieces that you put together to get things started. From there, the thing grows on its own. You're mostly left to deal with growing pains, college loans and, if you're lucky, a top-selling spot on Steam!

Like raising a kid, from the fundamental pieces you put together, a game grows into its own personality. Also like raising a kid, forcing a game to be something it's not makes it turn out ****ty.

Over the years, this has been among the hardest design concepts for me to grasp. I often will get so excited about a story concept or gameplay mechanic that I blind myself to the bigger picture. I love donuts and I love lobster. Putting them in a blender together is less than desirable. So, how does all of this apply to my project?

When I first thought of the concept of a wall jump attack, it was within the context of a Super Meat Boy meets Shadow of the Colossus sort of thing. I was imagining that you would wall jump up huge enemies to get to their weak points. I needed to start smaller though, so I came up with the idea of jumping off rockets quickly after prototyping basic movement with moving platforms.

Missile deflection prototype
​

Well, that's pretty fun. Maybe this game is really about deflecting projectiles. Maybe it's some sort of platforming bullet hell! This phase is my first glimpse into what my infant's passions might be. As if they as picked up a ball and threw it, pride pulled me to my feet as I proclaimed "My child is a quarterback".



But how do they die? The parental analogy breaks down here. We need the player to die sometimes. If they're deflecting rockets with their feet, what could possibly harm them? Maybe getting smashed between two solid objects? Okay, if the purpose of the game is to avoid getting smashed, what are other ways to nuance that challenge?

​

Not getting smashed is a thing in all sorts of platforming games. Of course we have the classic Mario Thwomp, but maybe something more interesting, like an enemy that hops. In most games, an enemy that hops into the air would be threatening while in air and prey while on the ground. Interestingly, wall jump combat changes that up.

Enemy Combat Prototype​

If I make these baddies invincible while on the ground, and always a threat vertically, they become an enemy unique to my game and the way that it's played.

Everything is young. I know that wall jumping to attack threats is what makes my game fun, so everything I'm adding should be with that core gameplay mechanic in mind. However, I barely know what my game is right now, so I shouldn't be buying a football uniform for my child yet, they could still turn out to be a dancer.

In these early stages, focus on the cornerstones, build a sturdy foundation. With just a few hours of work a day, I've got all sorts of design potential here! They grow up so fast.

Combat Prototype​

Let us know what you think, who do you agree with? How do build the foundations for your game?



Want more immediate posts from us? You can follow William on Twitter here and follow Gabe on Twitter here.

 

Its looking great so far! I like the uniqueness of how you attack the enemies. I think it has potential for a lot of smooth combo attacks between the enemies.

 

I love those skulls! Were they drawn on paper or digitally?

 

Thanks! I draw my concept art in standard ballpoint pen on sketchpad paper. At some point later down the line I'm also going to be making a post about a process where I hand draw graphics and then digitally color them.

 

Coding a Foundation for Comfort

Week 2

William's Game ​

This week, I began tackling the programming for my game. Hammering out a prototype, as Gabe had started doing a week ahead of me.

A little known fact about programming is that it's actually really easy as long as you can follow logic, understand order of operations, can work within a structured environment, and (most importantly) can use Google to see how other people approach it. To the surprise of those who have never programmed before, code is just a lot of mostly interchangeable instructions written in a very specific language.

​

I'm actually mostly self-taught as a professional programmer. I've programmed since I was 11 years old and it wasn't until I turned 19 that I started my first programming class. Now, having completed quite a few programming classes, there's really only one thing that I learned from them that I hadn't already taught myself: a clean coding environment is what separates professionals from amateurs.

Like this, but hundreds of lines long​

You want to write your code as if you have zero attention span and it's always easy to read the previous couple lines and know where you are. That's why my code in my game looks something like this:

​

That's just a chunk of my programming and it's already way, way simpler than what it needs to be because I effectively break down every programming task into individual working parts, and the script that runs these individual parts is usually so cleanly set up that it reads like a glossary of what each individual sub, function, and macro is useful for.

That's what clean code should be. It should be natural to follow to its works parts. Now, since I'm still working very hard on the prototype and have little to show this week, I wanted to go over organizing the working parts a bit. It's going to be pretty technical, but unless you're already a seasoned programmer you can't say that you didn't learn anything!

So, in my movement code I have a part that looks like this:

​

Remember what I said about good code looking like a table of contents? Now, you can see, in order, the scripts that do each part:
1. Check to see if the user has inputted keys that will affect the player's movement
2. Take the input and communicate it into variables that will determine the player's movement
3. Take those variables that determine the player's motion and actually move the player
4. Adjust the player's depth to ensure that they are properly drawn over objects according to their new location
If you want to update the game to include a new type of controller, you know where to make that change:

​

These broken apart pieces of the code are called "subroutines" ("subs" for short) and the most commonly cited benefit to using subs is that you can cut down redundant coding: instead of repeating yourself, you can just make a sub and execute it multiple times. While that's definitely one use I get out of subs, I tend to get my most value out of using them as organizational tools. It's so easy to get lost in programming, being able to give a name to a specific operation is incredibly handy.

But there's more tricks you can do once you get into something called a "function":

​

That's all of player movement. Pretty nifty, right? 11 lines of code, 3 of which are comments, 1 of which is the function's definition, and 3 of which are totally empty. How is it done so simply?

Well, the majority of the work done for the player's actual movement is in those "player_movement_indvfunc()" functions. Admittedly, I gave this function a bit of an ugly name, but I know what it means at a glance so it works for the necessary purpose.

Within those functions is the following:

​

That 81 line monstrosity (giggling to myself a bit because I know that's not as large as scripts can get) takes the player's movement variables and uses them to push the player through the room, slide along slanted walls, and feed back information about whether or not the player has come to an obstruction.

That's the difference between a subroutine and a function. A sub just executes a cute chunk of code, but a function executes a cute chunk of code and returns a value. You can set variables to be equal to a function, you can compare functions, and you can use functions in an algorithm. In this case, the function is one gigantic subroutine that moves the player along and then returns a value that will determine if the player cancels their momentum.

​

That "if" is taking the function and determining if it will return a "1" or a "0" (or "true" or "false") and setting the variable of "hs" to 0 if the function is "1". This makes the function not only useful in completing an action, but useful in helping the code that calls it to make a decision about whether or not the player needs to cancel their momentum.

So, if you were able to follow all of that, that's how I organize my code. Not only that, but I essentially just gave you my top-down movement engine for the player. Some parts are missing, but if you can follow the logic they shouldn't be too hard to fill in if you're making your own project. It'll look something like this:

Enthralling enough gameplay footage that I made this entire blog post about programming technique. ​

I hope you learned something valuable reading this, because lord knows this wasn't much of an entertainment value post.

​

​

We would love to hear what sort of posts our readers are most interested in. Maybe you thought this was too technical, maybe you were craving move details. Let us know!

 

Yeah, that is some very pretty code. :3

I can attest that time spend properly formatting and commenting your code will save you twenty times that amount of time spent in the stygian nightmare of coiling existential dread that is This Should Work But It Doesn't And I Don't Know Why. Google search can help you with a ton of coding problems, but a misplaced closing bracket isn't one of them.

I'd like to have a closer look at your movement code, but at least on my current monitor the image is a bit too pixel'y to be easily readable.

I like this thread by the way, have been looking for an excuse to post but since my response is usually just:

Code:

thatThingYouSaid += 1;   // Yeah! 

…I haven't bothered, to avoid kludging things up.

But I wanted to let y'all know I appreciate your efforts.

 

Hey, no kludging at all! I really appreciate feedback. I tend to be the only programmer on a lot of projects I work on so I'm never totally sure if my code will look half as clean to other people. An extra pair of eyes always does something to make my endeavors feel a little more... legitimized (I think that's the right word).

The code in all of its no-pixel glory is here:

This goes in create for the player:

Code:

///player_ini()

//Speed Limits
maxspeed = 4
accelerate = 1
frict = 1
hs = 0
vs = 0

//Input Stuff
inputmove_left = 0
inputmove_up = 0
inputmove_down = 0
inputmove_right = 0

All of these go in step for the player:

Code:

///player_input()

//Moving Left Key
if (keyboard_check(ord("A")))
    { inputmove_left = 1 } else { inputmove_left = 0 }
//Moving Right Key
if (keyboard_check(ord("D")))
    { inputmove_right = 1 } else { inputmove_right = 0 }
//Moving Up Key
if (keyboard_check(ord("W")))
    { inputmove_up = 1 } else { inputmove_up = 0 }
//Moving Down Key
if (keyboard_check(ord("S")))
    { inputmove_down = 1 } else { inputmove_down = 0 }

Code:

///player_movement_selfpropelled()

//Horizontal Movement Check
if (inputmove_left = inputmove_right) or (inaction != 0)
    {
    hs = max(abs(hs)-frict,0)*sign(hs)
    }
else
    {
    if (inputmove_left)
        {
        hs = max(hs-accelerate,-maxspeed)
        }
    if (inputmove_right)
        {
        hs = min(hs+accelerate,maxspeed)
        }
    }
    
//Vertical Movement Check
if (inputmove_up = inputmove_down) or (inaction != 0)
    {
    vs = max(abs(vs)-frict,0)*sign(vs)
    }
else
    {
    if (inputmove_up)
        {
        vs = max(vs-accelerate,-maxspeed)
        }
    if (inputmove_down)
        {
        vs = min(vs+accelerate,maxspeed)
        }
    }

Code:

///player_movement()


//Edit these as additional forces are applied to the player
var hsp = hs
var vsp = vs

//Horizontal movement
if (player_movement_indvfunc(1,0,hsp)) {hs = 0}
//Vertical movement
if (player_movement_indvfunc(0,1,vsp)) {vs = 0}

Code:

///player_movement_indvfunc(x,y,speed)

var xs = argument[0]
var ys = argument[1]
var ospd = argument[2]
var canmove = 0

if (place_meeting(x+(ospd*xs),y+(ospd*ys),obj_obstacle_basic))
    {
    for (var ii = 0; ii<abs(ospd); ii+=1)
        {
        if (place_meeting(x+sign(ospd*xs),y+sign(ospd*ys),obj_obstacle_basic))
            {
            if (xs != 0) //Move along ramps
                {
                if !(place_meeting(x+sign(ospd*xs),y-1,obj_obstacle_basic))
                    {
                    x+=sign(ospd*xs)
                    y-=1
                    ii += 0.5
                    }
                else if !(place_meeting(x+sign(ospd*xs),y-2,obj_obstacle_basic))
                    {
                    x+=sign(ospd*xs)
                    y-=2
                    ii += 1
                    }
                else if!(place_meeting(x+sign(ospd*xs),y+1,obj_obstacle_basic))
                    {
                    x+=sign(ospd*xs)
                    y+=1
                    ii += 0.5
                    }
                else if !(place_meeting(x+sign(ospd*xs),y+2,obj_obstacle_basic))
                    {
                    x+=sign(ospd*xs)
                    y+=2
                    ii += 1
                    }
                else {canmove = 1 ; ii = abs(ospd)}
                }
            else if (ys != 0)
                {//Move along ramps
                if !(place_meeting(x-1,y+sign(ospd*ys),obj_obstacle_basic))
                    {
                    y+=sign(ospd*ys)
                    x-=1
                    ii += 0.5
                    }
                else if !(place_meeting(x-2,y+sign(ospd*ys),obj_obstacle_basic))
                    {
                    y+=sign(ospd*ys)
                    x-=2
                    ii += 1
                    }
                else if!(place_meeting(x+1,y+sign(ospd*ys),obj_obstacle_basic))
                    {
                    y+=sign(ospd*ys)
                    x+=1
                    ii += 0.5
                    }
                else if !(place_meeting(x+2,y+sign(ospd*ys),obj_obstacle_basic))
                    {
                    y+=sign(ospd*ys)
                    x+=2
                    ii += 1
                    }
                else {canmove = 1 ; ii = abs(ospd)}
                } else {canmove = 1 ; ii = abs(ospd)}
            }
        else
            {
            x+=sign(ospd*xs)
            y+=sign(ospd*ys)
            }
        }
    }
else
    {
    x+=(ospd*xs)
    y+=(ospd*ys)
    }
    
return canmove

The movement code currently has a tiny problem with it where moving against slopes a certain way actually makes the player move at roughly 130% their speed, but that will be fairly easy to fix when I have the time and is fairly low priority. There will likely be multiple iterations before the game is finished, and I'll be sure to release the movement code again when things are in a more finalized state.

 

Week 3


Gabe's Game
​

On an indie team, being efficient with your time is important. As a solo developer, it's imperative. Traditionally, when adventuring into the early artist process for video games, you'll have piles of concept art, mood sketches, character concepts, often even prop art concepts. You'll find an art team deliberating over details in a way an individual just can't. So how am I possibly going to make an attractive game solo? By being strategically artistic.

​

My first step is to clearly define what I need to communicate visually. I know that I want the player's feet to feel powerful to suggest that jumping off of things is how you deal damage. I also don't want to include text in my game, so I'd like to be able to emote a lot through the character. Generally, really expressive characters require a lot of animation, so I needed to figure out a way around that for this solo game. I came up with this little fella while imagining a character with a holographic iMessage-ish head:

​

So with this design, I can make the head a separate object. I can then animate facial expressions and communicate through imagery projected on the face, all while looping animations for the body. Quick and efficient expression, one goal met. However, the legs look weak and I want the art for this game to be a bit more involved than the above style, so I sketched a bigger version:

​

Closer to what I want, but the legs still aren't grabbing enough attention. I decided to take this design into 3DS Max. Having done 3D art far longer than game design or drawing, I feel more comfortable tweaking a block out quickly in 3D space.

​

I ended up squashing down the body and making it bulkier to better fit within collision boundaries I like. I've clearly amped up the legs, but because I've also intensified his shoulders and hands, they aren't carrying the weight I want them to. The above is a rectangular silhouette, if I want the base to feel like the heaviest point, perhaps a triangle would work better.

​

The triangular shapes wonderfully depict the composition I was aiming for! This design feels way more powerful and deliberate. I'm still able to emote efficiently, the feet are obviously the most powerful part of the body, and I can fit the character within my preferred collision boundaries. Ultimately, removing unnecessary detail and refocusing on the visual information I need to communicate was the solution.

I decide to head back to 3D. I'm thinking I want to do 3D flat lit characters rendered into sprites with 2D handpainted environments. My logic is really just that I have plenty of experience with both of those things. I would never recommend exclusively sticking to what you know, but learning to program is enough educational exploration for one game.

​

Ended up throwing in more detail than I had anticipated, but I'm pretty satisfied with how they're looking. I don't want to get too attached to any part of the character this soon, so I've kept them very modular. Preparing for inevitable changes to your art and style is imperative this early on. Gameplay takes priority over visuals, so I don't want to limit myself with something that's difficult to tamper with.

All in all I'm off to a good start! The world for my game is now brimming with color in my imagination. I can see an iconic personality for my character and ways to make design points clearer than they could be without him. Best of all, the time commitment to this early character draft was pretty small. Now with a clear vision for my experience, I can really start work on building a world. There is a lot of work to do, so I'd better get movin...

​

...

 

PT2

Got questions, opinions or cool early game art to show off? Put all of that into the comments!

Want more immediate posts from us? You can follow William on Twitter here and follow Gabe on Twitter here

 

Goofy Looking Skeleton is not a bad name for a game, just sayin'. Also thanks for the code drop, I'll czech it out when I get a chance.

I concur that that robot looks amazing, though. I wish I had better 3D chops. There's a Blender icon on my desktop that stares me in the face every time I boot up. One of these days I will git gud.

To me early Character design is a balancing act between what looks good, works with the needs of your project, and fits the project theme. It's challenging but a lot of fun to figure out, and one of my favorite parts of early design, in part because I usually get to try something new.

My current project is a roguelite, so the focus isn't so much on one character, but rather how much variety I can get away with using a standardized animation system. (while simultaneously giving the player enough pieces to fit their idea of 'cool' since they'll be designing the character visuals, in a sense.) I talk about it a lot in my devlog but the gist of it is to get the versatility I need I'm layering interchangeable 'component' sprites, which has the added benefit of giving some control over what those sprites are doing, both in terms of what frames they are displaying, but also their offsets relative to one another. So you can animate them without.. Uh.. Animating them:

Eye and mouth sprite frame swapping to support facial animation:

Spoiler

Using sprite offsets to approximate squash'n'stretch, as well as demonstrating the sprite stack can rotate.

Spoiler

(welcome to the kingdom of lengthdir_.)

Frame-swapping and rotation to focus the mouse cursor, position and rotation tweening to animate attacks.

Spoiler

…I do need to add more component sprites to really see how the system works, however…

But yeah, I love doing this stuff.

 

Thanks!

Puppet anims are a fantastic method of streamlining character animations. I think one of the things that makes me enjoy working on this blog so much with William is that every developer has to find what works for them. Its already been made clear that our methods do not always overlap, and I think thats fascinating. The workflow for puppet animations always feel too mechanical for me. However, I plan to use some puppetry for my Boss animations!

As a side note, I have updated my Icon and thought I would post about it here

 

Creating an Intelligence to Outsmart​

Week 4
William's Game ​

For the past couple weeks, I've been working on making the enemies for my game work. For a stealth game, an enemy's AI could end up carrying a lot of the gameplay's weight. Being stealth is, after all, all about outsmarting and outmaneuvering a reactive foe.

And... this. ​

So, between my extremely time consuming job and the commute that comes with it, I've been working on designing my enemy AI.

When you're programming something like a Goomba, you don't have a whole lot to worry about. You can juggle all of a Goomba's abilities in your head: walks right to left, falls off of platforms, turns at obstacles, kills Mario on touch, gets killed all of the normal ways.

But, when you're programming a stealth game's enemy, there's states of an enemy's awareness and proximity to the player that will determine their behavior. And so, allow me to unleash onto your face the most exciting programming tool in the world:

The Flow Chart

​

If that doesn't get you all hot and bothered, I don't think I can help you.

So, if you can get passed the sloppy handwriting, you can see what is the foundation for the inner workings for what will be the most simple enemy in the game: no guns, pure chase, has a lunge attack that adept players can learn to dodge. Another benefit of the lunge-attack that can be dodged is that this becomes an enemy that the player might see as a waste of ammo, making players who have saved up lots of ammunition feel privileged enough by their ammo surplus to dispatch these nuisances with ease.

Modular Design

A big help in laying out the behavior like this is that now I can segment the behaviors on paper to plan out as functions and subs to organize. Once I have each aspect of the enemy's behavior compartmentalized I can pick and choose pieces from it to integrate into different enemy types, while switching out some parts (such as close distance aggressive chasing switched out for aiming and firing a weapon).

This is a kind of modular approach that is hugely helpful in organizing code when dealing with more complicated AI. A good example of this kind of thing is in the way that a game like Doom handles its programming:

​

While that's a tad more simple than this stealth game's AI will be, it illustrates one of the benefits of having enemies with many possible states: small adjustments to a single state results in a totally different and unique challenge.

Part of what makes stealth games interesting is that you often learn multiple ways of maneuvering around and besting your enemies. Part of what makes this extremely easy for creating difficulty curves is that you can put a twist on each individual approach at a time and it will inject a fresh dynamic into the scenario every time.

The best and easiest franchise to illustrate this approach with is the Batman: Arkham Asylum franchise. The game gives you tons of safety nets up front for approaching enemies by allowing you to escape to gargoyles that you can perch and hide atop of. But later on in the game, the enemies wise up and this happens:

​

This changes the entire dynamic of a stealth hunt. You have the ability to jump to a gargoyle for safety, but not long before it will explode. It will get you out of a pickle, but you won't be able to use it again.

The idea of small differences forcing players to improvise is taken to its logical conclusion with a genius boss battle in Arkham City where you have to battle Mr. Freeze, who can be attacked using any one of your stealth methods.

​

But every time you use a method on him, he immediately upgrades his suit and approach to prevent you from using that method on him again, forcing the player to constantly improvise to make it through the fight.

​

The Mr. Freeze boss fight is almost like an entire game contained to a boss fight, forcing the player to employ everything in their arsenal to adapt to slightly evolving threats. In a way, it takes a complicated setup that the player can wander around freely and makes it more challenging and interesting by simplifying it in ways that reduce the player's choices in how to handle a situation. Things become more complicated by becoming more simple.

And just like those Doom enemies up above or Mr. Freeze's suit, I can make an entirely interesting threat every time I change something small in an enemy's structure. It's the easy and smart way to make a fun stealth game.

​

I still have some work to finish with the enemy's AI before I can really show it off, so that will need to be in a follow-up post. But for now, rest assured that a good look at enemy AI is right around the corner!

​

Are there other methods of organizing AI that you are interested in? Are you a flowchart enthusiast? Do you perhaps have no idea what was being discussed in this post? Tell us about it!

Want more immediate posts from us? You can follow William on Twitter here and follow Gabe on Twitter here.

 

Week 5


Gabe's Game


Indies have less time, less money, and fewer people than AAA studios. So scoping your game to be within your abilities is imperative to success.



Which of the above images is more pleasing to look at? I used the same objects for both, in the same room, so they are equal, right? Obviously not, the images only have a few resources but A clearly takes better advantage of them. First of all, A combines the resources, allowing them to compliment each other. Secondly, it focuses the viewers eye in on the resources, keeping your gaze from wandering into less interesting portions of the scene. For B, you may or may not know what's missing, but what any person can do, is identify where information is lacking. Making games is similar.



So how do we plan games we can really finish? How do we focus the player in on the content we have? I don't mean get it out the door, I mean polish and make truly complete. How can we use our resources to compose satisfying, coherent experiences?

My opinion is that massive scale games are best made by massive scale companies. We have GTA online, Horizon Zero Dawn and WoW being produced by huge teams and we find bugs in them daily. Isn't this a pretty obvious sign that we, as indies, should play it a bit safer? Of course there are exceptions and these exceptions can even drive major studios to new territory. However, games take years to make, and I prefer to work with the odds in my favor.


​

Unfortunately, there isn't a universal team size to game size ratio. Knowing how to properly scope your game requires the context of your experience. I have experience producing all of the art for shipped titles, so my ability to estimate art deadlines is relatively refined. Having never programmed a full game, it's very difficult for me to properly plan programming deadlines.

When thinking about bosses, I had one idea for a giant creature who would try and stab you with huge spears. The player would need to dodge the spears, but then platform up them to get to the enemy. Another idea I had was for a boss battle where the floor and ceiling were kill zones. The boss would shoot rockets at you, forcing the player to platform on the boss's missiles to get to them and deal damage.

​

Both of these boss battles use the same basic concepts: use the enemies' weapons against them. However, I already have platforming on rockets working in my game and I know it's fun. I also already have kill zones and moving cannons. So, the second idea would mostly be built using scripts I've already made.

​

The first idea, on the other hand, would require completely custom scripts and I cant even be sure if it's fun until it's all built. As a novice programmer, it's just not worth it. We as indies have to make the absolute best use of our time and prepare for roadblocks. Expect bugs, expect artist block, expect ideas you thought would be amazing to suck.

​

Plan as if everything will go wrong, then double that time. You may be left with a game much smaller than you would like to make, but the extra time always fills up fast. Basically, a small polished game is usually better than a giant empty one.

 

...No offense, but who are you guys? You're kind of preaching to the choir here with these posts I think, hahah!

 

The intro post on our site does a pretty good job of going over our backgrounds, we both have about a decade of game development experience and a successful indie game made in game maker. The purpose of the blog is for us to go over our logic for everything we build in these new games, start to finish. Posts like my last one are more abstracted, but hopefully contain some useful information.

Assumably, not every dev already knew/agreed with all the information posted here thus far. If you did though, we hope the comments we make on each others post inspire people to think critically about their own workflows. The opportunity to discuss and refine workflows makes us all better!

 

This is a pretty good thread. I like a lot of concepts here and it's nice to read! What's your successful game BTW?

Also, i'm not sure if it's just me but your profile pics remind of the guys from vlambeer, lol

 

William and I made See No Evil, it's in the game maker showcase and on Steam. Glad you're into the thread!

Also, oh my god your right.

 

Oh nice! I remember seeing that game when I was first deciding to buy Game Maker. I always thought it had great art, not into puzzle games though so I don't know how it plays. Well done, though.

 

Making a Full Game By Yourself With a Full Time Job

Week 6

William's Game ​

This marks the sixth week I've been working on my game, currently under the working title "Bone Boy in Blob World." At this point in any full-time development schedule, I would have most of the main game mechanics fleshed out and maybe even some fairly developed early game levels.

However, this isn't a full-time development schedule. Unlike with many of my previous projects, I've been developing Bone Boy in-between a full-time day job. Not just any full-time job- a full-time job that I also spend at least two and a half hours on commuting every work day. This, combined with extreme ADD, means I have to be really conscious of how I'm budgeting my time in order to be an efficient developer.

So, have I been succeeding so far?

Well, not as much as I'd like. Compared to a lot of my other projects this one has been moving at a snail's pace. I've had to struggle with a lot of difficulties that come from this in different ways.

Progress

The most obvious aspect of development to take a hit from a highly restrictive schedule is progression. For reference, I have spent the past two weeks trying really hard to hammer out the AI of a basic enemy. So, what do I have to show for all of my hard work?

​

The only enemy behavior that's finished enough to show off is basic standing guard and becoming alerted. There's plenty of code developed for the rest of the behaviors, but nothing that can be tested or shown. This is the culmination of many sleepless nights and half of my week being solely spent on driving to work, working my ass off, driving home, passing out, and waking up just in time to get ready for work again.

A big part of the loss in progress influences the next issue...

Morale

Despite being the basis of the American dream, killing yourself at work to make a living while simultaneously trying to make a name for yourself is more of a nightmare than anything else. It's hard to keep spirits high when you're making less progress than you're used to and spend days without making any progress every week. What's even worse are the days that you have off but are too brain-dead from work to make any decent progress.

​

It makes you feel like you're wading through waist-deep drying cement toward your goal. It makes you feel like your project is a pipe dream. It makes you feel like a failure.

And then you decide to stop making background code long enough to make something testable and you have this to show for it:

​

You start to break down. At least, I know I do. I've made over 4,000 tiny game projects since I started programming in the fourth grade, and I've lost the majority of them to broken computers and haven't batted an eye. Yet now I have spent weeks on something that feels like it may have otherwise taken a couple evenings, and with the rest of my time being dedicated to one of the most mind-numbing jobs on the planet that pays barely enough for me to survive, it's hard to keep myself sane.

However, I've been doing something about that: since the first day I have off of work is usually where I am too brain-dead from thinking about nothing but work and driving for 4 days straight, my roommate helps me stay sane by driving me around California. Last week we went to the movies in Dublin, this week we're going to the Monterey Bay Aquarium (I'm actually writing this from a laptop connected to a hotspot).

​

Without trips like these, I'd surely be drowning in my own misery. Being occasionally reminded of what you love to do outside of work and your obligations makes for a healthier mind, and healthier minds make for better development.

​

Commitment

With shaky morale and slow progression, commitment is the third major element of development that takes a huge hit. When things are particularly miserable and slow it's easy to wish you could abandon your idea for something easier, simpler. It's an appealing idea, for sure, but it comes at the cost of loss of time already spent and can easily become a slippery slope into constantly starting new projects but abandoning them during the inevitable slog.

For myself, experience with the regret of leaving projects behind is what keeps me from abandoning this one. As I've mentioned before, I've made thousands of games and lost tons of them. The ones that actually did bother me, however, are the ones that had potential but I moved quickly along to either avoid challenges the project presented that I may have deemed unworthy of the time they would demand, or because I felt that I had a newer, better idea that I wanted to try out.

So, with that wisdom that can really only be felt with experience, I'm holding fast to my commitment to this project.

Even then, when times get rough, and I look at the scant progress I've been able to make...

​

...I have moments where I wish I could just make a simple arcade shooter instead.

​

How do you stay motivated? Any game dev want to share their work hour horror stories? Let us know!

 

I hear you!
I'd also like to have more time to spend on personal things, but there's soo many obligations.
The beginning of the year I had more free time, but now it's back to being busy again.
Sometimes I feel like I want to throw everything down and just do what I like anymore. Unfortunately, I have a conscience and can't let people down. Also, according to Maslow's hierarchy of needs, self-actualization only becomes important when all other needs are fulfilled. Perhaps this theory isn't spot on, but I think living as a game-developing hermit, it would soon become apparent that other things are more important. As with all things, it would be good if we could find a balance....

Also I sometimes feel like a spoiled brat for wanting to do only do what I like. A couple of generations ago, people had to spend all day every day just to have enough food and not freeze to death in winter, and here I am, whining about how I don't have enough time for recreation (because that's what it is, for most of us here).

 

I'm more of an applied behavioral analysis person than a Maslow person myself, but I agree that there's a balance we should be able to find.

I definitely think that we shouldn't feel guilty for wanting to do the things we enjoy if the things we enjoy are not hurting others though. Yes the people of previous generations had lots of responsibilities, but if Vincent Van Gogh had felt his pursuit of his craft to be selfish perhaps the whole world would have missed out on a brilliant painter's influential pieces. I'm sure not all of us will become Van Goghs, but I see lots of virtue in artists putting themselves into the world.

 

Gabe's Game


Its easy to forget how important camera systems are. In good games, you don't even notice them. If you're thinking about the camera system while playing, it's probably because it's annoying or disorienting. A good camera does two things: The first is to clearly show information in the world pertaining to gameplay. The second is to move as seldom and as smoothly as possible because brains get pretty confused when presented with the illusion of movement.

As a disclaimer, I have worked as a designer on multiple shipped titles. Not a programmer. I've never actually done the legwork on a camera system, but how hard could it be?

I started with a horizontal camera movement set up similar to Mario.




These new blue lines work similarly to the inner white lines I had before however, the blue lines now pull in toward the center when the player is outside of them. This pulls the character to the center of the screen as they pick up speed. If the player stops moving, the blue lines snap to their original position. Allowing the player to move freely when they're near the center of the screen without jerking the camera around.



The white lines on the outside represent the furthest the character can move before the camera snaps to the player speed. This keeps players from being pulled off screen when pushed by a fast moving objects. It's really important that the character is never off screen in combat because dying without knowing why is the absolute worst.



As one might imagine, the camera bounds are relatively to the camera zoom. This means more space for the player to move around before the camera has to move. As previously mentioned, the less camera movement, the less disorientating.

What progress we have made! the camera smoothly follows the player and does a good job of keeping them near the center of the screen. Even having never programmed a camera system before, I made quick work of this. May as well make vertical movement work the same way.



Noooope. the same system applied to vertical movement looks awful while wall jumping. Since the player is moving up and then back down quickly, the cameras only being pushed up bit by bit. Inconsistent, abrupt camera movement is really uncomfortable, especially in a game about wall jumping. I'm going to need something smoother.




I would include a picture of butter for the simile, but this post is already image heavy. There are two things I should mention. My horizontal movement system conveniently prevents the camera from jerking horizontally as players propel themselves off the wall. I also keep the camera from moving up when the player jumps while standing on the ground. Pulling the camera up then back down is, unfortunately, common in games. I'd say it can be done tastefully, but is more often than not a poor practice. If there is anything immediately above me worth seeing, I shouldn't have to jump to see it. If there isn't, why move the camera?
I think I'm done, now to test in a more realistic environment.

PART 2 BELLOW​

 

****... If I had a better test environment set up from the get-go, I would have noticed the above problem earlier. My vertical movement system is meant to prevent the player from crossing the bottom blue line. The issue is, if ever the player is above an enemy, they likely won't see it. This sort of thing leads to keyboard-smashing frustration as players unwittingly fall to their death.

​

a short and gentle pull toward the center of the screen helps make the whole play space easier to understand. This pull only activates when the player is touching the ground, so my smooth wall jumping camera movement isn't affected.

Here is what the final result looks like.




The eye thing at the end is an example of the camera targeting a point of interest when in range. I plan to use this to occasionally focus on important objects and lock the camera during battles in smaller rooms. Anyway, that's a wrap.

Please don't try and copy this system. Every game requires a camera that works best for that game's specific gameplay. If you'd like an in-depth guide to camera systems throughout the history of gaming, I encourage you to check out this awesome GDC talk by Itay Keren, of Mushroom 11 fame.

If your interested in these posts, click below for a weekly notification when they go up!

​

 

Week 9


William's Game ​

Last week I found myself working hardcore on two different things: enemy AI and a home-built developer console I could use to manipulate the game during runtime (something that there's not much native support for in Game Maker, unfortunately).

So I had to ask myself: which do I write about? Still unfinished AI or an unfinished developer console?

​

The answer was neither because my car broke down and I spent the whole week fixing that and visiting family who came in from out of state; but I digress. My point is: I need to take a serious look at what I've been doing development-wise to be missing crucial but simple milestones.

1. Fighting a War on Two Fronts

Now, back a few years ago, I could take on three or more of the major tasks in programming a game at once and have results in no time. Hell, just last year I was juggling three major projects for a company that had contracted me and all I needed to get these things done was one assistant to help me with the busy work aspects.

That's the way that I've worked for years and it's not going to work anymore. I haven't had my ADD meds in over a year, I work a more stressful job than I'm used to, I'm going to school full time, and I need to change my methods of development or I'm just going to burn up with everything going on around me at once.

"This is fine"​

2. Maintaining Momentum

When I look at the code for either the console or the enemy AI, neither looks like they add up to the amount of time I've been working on either, and that's just not good for either progress's sake or my motivation to continue putting in my spare time on this.

Right now the enemy AI looks like this:

​

For somebody with no programming experience, that may look somewhat impressive. For me looking at weeks worth of work, that looks like amateur hour. Especially when the current result can be summed up as this:

​

And this:

​

If I were working on this two years ago, the enemy would be attacking and no longer use placeholder graphics by this point in development. He would probably even have multiple variations completed.

For reference, in roughly the same amount of time (give or take two weeks) I had created a far more sophisticated AI system for See No Evil.

As Gabe has previously pointed out, everything that we do takes time and the the more conservative estimates for development time for a one-man-devteam has me looking at putting years into this project to come up with something good. This kind of thing can be really crippling to my motivation, and I'm going to need a lot of motivation to finish a commercial quality game.

This is just another reason why I need to move toward a more focused, one-goal-at-a-time approach to development. The more accomplishments I have, the more I am driven toward completing the project.

PART 2 BELLOW​

 

3. A Wandering, Unfaithful Eye

So, as I've mentioned, I have ADD that I haven't been medicated for for at least a year. Now, when some people talk about having ADD, they're making some quip about how they don't pay attention to things that don't interest them.

That isn't ADD- that's just being facetious and frankly a bit insolent.

I have legit ADD, and to save time describing what that's like, let's just say that my mind can occasionally wander from topic to topic so fast that it prevents me from forming short term memories and can happen so rapidly for so long that I might as well be having a 20 minute blackout where my mind just gets carried away but I can't commit any of what I was thinking about to memory.

A depiction of my ADD from another blog I wrote two years ago​

On top of this, I have slight obsessive compulsion, which means that my ADD mind can suddenly change topics to a new idea and then I'm stuck absolutely obsessed with pursuing it.

The ultimate result is that I get scattered very easily. Over this week and last, I wrote 4 different Game Design Documents for games that I don't have time to develop- some of these being tens of pages long.

But this is probably one of the least damaging of my unhealthy behaviors so far for one reason- they're giving me indirect passion and motivation to want to finish my current game more quickly.

So what now?

I've decided to actually do something about my reckless development in the form of a task list, and the three I've got in front of me right now are as follows:

1. Finish a single enemy's AI
2. Finish the developer console in a way that can be distributed through this blog
3. Create the player's means for combat

Hopefully, in two weeks I'll have at least the first one rounded off to report here!

What helps you to make progress in your projects? Can splitting your focus be productive? Let us know below!

If you're interested in these posts, click below for a weekly notification when they go up!

​

 

Gabes Game​

There have been countless platformers made. In many of those, there are a wide variety of enemies. So if you couldn't count the number of platformers made, you really can't count the number of side scrolling enemies in existence. So while you're not counting, how do you find originality?

You don't. You find what makes your specific game fun, then you push the player to experience that. I've found that the coolest moments in my game, are when I'm doing sweet air combos. Jumping from one enemy to another, or sending one enemy flying into his buddy. Essentially, the game is most fun when the player isn't touching the ground.

​

First things first, I needed an enemy to teach the player that wall jumping is your primary weapon. So I made this little frog guy, he has a spiky kill zone on his head and occasionally hops (the final character will have clear anticipation before jumping). The idea here is that the only method of killing this guy is a wall jump.

​

This is sort of accomplishing my goal. In practice, the enemies are pretty fun. But, they are hard to combo and don't keep me in the air as long as I'd like. These frogs create an interesting issue. Having kill zones on their heads doesn't encourage vertically, it makes falling downward a threat.

​

Instead of trying to stay in the air, I'm waiting on the ground to time my jumps, so I don't land on one of them. I decided to move forward by creating an enemy that is the least threatening while you are in the air.

​

This little dude shoots a giant laser to keep himself afloat (again in the final game the laser blast will have an anticipation animations so you can see it coming). When the player is on the ground, they have no choice but to run from this enemy but, when in the air, the enemy poses no threat.

​

Coooomboooos! The final bit there, where I jump from the frog to the laser thing, was crazy satisfying to play. That's the stuff that will make my game stand out from the hoards of platformers.

Next, I needed an enemy that would provide the player with plenty of platforms to use to stay airborne. Now, this is actually one of the first enemies I designed for the game. It shoots rockets at the player, the rockets don't deal damage but will crush you against walls or other enemies. As long as your touching the ground, these rockets are threatening you.

​

​

Oh hey, it doubles as a general platforming tool! Though this same thing could be accomplished with a static cannon and has been done before.

​

These two make for a challenging pair. The enemy shooting rockets is constantly pushing you into the laser enemy's laser. You may also notice that just adding a static square block makes this fight dramatically more interesting. It's worth keeping in mind that enemies are only a portion of the gameplay, interesting environments with dynamic props will work wonders for the experience.

I have early code for an enemy that slams the ground creating a deadly shock wave and a larger mech that shoots walls of rockets at you. Progress is slow, so I didn't have them at a place where I can show them just yet. Hopefully, these gifs are enough to peak some interest. Displaying my game as a unique experience, even at these early stages.

​

Art is soon to come...

 

William's Comment: I'm digging what I'm seeing, and have to say: I didn't expect combat to take that form. When you showed one of the earliest combat gifs, I was expecting that enemies would be mostly slow, deliberately moving challenges that the player would need to actively strategize against to find their Achilles's heel. Kinda like the first Kirby game, Kirby's Dreamland

​

If Whispy Woods were to stop dropping apples, he would be invincible.
Judging by your blue enemy that shoots deflectable projectiles at you that you can also kill just by jumping off of, the player is going to be way more free to approach combat how it suits them. Kinda like every Kirby game AFTER the first one.

​

Kirby doesn't need your stinkin' apples!
This is bound to create a more fun experience for a broader audience, which is probably the best possible thing since games with unique gimmicks that are too particular about how to use the gimmicks are way crummier than games that let people have fun with gimmicks. It's funny, because I would almost certainly have opted to make something more like I had imagined if I were to handle your idea instead of you.This is going to be great in two other fields as well. The first is that, with combat as approachable as it is shown, any combination of enemy types and obstacles can be interesting instead of dreadful. The second is that every battle can be approached in different ways, and enemies can be cleared out in different orders or even used as projectiles to clear each other out. I don't know about you, but I can see this being extremely attractive to the speed running community as the battle routing possibilities feel nearly endless.

If your interested in these posts, click below for a weekly notification when they go up!

​

 

Gabe

Over the last decade, I've watched countless GDC lectures and interviews. I've read loads of development blogs and dissected other developers methodologies. The primary lesson I've learned through all of this can be summed up in a single phrase: Absolutely no one knows how to make games.



Games often take years to make. That's years of daily influences, most of which go entirely unnoticed. Years of actions taken, opportunities missed and unwitting influences. However, there is a tendency among developers, William and I included, to preach anecdotal evidence as gospel. As if a handful of principles were responsible for a game's success or failure.
​

Satoru Iwata (former CEO of Nintendo) -

"Above all, video games are meant to just be one thing: fun for everyone"​

​

Jonathan Blow (creator of Braid and The Witness) -

"Everybody expects this fun thing out of all games... Maybe we ought to have different categorizations."​

​

Tommy Refenes (programmer for Super Meat Boy) -

"The things I've sacrificed are social. You kind of have to give up something to have something great."

​

Frank Lantz (Director of the NYU Game Center) -

"If you're sitting in a box watching a power point, instead of sitting under a tree, talking to your friends. You're doing it wrong."

​

I could go on for days. These developers contradict each others approaches but have each found success with their own methodologies. In an attempt to educate, they have all voiced their personal design theories, which is great. However, few design theories are universally correct, so we should all explore until we find personal ideals.

This extends into individual mechanics. Marios jump feels weighted, pulling you down to the ground with a thud.

​

Meat Boy is notably less restricted by gravity, making long floaty leaps.

​

Ori's jump is somewhere in the middle. Comparatively shorter than Meat Boy's but with a comfortable hang time.

​

Though drastically different, all of these games feel great to play because they offer unique perspectives on platforming. Not to say there aren't widely applicable rules. For example, each of these games characters begin moving downward the moment the jump key is released. This helps provide intricate control of the character while in air.

To be clear, your game very well may be ****. I don't want to give the impression that personal preference absolves you from critique. As developers, we play our games more than likely any other player ever will. As masters of the experience, it's easy to get blinded to its flaws. Players take our abstract ideas of gameplay and demonstrate how it functions realistically.

In conclusion, filter through other developers' theories to find what, in practice, works for you. Let players be your grindstone, helping smooth the flaws in your constructed vision. Also, I'm not ignorant to the irony of this post. As I've advised in regards to other developers, take everything I say with a grain of salt, or don't. Look, I don't know how to make games.

(My next post will be about my actual game)​

Read More post like this here - http://www.duelingdevblogs.com/2017/06/absolutely-no-one-knows-how-to-make.html​

 

​

William's Comment:

I agree with the majority of what Gabe is saying in this post. Games are both products and art forms. They're both subjective and have target audiences. I think the most off-base quote is Satoru Iwata's that a game should have universal appeal, since the medium itself isn't even universal and that's just a ridiculous and lofty, unobtainable goal. But, just about everything that somebody says about game design can be true as long as it is not taken as gospel.

A while back I wrote a review for GameMaker: Studio on Steam and it somehow ended up sticking around on the store page for it forever, exposing people to the fact that I have 15,000+ hours (that's over a year) spent in GameMaker. Tons of people would start adding me on Steam looking for information and help on making games. I tend to give most people who add me a chance, and try to be helpful when I have time.

There are three videos that just about every single person would direct me to in order to prove to me that they are well versed in game design: "Juice it or lose it" a talk by Martin Jonasson & Petri Purho, "The art of screenshake" by Jan Willem Nijman of Vlambeer, and Arin Hanson's seminal "Sequelitis - Mega Man Classic vs. Mega Man X".

These are wonderful videos to get you excited for game development at least, and at most put you in the mindset of crafting a coherent and fun experience. These budding devs who added me were using buzzwords that they grabbed from these videos to use as mud patches over glaring flaws in their games. I would point out to them that their controls stick, and their responses would be, "oh I'll make the game juicier™. Have you seen the Martin Jonasson and Petri-"


Yes, I've seen the video. Adding more effects would do nothing to alleviate sticking controls, and the person's game at that point was already a mess of particles and effects that made the game window as confusing as navigating a burning fireworks factory.

​

Too much juice! TOO MUCH JUICE!


And that's not even touching on how many people came to me with direct ripoffs of the Mega Man X intro stage because their takeaway from Arin Hanson's video was that the way to make a great game is to do exactly what Mega Man X did.

Look, I guess what I'm trying to say is that designing games is a lot like designing movies. David Lynch created a seminal masterpiece with Eraserhead.

​

But everybody who has tried to capture what made Eraserhead great in a bottle for their own films have come across as derivative and ****ty student films. It's great to learn from the greats, but what you should be learning is their passion, reasoning, and technique- the style and what parts of their reasoning or technique you agree with are up to you, and that's what's going to be your voice. If there were only a handful of "right" ways to do it, then there would only be a handful of good games and films and everybody else would have already given up.

And, uh, that's not the case.

 

Both these games look incredibly fun to play, and I think they both have a lot of potential. Really enjoying the thread!

 

If this forum wasn't dead I would say blogging all this would be worth it.

Right now I don't see the point lol.

 

Thanks JacobV, you rock!

The posts are also on our blog - http://www.duelingdevblogs.com/
We wanted to put the full posts here to do our part in pumping more life into this forum.

 

Gabe's Game​

DISCLAIMER: These gifs are recorded at 15 frames per second - My game runs at 60 frames per second. The animations depicted are not representative of the final, or even current, product.

I've been watching boxes jump around for too long. I have a character design ready to go, so let's get this thing animated and in game!

My characters build actually presented some unique problems. The body is almost entirely legs, a deliberate design choice. Putting focus on the part of their body that is used as a weapon.

​

This body composition presented some interesting challenges. It's very frustrating to control a character who doesn't seem to care as much about the action as you do. When I'm running away from a monster that's trying to kill me, I do it in a dead sprint. If my character looks like they're jogging, the player will feel like they're being held back.

When a character that's all legs runs at full speed, you get pretty dramatic effects.

​

The run itself feels great, when I'm running I know my character is going as fast as they can. However, stopping and starting both look really abrupt. The full extended legs are uncomfortably far from the idle pose, causing a snap to start and stop.

​

The character already takes some time to accelerate in the game, so I just added an animation to go with it. They now do a few quick steps forward before reaching full speed. As for stopping, making the legs come down naturally every time would require a few stop animations connected to specific frames in the run. I decided to optimize my workflow, stopping the character with a sort of body jolt helps the character feel weighted while compressing the work down to a single animation.

On to the jump. This is a pretty important animation, it's more or less the focus of the entire game. So I wanted something catchy and memorable, while also simple enough to not get annoying the ten thousandth time.

​

Taking advantage of my little robot, I went with a quick lower body spin. A landing animation would obviously help imply weight and impact, but maybe I've already made it.

​

The stop animation from before feels pretty good. This is one I might go back to later but, for the time being, I'm happy with it. Now for a bit of polish.

​

A little squash and stretch on the head gives them the final bit of character I was digging for. A wall slide and a blink later, I have my characters basic animations ready to go. Before wrap up, I wanna mention collisions.

​

In a game where jumping at the right time is life or death, precise collisions are imperative. My character's boxy head helps a lot with defining their bound box, but I also put deliberate effort into filling the box with the body and only ever barely breaking out of it.

So, that's that. Now every time I test my game I'll have a cute little action hero cheering me on! In the future, Ill be adding a lot more facial animations. I'm also strongly considering a few jump variations. For the time being though, this should work great.

​

 

William's Comment:

The animations look great so far, but I can't help but feel like there's still something missing. Gabe's implementation of a build-up animation for running and a stop animation, as well as an impact animation really helps to give the character some needed oomph. The squash and stretch of the character's head feels like it perhaps does more for the character quality than the conveyance of motion (at least to me), since the shape of the holographic box comes across to me as a stand-in for expressions.

Before Gabe and I ever made Dueling Devblogs, he and I had planned to work together on making a game with a similar focus on wall-jumping (though the game itself would have been far different from what Gabe is developing now). When we programmed a prototype for the platforming engine, I had been using Mario sprites from Super Mario Bros. as a stand-in while trying to make them feel more dynamic. Gabe and I ended up creating a system where the sprite would:

• Lean into running initially
• Lean back a bit as he picked up speed and the feet were what were carrying him
• Tilt dramatically with abrupt change in direction to show a bit of whiplash
• Tilt with the angle he was falling or ascending

The prototype was pretty underdeveloped and needed lots of improvement, but even this was a lot of fun


These are pretty minor visual changes (implemented with an entire system of additional functions to get it working properly) that do a lot to emphasize things like effort and aerodynamics- that is, reactions to forces and factors that can't be seen but are subconsciously assumed to play a role in movement.

Of course, there are some issues with implementing all of this with the way that things are currently set up- you want for any tilting or squashing of the character's main body to not be so extreme as to no longer adhere to a collision box, but with the way that Gabe is currently drawing the character's head as a completely separate sprite he would also need to use some "fun" trigonometric functions to keep the head projecting out of the neck whenever the body tilts.

Gabe isn't finished with his animation, and I'm positive he's going to continue touching up the look and feel of his character as he continues- Gabe is a graphic artist first and a programmer after the fact. He may go a completely different route with supplementing his animations that I never would have even considered, and since this is much more his expertise than mine I'd definitely trust him with whatever he decides.

 

Metamorphosis: How Player Upgrades Develop an Experience

I'm working on a game that randomly generate pseudo-infinite landscapes that you are expected to leave behind as soon as you're capable of doing so, never to see them again. Through certain inherent patterns in hopping between worlds and overcoming certain challenges, the player can begin to uncover secrets, a greater continuity, and, most importantly, player upgrades and items.

​

Setting up a world of possibilities
I had originally started working on this game some years ago with a concept that only included the player character running around in randomly generated worlds, hopping from portal to portal. There were no interactive elements other than the portals, and the player certainly didn't have any tools to work with (other than their legs, which they use to move around).

A gif from the original project ​

While the game worlds still require lots of fleshing out, they're currently made of certain elements: world tiles that impede movement, NPCs who the player can engage in dialogue with, enemies that the player must avoid, and portals that launch the player into the next world.

But, if the player can only run around, surely interaction within the world will become stale, and possibilities for gameplay ideas will run low. That's when I introduce player upgrades and tools to multiply what's already there via new dynamics.

The first dose of power: Tabula Rasa
When the player starts the game, the very first tool they're given right away is the Tabula Rasa.

​

Using the Tabula Rasa, the player can instantly jump to a safe home area I'm currently calling The Void. The Void is a jumping off point for the player where they can take their pick from a more varied and dense selection of portals than the player is likely to find in a single world.

​

There's a downside, however: making progress in the game requires that the player hop from world to world in consecutive succession. The Tabula Rasa allows the player to instantly access this area, which is great if all you're looking for is a new environment, but this also sets the player back to square one in terms of attempting to explore deep into the multiverse. It's a kind of blunt-force reset button for the player's current excursion, useful for it the player needs to restart an exploration pattern or escape from a situation where they find themselves trapped.

It's a clunky, imprecise tool that comes with some drawbacks from use. It completely shifts the situation the player finds themselves in. So, what's a good followup tool for the player to obtain next?

A Tool of Precision: The ShockWand
Obviously the player isn't going to want to deal with every situation by hitting a reset button. Sometimes the most powerful tool is one that allows you to manipulate only a single aspect of your environment at once.

That's where the ShockWand comes in.

​

The ShockWand is a destructive tool that allows the player with small aspects of the worlds they explore. A small obstacle in your way? Blow it up. An enemy closing in on you? Blow them up. An NPC getting on your nerves? Straight up murder them.

The ShockWand is one of the most conventional tools in the game, and one that you wouldn't expect to leave home without. However, it's not a tool that you start with and you may often find yourself in situations where you can't reliably use it. What may appear to be a standard given in a player's arsenal in most games is a privilege, not a right, in this game.

Since the player is expected to progress through the game up until the point where they obtain a ShockWand without one, much of the game includes aspects of gameplay where the player may be required to walk around annoying obstacles or retreat from enemy ambushes. After learning much of the game this way, as a passive and fearful trespasser in these worlds, the ShockWand paints everything that the player knows in a completely different light.

The game transforms from needing to explore on the environment's terms to making a path on your own terms.

The main drawback of the ShockWand is that it's clunky to use; to use it, the player must activate it, stand still, and then press the direction in which they wish to send a lightning bolt. Once the player activates it, they must send a lightning bolt in one of four directions. It's also not a tool that can be used in rapid succession, as it (like most of the tools in the game) has a cool-down time, which may make the player less than capable of dealing with more intense combat situations.

Compromising Precision for Power: The StaticBlast
Let's say that you do get ambushed from all sides by enemies and need a quick out, but are so deep in your travels that using the Tabula Rasa would waste too much progress?

The StaticBlast may be the solution you're look fo-

Dear God ​

The StaticBlast is an absolute wrecking ball of a tool. Planned to require an ammo supply to use, the StaticBlast is how you can get the safety and complete shift in situation that the Tabula Rasa gives you without necessarily needing to hit the restart button.

It destroys everything and, unlike the ShockWand, can be used on the go.

​

This is exactly the type of power-trip tool you use when you're either in an extremely hostile environment or just really want to make an entire world your b*tch. It creates a path of destruction that is unparalleled by anything else the player gets in their inventory, though if the player is attempting to find certain objects or NPCs in a world they may end up obliterating them on accident.

Tools of specific function
The Tabula Rasa, ShockWand, and StaticBlast are the major three tools that the player will use most often for the largest number of situations in the game. The rest of the tools that the player gets, however, are focused on making the game's nuisances easier to deal with.

For example: most of the game is spent hunting for portals to the next world. Eventually, this task is going to become tiresome. The best way to alleviate that? Give the player an item that scans for nearby portals, of course!

​

What's the design benefit of slowly giving players these tools?
This is a pretty old design trick, used in games from Metroid to Megaman to Bioshock, to make progression in a game feel good while evolving what kinds of tactics the player can use to proceed through the game.

Killing these guys is so much more satisfying when you just spent an entire stealth mission running from them ​

By giving the player these abilities over time, the game allows the player time to explore the world without convenience. The beginning stages of the game will be slow and require the player to be fast on their feet for what amounts to fairly minimal progress.

Once the player obtains the tools it will mean the world opening up and becoming easier to traverse. Every upgrade or tool allows the player to move faster through the environment toward real progress, accelerating the game and allowing the experience to shift and change at a very natural pace. Instead of the player taking these tools for granted as they would if they started with them right away, they will have real meaning.

By moving from having no weapon to having a weapon, the player will feel so much more positively about the weapon than if they had it from the start, and will be able to look at enemies as opportunities to succeed where they once saw unstoppable threats. And, really, what's more rewarding than that?

 

Gabe's Comment: I like the idea of shifting rapidly through many strange and interesting worlds. A problem I often run into with procedural worlds is the feeling that they would be more beautiful if they were pre-produced for me. Games like Minecraft and its infinite kin allow me to do the beautifying myself

​

Uneditable procedural worlds are often platforms for simple but solid mechanics. Examples of this would be The Binding of Isaac..

​

... and DownWell.
​

These experiences rely on mechanics that are basic enough to be water-tight. The less variables the core mechanics involve, the less opportunists the game has to **** over the player with things like unbeatable levels and cheap deaths.
Your project seems to fall somewhere in the middle. You aren't blasting through controlled procedural danger zones, but you aren't meandering in vast construction zones. It seems you're using your combative tools only as much as is necessary to dimension hop.
So, perhaps this is a procedural world about movement. You begin the game without the combative tools right? So you're tasked with moving strategically through the environments. The radar is a necessary tool because you primary goal is moving to the next dimension. The first weapon you get, the ShockWand, allows you to face threats, but at the expense of what was previously your primary defense, movement. As you mentioned, the StaticBlast requires ammo because it's incredibly powerful. You can both be destructive and keep moving. I think the tool that's missing is something that introduces more unique skill to movement. A dash, a teleport, whatever. Once I'm a skilled player, if I'm in a situation where my ShockWand is too slow and my StaticBlast is out of ammo, I don't want to helplessly wander. I'd rather use a tool I can master to make retreating skillful. When I'm going to inevitably run into enemies, I'd love to be able to choose between lead footed combat and nimble maneuvering.

​

I'm sure there's a lot more to come and I'm excited to see it. I have questions about style, marketability and motive, but I have no doubt all those things will be written about in due time. For now, I'll just wait to see how you move forward.

 

Gabe's Game​

When conceptualizing a game, my imagination generates an ideal. When the project kicks off polish is paramount and planned detail is intricate. Then reality sets in. I think it's easy for indie devs to become intimidated by the enormous amount of work ahead of them. When that pressure sinks in, things get rushed.





Two weeks ago I made a post about animations for my game. All of the animations in that post along with their implementation took less than 8 hours total. In other words, it was very rushed. Since art is the field I'm most confident in, I spent the week working on bugs and then sped through the animations the day before posting. The result was half-baked work. So, I took a deep breath and started fresh.

Old ​

New​

It really took very little time to drastically improve this jump animation. My whole game is about jumping, so the visual feedback for the jump is among the most important animations I'll do. Slowing down and doing it right was absolutely worth it.







Starting fresh is something I've had to do a lot with this project. I mean a lot. In fact, I've reprogrammed the entire game four times...



Before starting Dueling Dev blogs I shambled together a buggy prototype for a game where you wall jump up giant enemies. I had no idea how to program so this was mostly a Frankenstein of various programming tutorials.

​

Even in this broken ass state, it was pretty fun. When William and I decided to start Dueling Dev Blogs, I did a post about my early prototyping, in which I took this concept and expanded it. Now the player was deflecting projectiles.

https://3.bp.blogspot.com/-c2UH7RsC5bE/WWO0Kex9OuI/AAAAAAAAAq0/1h4Uds3P2YUSupa1tJETZUpwDVt7mG6aACLcBGAs/s1600/earliest%2B****.gif​

Hey this could be fun



This prototype took the project from a vague idea to something I could happily work on for a year or more. Unfortunately, my programming skills were still hardly existent. As such, the systems in the game were clunky and nearly impossible to expand on.

​

This is not fun


So, I scrapped the entire project and opened up a blank file. this time I was going to make the game's systems infinitely expandable. Now, if you're a programmer, you're about to shake your head. If you're not, I'll help you understand why you should shake your head. I not only made my systems way too open ended to be stable, but I had almost no comments anywhere in the code. Comments are just text accompanying code to remind you later how things work. When you have hundreds or thousands of lines of code without comments, the project becomes helplessly confusing.



Anyway, I managed to pull this together.

​

I love this gif. It captures the ninja-like feelings I had envisioned from the beginning. However, my code was scrambled and hard to read. Even though my programming abilities had gotten to a reasonable place, the project was too messy for me to be productive.



This gif, however, sparked interest in my game from a few different people. Most notably, an insanely talented programmer friend of mine. He asked if I'd be interested in us producing the game together. It took me quite awhile to decide, but ultimately I felt like my current code was going to be impossible for me to move forward on.



We decided to make the game 3D in Unreal Engine. The project's scope expanded as I began work on a fully 3D world.

​

A month into this, the programmer I was working with got a job offer for a senior position at Blizzard. It would be ridiculous to turn a position like that down, so I happily encouraged him to take it. The project had been my baby for a long time anyway, so I was uncomfortable from the get-go involving another party and evolving the concept.



I knew I couldn't go back to the project I had built. It was a total mess. So, once again, I opened up a blank document. This time I wrote a detailed outline of the systems I needed and how they would interact with each other before starting on any code. I then filled my code with detailed comments, allowing me to read through every inch of it clearly. Most importantly, I've been testing this thing nonstop. What has come of this is a project I feel is rock solid. The bugs I encounter are easily located and fixed and I'm able to expand on the game quickly and efficiently.



I am by no means a world class programmer, but my systems accomplish everything I need them to. I am confident I will redo some things occasionally, but no more starting fresh. This is the real deal. It feels great to play and I am excited about the future.

​