Category Archives: Programming

Feature Lock is the Place to BE

March 2, 2013 1:28 pm / Leave a Comment /

Oh man, finally.  What a great feeling.  I got the loot system in and working which is the last big feature for the game.  And with that, I’ve hit ‘feature lock.’  Basically, I’m finished building the game.  Now it’s down to content generation and bug squashing.  I wanted to hit this point a little earlier, but I should still be able to hit the May release date. (Is this the first time I’ve announced that?…huh, well, there ya go)  With that, on to what I done did!

Loot

Now when you kill an enemy, there is a chance that they will drop some loot.  This loot will be able to confer different bonuses to your stats.  Right now, it’s stuff like +4 to crit chance, or +5 to jump height.  There will be some more interesting stuff later, but the stat bonuses are fun to play with for now.  I’ve setup a system that, at the moment, has a cap at 10 items, with 1 equip slot.  Any items you don’t want, you’ll be able to sell for XP.  In programming language, the player has a list of inventory items, one of which can be marked as equipped.  At any time, the player can go through that list and equip another item or sell it. So excited for the possibilities that can come from these.

Cutscenes

The story is going to be a big part of this game.  It’s based on my characters so we need to be able to hear their voices.  Well, “voices.”  I’m not planning on any voice work, but you can read what they say.  Anyway, I’ve setup a text scroll and headshot display so we can have conversations.  I’ve tagged spots in the level with cutscene numbers so as the player get to those spots, direct control is taken away and we watch the story unfold.  For this I basically have a giant struct of cutscenes, and a class to hold them.  That class gets called with the cutscene number and it returns each line of dialog until it’s over.  And once it is over, control is given back to the player and they can continue from there.  It’s like this is becoming a real game or something.

Save/Load

I hate games that make me manually save. So, this one won’t.  Once you finish a level, the game autosaves.  And once you start the game back up, it checks to see if a save exists and allows you to continue.  Right now I only have the one save slot, though since this is a PC game, you’ll be able to just get at the file whenever.  I want to add more slots, but that’s fallen under the “Nice to Have” list.  But basically, all we need to track is what levels have been completed, and the current stats/inventory of the Player.  As a result, the save file looks like it’s maxing out at about 10KB.  I love how tiny that is.  I’ve basically just got a class for Save() that, when called, will pull the level and player info, serialize the class, and write it to a file.  Currently that all happens in the same main thread as the game, but I will probably put that into it’s own thread so it can save in the background.  It’s such a small process that it shouldn’t create a problem where you’re staring at a “Now Saving” screen anyway, but still would be nice.

Art

While I’m not showing it off here, I have some of the actual art in the game now.  Mark is basically finished, and so is the first world tile set.  I have a solid starting point for the first wolf enemy which should be getting finished soon.  Though the biggest breakthrough on the art side is implementing Parallax Scrolling.  Since I first started designing the game, I knew it needed to have that.  And now it does.  I’ve basically got two layers in the background that move at appropriately different speeds as the player moves.  Probably the coolest part of the whole thing was that it took about a half hour to implement and practically worked on the first try.  To create the background, I’ve got an image that can loop, so I take the width of that, calculate out how long that needs to be, and repeat it to fill out that length.  Then, as the player runs, I pull in his speed and use that to move the backgrounds.  And I tell ya, having that stuff in there makes the game look infinitely better than those early screenshots of the red block and the blank background.  Once I get some final art, we’ll get some real screenshots up here.

So what do I have left? The biggest thing is the art. I do need to finish the story/dialogue.  I have the broad strokes figured out, but need to lock that down and start dropping it in the game.  I also still need to finish level/world design. Then there’s the music/sound. That I will hopefully be able to outsource as I know basically nothing about it.  But then it’s beta time.

And what a time that will be.

Posted in: Otis, programming

Tools can be a Good Thing

December 26, 2012 3:59 pm / Leave a Comment /

Oh man, did that text document way of creating levels get tiring.  I always marveled when seeing actual developers and the crazy awesome tools they had at their disposal.  I didn’t think I’d need that, especially not for this game.  But as I started adding switches, and scripting, it became clear pretty quick that my 1s and 0s wouldn’t handle it anymore.  So, I built a level editor:

Here's the beginning of level 1

Here’s the beginning of level 1

It’s a relatively simple form.  It just loads the serialized level, drops the images where they should go on the grid, and from there I can select individual or multiple blocks to make changes.  This has proven to be especially useful when filling in areas with blocks.  All I have to do is a quick shift-click and select “Block” from the dropdown.  DONE.  I just today finished converting my old txt documents to this new editor and will use this going forward.

All this made me realize that these big studios don’t build these tools just for the hell of it, it actually makes their job significantly easier.  I spent about a day and half making this thing, and it will definitely save me way more than that by the end of the project.  And hell, if I can get it full featured enough, I may just throw it into the game to let people create their own levels.  Or not, I should finish the game before adding more stuff to the pile.

