Metris, Tetris and mutating known formulas

After sitting and waiting for the memories of the last Ludum Dare to fade a bit, especially the emotions, it's time to sit down and do some good, old-fashioned analysis on our game, Metris.  Metris is a mutation variant of Tetris, the classic block game.  Instead of the known formula of rotating shapes, we used morphing in place of it.  That was the core of our idea: morph the shapes in Tetris and use someone's existing codebase to kick off the jam a little faster than the last iterations.

We started the evening by brainstorming ideas until the two teams were decided: Our game, with two people working on it in Python, and the gobs of people working on the other game in Unity. It seems like my preferred language, Python, turns off quite a few developers.  Those not scared off by Python were not too enthusiastic about working on a Tetris clone.  Oh well, the game they came up with was good as well.

Once we had our game concept in mind, we found a code base to work from and started working on it.  At first, it seemed like the code we were using was good, but after a while, I found myself working on handling the edge cases that the original developer never bothered to handle.  I spent the entire first evening and most of the morning working on getting the edge cases under control.  Although it was a good lesson, I would have much rather have just spent some more time looking at code bases and not have dealt with the headache in the first place.  Lesson learned, I suppose.

I started feeling rather weathered as we entered the second evening.  Apparently I didn't avoid the cold that my significant other had brought home from work.  Despite that, I was still able to handle the rest of the edge cases in the code and get the game to run the way we wanted it to run.  I retired from working on the game early that night, knowing full well that the next day would be a mad rush yet again to get the game finished and polished.

We started doing the polishing phase once we started working on the final day of the jam.  We created a win condition, set up several levels for the game, and even got some music in as well!  Funnily enough, we started the day assuming that we would not be able to get music in for the game.  There just wasn't enough time to get both the polish in, along with working on the music.  In the final hours, Josh came in and wanted to do some audio for one of the groups.  Fortunately for us, the other group, which had seemingly absorbed any walk-ins, was at capacity when it came to audio people.  We sat him down for a quick playtest and some vague desires on what the game should sound like and we let him loose.  A mere hour later, he had music done and in the game for us.  Sweet!

Ok, now time for good, the bad and the ugly!

The Good:

• I got practice on working with a poorly documented, buggy code base other than my own.
• Metris has music!
• We got time to spend on polishing the game more than a few hours.  Consequently, the game was much more complete and looked better than the playable demo we had at the beginning.

The Bad:

• Not a lot of people joined us for creating this game.  This was not ideal, since there were over a dozen people working on the other one.  I think Unity has saturated the game development community.
• Getting sick.  Not much else to say about that.  Colds suck.

The Ugly:

•  My artwork.  Seriously, who let me do the artwork?  Oh, riiight.....

Ok, that's all for this segment.  At some point in the near future, I'll be taking a more formal look at the numbers and what the community had to say about the game.

Analyzing my first few attempts at Ludum Dare game challenges (Part One)

I have been looking back at my previous entries into the Ludum Dare lately.  It feels like every time I work on one of these games, I come away feeling great about it.  I rarely look at them a second time, however.  As I have some downtime before the next Ludum Dare, now would be as good a time as any to compare my post-mortems to what the ratings actually said of them.

First up, we have my first ever entry, Lobo.

This being my first ever game created with a team, I felt very good about the outcome.  The strongest portion of our game happened to be the audio.  We found the audio online, using free music (as in the music that can be used for general non-commercial use) and used a few sound clips we made.  I feel that made audio point somewhat of a caveat, since we didn't create all of the assets.  The lowest score we got was in fun.  As the game only had walking brains and no win condition, I'd say that this was a fair critique to have. There wasn't much in terms of gameplay here.  The graphics were a second strong point we had.  I'll do a full post-mortem on this game later.  Onto the next one, The Orion Trial!

Not to be confused with Schell Games The Orion Trail, our Orion Trial ended up being a standout game in terms of rankings, despite having no audio.  We ended up ranking in the top twenty for humor by filling the game with humorous sci-fi references.  It ended up being just a game of random number generation, but no one seemed to care about that weakness, at least judging by the fun rating and the comments.  The weakest portion of the game was the innovation, since it was a clone of the meta-game in Oregon Trail. I personally spent way too much time working on a parallax field, which I felt added polish to the game, but didn't help the fun factor of the game.  I know that I didn't really care about the looks of the original Oregon Trail.  The main part of the game that I liked was the mini-games: Packing up as many bullets, ignoring almost all other supplies, for the hunting mini-game was what I did as a child.  Having no mini-games in the Orion Trial made me feel like the game was somewhat unfinished.  One commenter left one hilarious post, however:

 fisholith says ...
