Royal Flesh Post Mortem

Well, another Ludum Dare down, and another game out.  It's been a week since we finished and published what I thought was a functioning game.  Before we delve into what went right, wrong and ugly, though, take a few minutes to try it out here.  I'll wait.  Tried it?  Good!  Leave a comment about it and I'll be sure to read it.

Now time to do the post-mortem!

This game went surprisingly smoothly, save for a few particularly bone-headed moments and a LOT of frustration getting cxfreeze to work properly (seriously, how can you forget to include something that is IN the include call?)  We started out with a long idea session that seemed to center around an idea called "Grammar Nazi."  Thankfully, that idea didn't hold enough interest to develop and we settled on the trope of abducting royalty as a dragon.  I even got ambitious and got the framework for the game ready the first evening.  I went home to bed happy, thinking that I had gotten so much done already.

The next day I got into a HUGE memory leak due to my framework not properly closing out when switching between screens.  I spent an hour working on getting that migrated over to objects instead and then implemented the item system.  At this point, we had an artist that we were supposed to be sharing with another group (thanks again, Tamara!) and things felt good.  We even had a few teenagers helping out with the audio portions.  I brought in my home-made sword and so did Brian, so we had props for making convincing sound effects for the game as well.  As the day dragged on into the evening, things started going sideways.

Our awesome artist couldn't work with us anymore, since she had prior plans.  That left us with about 3/4 of the assets we needed and no one to do the rest.  I was looking at doing artwork for some time, so I stepped up and started jamming on the art, leaving the code work to Brian.  The guys working on audio were not really into it and started messing around with two shiny swords outside.  They claimed they were making sound assets, and they did, but their methodology could have used some... work. After about an hour (maybe more, maybe less. I was lost in artwork), they came back in with dinged swords, cracked chain maille and apologies.  Apparently, they used the equipment improperly and caused quite a bit of damage.  I was so engrossed in the artwork, I forgot the first rule of teenagers: Never give them dangerous things without supervision.  I went home that night with a rather sour taste in my mouth.

The next morning, I got in and attempted to start working on art again.  I was immediately foiled by a broken tablet pen.  Just as I was getting comfortable with it, too.  I had to go grab a mouse to work with and got back to art.  Thankfully, the rest of the development process went smoothly.

When we went to package the game up, we had troubles with it packing up nicely for mac.  We spent an hour working on it, but to no avail.  I was getting tired, so I packaged up a Windows build, tested it and went to bed.  Apparently I should have tested it on another computer without python installed, since I looked at the progress of voting and found a long list of "Broken game!" comments on the site. I just figured out that cx_freeze was not including pygame._view in the build, rendering it useless.  D'oh!  At least now the game is playable.

Ok, time for the Good, the Bad, the Ugly:

The Good

• We released a game!
• I got to do some artwork
• Scope Creep wasn't really an issue
• Execution was very close to the original Idea

The Bad

• Artist had to duck out
• Bad build on layman PCs
• Broken equipment (tablet pen, swords)
• Animation had to get cut back for the Nobility

The Ugly

•  Broken chain maille
• A week's worth of "Broken Game!" comments on the Ludum Dare website

Failure.... Yet again.

Well, Game Boy Jam didn't go well for me. Real life got in the way.  Again.  I sat down throughout the week to jam, but either my motivation vanished, I got stuck and lost steam on the project or friends and family needed my attention.  It is endlessly frustrating to have to write this post about bowing out of the jam.

I started the jam with an idea of a princess, one who tired of waiting for her prince.  Over the first few hours, I imagined that it would be a stealth based game, where you, the princess, are helpless to stop the invasion of your castle.  Your only hope is to escape the pillaging and survive.  I quickly realized that this was going to be difficult to implement this initial idea.  I spent a few hours getting a semblance of a game running, but I had to shelve it until another day, or so I thought.

The next day, I was able to sit down and work on the artwork of the game, but I was frustrated by my incredibly rusty art skillset.  I have been working with artists on every jam since I started doing them two years.  During that time, I have not drawn anything more than a doodle, let alone flesh out an entire cast of characters (I was going to implement five of them). I fell back on my schooling and started doing warm-ups.  They went well, but they didn't exactly help me get a whole character committed to a sprite sheet. After pounding my head on my tablet for a couple of hours, I called it a night and went to bed.