But the lesson here is clear.  If you’re making a game, and you have the means, build yourself some editing tools.  You’ll be glad that you did.

Posted in: Otis, programming / Tagged: , ,

I’m Really Good at Playing my own Game

December 3, 2012 4:00 pm / Leave a Comment /

This is a lesson I learned rather quickly as I had my first beta demo for friends.  I have the first world about 75% designed along with the first boss.  I also now have switches in the game for moving platforms and other level geometry on the fly.  But that’s not as important as what I learned watching other people pick up that controller and run pixel Mark around.  My game is kind of hard, but I’m really good at it.  Sitting there for months alone, constantly tweaking and rebuilding and running through the first few levels in the perfect route, I couldn’t see the forest through the trees.

I was constantly upping the game on myself.  This jump could be harder.  This enemy could be stronger.  This switch could do worse things.  I thought I had a solid demo that would be somewhat challenging, but people would blow through.  I was really just looking to see if people thought the platforming felt off in any way.  Then the first of my friends had a rough time on the first level. Then so did the second, and third.  Next thing I know, I’m am getting those looks of disbelief as they see the next level that lay before them.  I was in no position to tell them I found the first couple levels easy, because they didn’t.

This jump to open the second level was not a welcome idea

So now I’m taking a second look at my level design.  I obviously need to pull back a bit and think more about the challenge to the end user and not the challenge to me.  It was something I really needed to see and has re-centered how I approach level design from here on.  I will say that just about everyone was able to finish the 5 level demo, they just lost a lot of lives getting there.

It’s also nice because I was worried I was running through all my tricks really fast.  But now being able to stretch things out a bit more, I can make each level it’s own challenge in a slow ramp up to the real stuff instead of front loading everything.

On the art side, I’ve decided to throw away the pixel art.  Well, sort of.  I’m not going to create pixel art in the traditional sense, but I’ll be hand drawing the art in a pixelized style.  I think this will help the game look better (as I know how to draw better than I know how to pixel) and give it a more cohesive look to tie into the comic.

And obviously the end of the year release date is officially out the window.  The engine is pretty much done save for some scripting I need to clean up.  It was fun building my own engine from scratch, but I’m not sure I’ll be doing that for my next project.  Anyway, I feel like an official game studio now as I’m announcing a delay into the first half of 2013 for Otis.  We will announce a more solid release date when we have it.

Posted in: Otis, programming / Tagged: , , ,

Animation and the Lists that Love Them

October 21, 2012 11:21 am / Leave a Comment /

Oh man, how is it that every time I work on a huge project, I forget about Lists?  I don’t know why I keep fighting for Arrays.  I just don’t.  The only thing I can figure is that Arrays were the first structure I was introduced to in programming and it opened a whole world for me. I’m not sure how it was for everyone else, but that was about the time I had that light bulb pop up over my head when I realized how powerful programming could be.  I can do ANYTHING!

So now I’m working on switching any single dimension arrays to Lists where it makes sense.  One of those big places was in my animation engine.  Because each animation could have a different number of frames, it makes sense to use something that lets me add and delete as needed.  Speaking of which, I finally got a walking animation working.  However, it’s of our old friend the stick figure, so I won’t be sharing it today.  What I will be sharing is the first pass at a pixelated Mark:

Early art is both the worst and the best all at the same time.

Anyway, for the animation, I basically just run a few checks to get the next frame.  I see what status the Character is in. I say Character and not Player because this animation engine will run for everyone in the game, enemies and such included.  So once we have the status (i.e. Walking) we check was the last status was.  If it wasn’t walking, we return the first frame.  It if was walking, we check the timer.  When the timer expires for each frame and the status is still walking, we return the next frame.  And once we hit the last frame, we reset to the first.  If at anytime the status changes, like to jumping or idling, we drop out of the walking animation and switch to the next one. The reason for the timer is to give some space between each frame.  If we just blink from one frame to the next without any kind of delay, it’s basically a blur.

And so, the art heavy portion of the game really kicks in.  The odds of us hitting our end of 2012 date are basically a million to one.  Partially because of just the time it takes to do all this non-coding stuff, but also, I’ve been adding design elements as I’ve been going.  This is going to be much more ambitious than just another 2D platformer.  I’m stupidly excited about where this is headed.

And I’ll leave you with one last piece, early art of the basic minions you’ll be jumping on:

I swear it’ll get better.

Posted in: Otis, programming

It’s not my World, I just Jump in it

August 23, 2012 7:58 pm / 1 Comment /

It’s about time for another update.  I’ve made some fairly significant progress and I’d like to share.  The biggest of which is the world map. I finally have a screen where you can walk around and select your level.  It was kind of hard to suddenly stop thinking about physics and gravity and hitting stuff and just break it down to moving in the cardinal directions and stopping at a level.  But it works.