"Cool concept, I love the encounters. :)
On one mission I recruited no fewer than 4 LRRRs. They all died.
On my next mission, my ship had been built on top of an ancient space burial ground. One which also seemed to travel with the ship, because wow, was that ship ever haunted. Actually ... now that I think of it ... there were more ghosts on that ship then crew. Oh my various space gods! *WE* WERE THE GHOSTS!

But also we died later."

Loot Runners was a seeming back-slide in terms of finding that magical mix of game.  I only worked with one other person on this game, but I still am only somewhat happy with the results.  This was our first attempt to create a game involving multiplayer.  The comments on this game were appropriately critical of the execution.  There was not much in terms of gameplay, nor was there much in terms of eye-candy.  What seemed to frustrate the players the most was the lack of feedback.  I think this could have been solved if the player image shook or the monster shook when they attacked you.  What we did do right was sticking on point with the theme.  The entire game was on a single screen.  One bright spot in the game was using a giant killer rabbit for an enemy.  Once again, it was not an especially innovative game.  As a first stab at a local multiplayer game, however, I am pleased with the results.

I will continue the analysis and data visualization of the next three games in the next post.

Space Mashers, or time to polish. WHAT IS THAT?

     Last weekend, I participated in the latest Ludum Dare along with about half a dozen other people at the TinkerMill.  For the theme reveal event, we had about a dozen people help brainstorm and flesh out mechanics for various ideas we came up with. It was an extremely productive session, with at least fifty ideas being thrown about.  After about an hour or so of discussion, we broke out into two groups, one working on what would become Space Mashers (the one I worked on) and one that would become Attack of the Vikings, made by my friend Terry and his family.

The participants watching the keynote

      Once we broke into groups, I actually got a (very) rough draft of the game up and running.  I was amazed that I was able to get into playtesting after the very first few hours.  In all of my times doing Ludum Dares, I have never been able to get playtesting in so early.  I was very happy with that development.  I left the first night very happy with what had developed. I fell into bed feverishly dreaming of what the game would become.

A quick note in front of a white board full of ideas

     The next day, I was able to get the vast majority of the gaming mechanics finished, along with most of the game modes. Brian hammered away on the final (and most creative) game mode, where the player uses a quite alien way to get a turret to move around the screen and shoot pursuing ships.  Adam was able to get a bunch of artwork done and we started integrating the disparate pieces together to make a whole game.  As night two came to a close, I once again left feeling quite happy to have finished the core of the game.

      At the beginning of day two, we continued on making artwork and got to polish up a bunch of little details.  I went wild with the parallax field I made for another game (thanks, Orion Trial!).  We had a few people that weren't involved in development do some playtesting and we got some valuable feedback from them.  After adjusting the difficulty, we went to the final frontier: Sound.  Although it was getting close to the deadline, I decided that adding sound would make it much more immersive, so I pushed to get some in before we had to get it into a package to submit.

     Ok, enough of the blow by blow, let's get down to the good the bad and the ugly!

The Good:

• Polish!  I never thought I'd be able to polish within the 48 hour time frame.  It made a huge difference.
• Playtesting.  I hear this often, but this has been one of the few times that I was able to sit back and playtest the game and somewhat balance it before submitting it.
• Audio.  Getting it into the game was a last second thing, but it added a bunch to the game.

The Bad:

• Audio.  It makes it into this category too, since we didn't have time to match it up to the timing that we needed and it shows, especially when the ship is exploding.
• Losing Work Space.  This one didn't really effect our group, but the other group we collaborated with had to migrate in the middle of the jam, making it much harder on them.
• No internet access.  At the beginning of day one, we had a router issue at the TinkerMill and we lost internet access for a vast majority of the group.  I never thought that I would have a problem working without internet access, but I quickly realized that I need to have more intimate familiarity with the libraries I'm using.  Lesson learned.

The Ugly:

• Artwork.  It's not fair to put this all on Adam, since he had little experience with artwork, but the project dictated that we needed to dedicate one person to the artwork and I had already started coding for the game instead of making artwork and letting Adam and Brian tackle the code.
• Management.  This ties to the artwork point, but I should have played to everyone's strengths instead of just diving into one portion that I was most comfortable with.  Although I'm more comfortable with code over art, Adam's talents were misused this jam. I should have recognized that early on and reassigned him.  It would have been a totally different game, but that is not a bad thing.

Overall Verdict:
     I was extremely pleased with how Space Mashers turned out, even with my missteps and obliviousness.  If you haven't tried it yet, you can find it here.  Tell me what you think of it in the comments!

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.

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!