With the beginning of the week came work and all of the distractions that entails.  I was able to get a few hours of work down on the artwork, but I fell into the rusty knives of dulled skills again.  The rest of the work week was too busy for me to sneak some time in for the jam.  Needless to say, I was looking forward to the weekend, where I could jam without the messy distractions of working and preparing for school.

As the weekend began Friday, I had two ultimately fatal complications pop up.  The first was a previous commitment of working on my girlfriend's family farm Saturday.  I was only expecting a half-day of work, since it sounded like we'd only be doing a few things.  I was wrong. Very wrong.  I barely had time to snag a shower before having to go to the weekly Game Developers Forum.  I didn't get time to work on the jam that day.

The second complication was having an old friend surprising me with a visit.  I mentioned that I was jamming at the time and he seemed willing enough to help.  As I sat down to work Sunday morning, though, he fired up his latest gaming obsession: Rocket League.  I only got about a half hour of work done before finally succumbing to the allure of gaming.  It ended up nuking the whole day.  Not that I regret anything.  I got to see an old friend and see a new game that I had only heard of before.

Ok, enough of the blow-by-blow account, let's do the Good, the Bad, and the Ugly of this post-mortem.

The Good

• I got to verify my latest additions to my code-base
• I implemented a better chase algorithm for future use.

The Bad

• Previous commitments killed any hopes of getting a game done.
• I surrounded myself with those who impeded my progress.

The Ugly

•  A half-baked, only partially completed game.

Although I got practice like I wanted this jam, I would have been much better off cloistering myself for a shorter amount of time and getting more done.  Life had a way of screwing over my intentions of joining this Game Boy Jam #4.  Lesson learned.

Chomping at the Bit

So, I've gotten the game jam fever and couldn't wait until the next Ludum Dare.  I know; the next Dare is only two weeks away.  The thing is, though, that I've been really inspired by some of the theme ideas.  That's not to say that there are bad ideas, there are a ton of them.  The gems that I do find going through the slaughter are worth the sifting, though. I have a horrible bias towards themes that can lend themselves to either fantasy or sci-fi wrappers. As I worked my way through the slaughter, I thought to myself, "man! I really want to start jamming on a game!"  And that's how I ended up starting the GBJAM.

The Game Boy Jam is an interesting one.  Instead of the focus of updates being on the website itself, it instead leverages Twitter for the vast majority of it's updates.  I'm not quite sure that I'm a fan of this, since that means yet another social media platform is scraping my information.  I don't know how, but Twitter scraped my G-Mail for people to follow.  Grrr.  That's a rant for another day, however.  I'm here to talk about the jam, not the social media aspect.

From what I can tell, the jam isn't as popular as the Ludum Dare (duh!). I do see a lot more cross pollination, though.  A few users have been religious about updating and now I've seen several different versions of what a 3D game would look like using a Game Boy screen. Weird.

Another departure from the norm is the time allotted.  Ten days.  Yeah, that's right, ten days.  Wow, that's a lot of time.  It almost hits the point where I'm able to put off stuff until the last day.  Not that I would do that (sarcasm).  This is a departure, since the jam now starts to bridge the divide between a quick burst and a slow burn.  I'm not sure that it's good for me, personally, but I am giving it the good old college try.  We will see how it turns out.

The last part of this puzzle is my team: Me.  Yep, that's it.  It's just me this time around.  I've had a blast working with others every game jam, but I feel like I need to be able to jam alone.  So, that's exactly what I'm going to do this time around.  And yes, I don't have much to show for it except these puddles chasing a red one around.

Now if I can get used to the whole Twitter feed for updates....

- Chandler

Ludum Dare 32 Post-Mortem

In preparation of another Ludum Dare, I am reposting my post-mortem from the last Ludum Dare.  To those who are joining for the jam or compo, good luck!

--------------------------------------------------------------------------------

Well, It's been a week since we submitted our game, Break A Leg, and it's given us time to think about what we have done.  It was a blast to make and I personally am proud of what we had made.  That being said, I feel like a proper post-mortem is in order.  Let's do this!