You’re the smiley face!

Like with the rest of the game thus far, very basic placeholder graphics.  What I ended up doing was creating a matrix similar to the level (I’ll explain that shortly) and setup the levels each as nodes.  Each node has what direction the player can move in built in, so currently the player is on a node that can only move left and down.  If the player hits one of those buttons, they will move in that direction until they hit another node.  Pretty easy stuff.  I still need to block off the later nodes until the previous ones are beaten, but that can wait.

And as with most sections of the game, new programming means new bugs!  Basically if you mash the directions while moving around, there is a chance that you will fly off the map and travel forever.  Don’t worry though, I’ll have it fixed before we launch.

As for creating the map, as well as the level, I decided to go with a pretty basic matrix.

For instance: 0 0 0 0 1 1 1 1 2 0 0 0 0 0 0  is essentially what that first line of the world map is.  The zeroes are empty space, the 1s are the pathways, and 2s are the level node.  To create the whole map, it’s just mulitple lines of that. So…

0 0 0 0 1 1 1 1 2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
0 0 0 2 1 1 1 1 2 1 1 1 1 2 0

As a result, this makes it super simple for me to change the layout of any level or map on the fly and see those changes immediately.  It was important to me to make something that worked quickly when it came to these kind of design elements as I knew I’d be doing these steps over and over again throughout the process.

Those -1s can’t be good for that guy

I’ve also made some progress in some of the extra flourishes that I want to appear in the game.  I’m not going to go too deep into my design philosophy for it right now, but I like number flying off dudes.  A lot.  So it was important to me that I had that in here.

Now the inspiration for the code behind it came to me while I was running.  And that just meant I had to run that much faster to get home and write it down before I forgot.  Basically, when you hit an enemy, or are hit yourself, the game takes the position of where the hit occurred, and draws the number.  It then will rise up off the initial point of contact for a period of time before it disappears.  It’s a really nice effect that I’m super excited to get working.

So that’s basically where I am with the game.  I’ve squashed some pretty serious bugs when it comes to the platforming, but I’m still playing with the numbers and working on that nebulous “feel.”  I now have the task ahead of me to get the world map 100% functional.  But once that’s ready, it’s time for some real design theory to kick in.

I’ve also got some early art that I may be ready to show next time.  As much as I love the stickmen and their red blocks, it’s about time they get the hell outta here!

Posted in: Otis, programming / Tagged: ,

Building an Engine that Runs on Bad Words

July 12, 2012 10:04 pm / 2 Comments /

I have a bad habit of yelling awful things at my computer when my programs don’t exactly work.  It usually results in a few hours of yelling followed by immediate deletion of all work in those hours, followed by about 15 minutes of writing a working solution.  Not exactly the best process, but it works.  Such was the case with collision detection between the player and the world.

I originally started by running a quick calculation on where the character was vs where the world existed.  This got way too complicated incredibly fast.  Running all that math all the time probably wouldn’t have been great on performance either.  So I started looking around the olde internet and stumbled upon the most basic solution: Bounding Boxes.  DUH!

Player in the process of jumping on an Enemy

How I overlooked that I’ll never know, but all 2D games run on bounding boxes. For those not in the know, bounding boxes are invisible boxes that surround the player and world to figure out what they should do when they hit each other.  XNA has a nice class for Rectangles that you can use and just check if they intersect.  Suddenly instead of calculating placements of everything all the time, I was calculating a bounding box once and running easy checks.  While it gave me a good starting point, I still had plenty of work to do.

I’ll get into my level building process in another post, but once I had that down, I had a few things to check aside from the collision.  There was also the matter of gravity and making sure that kicked in when needed.  There was a fun instance where you could walk off the edge of one platform and just stay at that height so long as you didn’t jump.  Not exactly game worthy.

The funny thing is each time I ran into a strange bug like that, the problem was the complexity of my code.  As the code was simplified, things began to work better.  What started as several hundred lines was cut down to about 80.  The simpler the better.

And what’s really nice about the engine is that it’s very modular.  If I decide to change the size of my tiles or the player, everything will automatically adapt.  Nice to have as I begin to move onto actual game design.

Once I had the player actually walking on the world, it was pretty simple to extend the Character class I had built into an Enemy.  They dropped into the world just as easily.  Using the same Bounding Box idea, I was able to run easy checks on whether the player was jumping on the enemy and killing it or if he was getting hit and had to get some HP deducted.

So now I’ve got a world and an enemy.  I was even able to install some goomba AI into the enemy so they’ll just walk forever until they hit something or fall.  Easy enough stuff, but a good stepping stone onto bigger and better things.

The first step in my game is done.  I’ve got an engine.  Time to start putting it through it’s paces and get rocking.

Posted in: Otis, programming