The Good:
Playtest the game mechanics the first night.  Most of the Ludum Dares I get lost in the details of making the game that I don't stop to think of whether my game will actually be *fun* or not.  So, playtesting the game mechanics night one made me much more confident about the direction of the game.
I had backup for programming! This one was personally huge for me, since it gave me more time to think about the structure of the code and, consequently, make better code.  A larger group also let us have some backup on each area of work.  The extra help on art and code made a much better project.
The Bad:
Time.  I know this is a common item on the bad list, but having some extra time would have been immense. Everyone had work on Monday, so the last day of the jam really wasn't an option.  We worked as late as possible and got a lot done in the final few hours, but we didn't have time to get the audio that we recorded into the game.
Split work areas.  Since we had a larger group than expected join us at the TinkerMill, we had to move into the main area for the Dare.  We had the people doing art and sound working in one area and the programming group working in another.  That led to a few issues with user interfaces and misunderstandings about what the vision of the game would be.  Although we mitigated confusion by planning thoroughly the first night, some details fell through the cracks.
The Ugly:
Having to move into the central area.  The main area was quite a bit louder than the conference room we were initially going to use, so it affected how focused we were on the game.  It wasn't a huge deal, it just made it take longer to get done.
Not participating in the warmup weekend.  I was a bit rusty on the coding side, so it took me longer to get moving on the code than it should have been.
Next Time:
Reserve the classroom.  I think that this would solve the split work area issues, along with the noisier work area.  This is easy enough to solve, though.
Practice!  Working on games is not a short term endeavor, so not practicing the art really takes it's toll between the Dares.
As always, it was a blast to make this game and we look forward to jamming again next time.

Practice, practice, practice

Game development is like any other art form; without practice, the capability to create withers.  I really need to take this to heart. For all of my game design challenges, I have been the quintessential code monkey: The person lost in the code, yelling at the artwork to stop walking away (damn you coconuts!) while the rest of group works on the other portions of the game, such as artwork, sound and music.  These are what the player will see and hear the most, not necessarily the code that makes it fun to play.  That's why I have been working on art.

The migrating coconut game a.k.a Feeling Lucky (find it here)

For the past two weeks, I have been practicing with my new drawing tablet.  Drawing on the computer is not *quite* the same as doing it on the tablet.  It has been a while since I've taken up the pencil for art (at least a year, from what I remember), but working on the tablet takes a little bit away from the drawing experience, even for someone with rusty skills.  The first thing I had to work through was the disconnect between the pen and the image.  In analog world, the pencil is friend, a close, immediate feedback.  I can feel the pencil move, watch the line form as I draw it.

When I work on my tablet, however, there's a slight delay.  The pencil is no longer directly attached to the lines.  The delay and the detachment from the pen makes me yearn for the pencil again.  The yearning dies down after a warmup, though.  Giving up the tactile nature of drawing is a small price to pay for instant digital work.  I'm not sure that the tradeoff is always worth it, but for making digital artwork, using a tablet is a huge improvement over the mouse, especially for those who were trained to work in physical mediums first.


- Chandler

The Perfectionism Paradox

This past couple of weeks, I have been playing my way through some of my old favorite PC games.  I have been playing the original Thief and my personal favorite turn based strategy, Alpha Centauri. Once I got past my (very thick) nostalgia glasses, I found a few things that irked me.

Thief is a game loosely focused on stealth, but in reality, it's a game about messing with guards in a variety of ways.  What I immediately noticed when I started playing this game was the wonky control scheme. For some reason, there are four different speeds in which to move forward.  There are the standard run and walk, along with a slow modifier for each one.  This may sound like a good idea for a sneaker at first, since you may want to sneak run past a guard as you are being chased by another, but in practice, you will accidentally press a movement key when trying to look around a corner.  This makes any hope of getting into a smooth control groove aggravating.  It was a great reminder that using industry standard control schemes tend to make for a more enjoyable experience.

The other game I've been playing a lot of is Alpha Centauri.  Man, I love this game!  It is a turn based strategy game in the same vein as the Civilization series.  I should say it's in the series, since it has Sid Meier's name on the box, but I feel that the sci-fi theme in the game changes the flavor of the Civilization formula enough to make it unique.  Either that, or I love sci-fi and get bored with running a normal society too easily.  It's music fits the action onscreen very well.  It seems to come into my consciousness just enough to remind me that I'm commanding a sect of humanity to survive.  Commanding humanity beyond the stars is a great way to forget all of the petty issues I run into on an average day.

Having just gushed about Alpha Centauri, there is something that I've found that really started to bother me.  I play it like it's a SimCity game. It is something that I noticed as I played up until the conflict period of the game, where you fight, negotiate or contain your opponents, and stopped playing after a few turns into it.  Once this conflict stage began, I found myself either bored by the fighting or yearning for a somewhat... more engaging experience.  That's not to say that the conflict stage in Alpha Centauri is boring, I just found myself not playing a single game to completion once I developed all I could at my main landing site.  My soldiers seemed to me to be nothing more than tools, lacking any sense of personality or anything else to get attached to losing them en masse to take a single colony.  Consequently, I would end up massing up a massive army only to feel apathy when I lose them in a series of battles with my opponent.  I tire of the build, move and attack phases of the game, which is what the mid to late portion of this game center around.  Watching the same fighting over and over again with no input on who wins the engagements becomes tedious, killing any desire to finish the game.

What could I do to make the fighting more engaging?  I have been dwelling on this since I noticed that once the fighting starts, I stop playing.  One method is to make the combat more exciting, with units crouching and shooting, turning and firing, covering when artillery strikes.  That would make the units look like they are doing more, possibly engaging the eyes while the fight takes it's course.  Another method I considered was to implement a Final Fantasy Tactics type of combat.  When you engage another unit, you are given the option of joining the combat as a leader and directly engage the enemy on the field.  This would make an already long game even longer, however.

Looking at these old games has given me time to consider the strengths and weaknesses of their designs.  Even with the minor gripes on each game, I recommend giving each a play.  Cheers!


-Chandler

The Motivation Problem

Motivation.  Man, is this an issue!

I have done a few game jams and have only once been thoroughly uninspired by the theme. Even then, I haven't had an issue working my way through the initial, "What AM I making?" most (longer) projects I've worked on are plagued with.  It's not that I'm uninspired by the project (well, mostly, anyway), it's more of the long burn the long project presents me versus the, "Gotta go, gotta go, GOTTA GO!" mentality that pushes me through a short, succinct project that I embark on in any game jam.  Why would doing a game jam seem relatively easy compared to a solo project, where I have as much time as I need?  I have had to think about this exact problem as I work on my latest project and I think I have come up with a few reasons.

3. The rush.

I'm not sure what it is about doing a jam, but I always get a rush when I'm in them.  It's like a gaming Mardi Gras filled with fellow masochists. We're all in a fellowship of suffering for our favorite pastime, designing games.  There's some comfort knowing that I'm not the only one who is doing it, all competing for attention and glory.  That's a huge rush.

2. Long burn versus short burst. 

A solo project long-term is not the same thing as a quick weekend of design.  Sure, you can continue to develop the game you come up with in the jam, but at the end of the day, you're still facing the prospect of a long, sometimes soul-crushing, development time. A jam is nice because it has a clear, short time frame in which to work. Polishing any game takes a looong time. And from my experience, once you have that proof of concept from the jam, guess what most of it ends up being?  That's right, the polish.  I haven't quite mastered the polishing stage, since all of my games have come from quick burst of inspiration.  Once the inspiration expired, I moved onto another project that caught my fancy. The long burn of the polishing stage is the next stage I need to master.

1. It's a solo project.

I really want to discount this as my number one reason, but I must come to terms about my own behavior.  I suck working alone.  Sure, I can work my day job a whole day alone, with me being the only one in the office that day, but I feel as those days fall into the short burst category.  When it comes to the long burn type projects, having someone there to bounce ideas off of or prod me into doing that part I don't care for really helps me advance.  Not having someone relying on my work to get something done makes me want to put that project on the "I'll do it at some point" list.  This destroys most immediate motivation I have.  Honestly, I'm not sure how to remedy this.


Thank you for reading this rant!

Adventures in Quad-Trees!

This past week I have been looking into implementing a quad-tree data structure in my game engine.  Although the amount of stuff on-screen in most of my games may not really benefit from it yet, I figured now would be the time to implement it before I face massive slowdown from too much shiny (á la fancy particle effects that bounce off of players, walls, etc.).

For those who are in the dark about what a quad-tree is, it's a specific data structure that can significantly streamline collision detection.  The basic concept is that the screen is split into zones as the number of objects on-screen increases. Once the number of objects on-screen reaches a threshold, the quad-tree splits the screen into exactly four quadrants.  Each quadrant can only contain so many collidable objects. If there are too many objects in any one of these quadrants, that quadrant can then be split into four more quadrants and so on, until each portion of the quad-tree is either at or below capacity.  Once you have the objects placed in different quad-trees, you can then check collision between only those inside the specific quad-tree rectangle and not check against one across the screen.  This can potentially save significantly on collision checks

Now, I know I asked myself, "Why would I want to do this?  Isn't it cheaper to just do collision tests on all of these objects at once?"  After all, all of my games up until this point have had only a handful of objects on the screen at once, and only a few objects cared if they collided with anything.  The first game I made, Log Jam! only cared if the player collided with any log, not if any logs collided with each other.  This led to some really weird problems, where the logs would "ride over" each other.  Although this was purely an aesthetic issue, it has always kind of bothered me.  Implementing collision logic between the logs would add variety in movement to each one, and make the game more dynamic overall at the cost of a LOT more collision checks.  This is where I could have implemented a quad-tree system to minimize the number of checks I would have to do.

An example of a collision issue in Log Jam!

Another example of wonky overlap with the logs

Working with Log Jam! as an example, let's go through the number of checks that we would need to do if we are later into the game, where there are a bunch of logs on-screen at once, such as in this screenshot:

A late game screenshot of Log Jam!

 In this shot, there are ten collidable logs on the screen (the waves are just for polish and aren't affected by the logs).  In this example alone we have 10 log collision checks to do, coming out to 45 checks minimum to make each time through the game loop.  If I was sloppy in coding (as I sometimes am), the number of checks would be closer to 90, assuming that I forgot to cull redundant checks.  Keep in mind that each check is a simple rectangle collision check, relying only on the bounding box of the log.  Even in this example, that is a lot of checks!  Let's break this into a more manageable size:

The same screen broken into a quad-tree

Now in this example, our parent quad (the entire screen) only has two objects in it, the log straddling one and two and the player's raft. quad one has two objects in it, two has one, three has two and four has three.  Let's go through the math: the objects in the parent node have to check against all of the sub-nodes and each other, netting 17 checks. The logs have to be placed into one of the quads, netting in another 24 checks.  Once all of those are into quads we can check each: quad one has 1 check, quad two has no check, quad three has only 1 check and quad four has 3 checks.  This leads to a total of 46 checks.  Hmmm... Not much better, is it?

If we limit our checks of the parent node to only those sub-quads that the object hits we can cut the number of checks.  For example, the player's raft will only hit quads one and three, that check alone netting us 4. we then compare the raft against quads one and three, netting another 4 checks. Doing the same with the log, we net 7 checks, cutting our total collision checks to 15.  When we put this into the our previous calculations, we end up with 44.  Not great, but a modest improvement.  The more objects that appear on-screen, the better the results we will get.

In my example, the quad-tree algorithm adds a lot of overhead to collision checking, so in this case, it may worthwhile for Log Jam! If there was a lot of collision checking that I had to do, such as where I was dealing with something where the logs rotated and the collision checks weren't just dealing with rectangle checks, but whether a rotated object indeed hit another, the quad-tree would make more sense. Having it in the toolkit for speeding up the game loop doesn't hurt, however.

Well, that's my broad-stroke analysis of quad-trees.  I'm sure that I'm missing something in this, but I just wanted to write my way through the problem before diving deep into the code.  If you have any questions/feedback, leave a comment.  Thanks for reading!

- Chandler

Obligitory Hello World

Hello all,

I am Chandler Norris, an admittedly amateur game developer and this is my development blog.  I am currently working on a game prototype using Python/PyGame as my rudimentary framework.  I have made a few Ludum Dare games (found here) and countless prototypes scattered across countless hard drives.  I am also leader of a Game Developer's Forum at the TinkerMill, a hackerspace in Longmont, Colorado.  If it is not obvious at this point, I am definitely into making and playing games.

Now before you say anything, yes, I know that I'm not using the "optimal" language, such as Lua or C#, nor am I using more feature-complete tools, like Unity or Construct2. Why? The answer is simple: I like what I'm using right now.  That is not to say that I am against exploring those options further, it is just I have not found PyGame's limitations to really hinder my ability to make the games I want to make.  Once I find it to hold back the types of games I want to make, I will start exploring these other options.

Join me in this adventure of game design!


- Chandler