Showing posts with label group project. Show all posts
Showing posts with label group project. Show all posts

Wednesday, June 22, 2016

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, MetrisMetris 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.

Sunday, February 7, 2016

Analyzing my Ludum Dare games (Part Two)

Continued from part one:

Up next on my list of Ludum Dare games is Break a Leg.  For this game, we started working on the project by creating the game with two sets of cards.  I thought it was great:  So much so that I am actually working on making it a full-fledged game right now.  But what did everyone else think of the game?  Well, the instructions didn't really help.  Most of the comments were focused on confusion.  Most commenters didn't know what to do and were confused by all of the sandbags dropping seemingly at random (they were dropped by the other actors).  In terms of artwork, the commenters stated that they liked the style, but the UI was less than obvious, especially with the sandbags up at the top of the screen.  It seems like the UI could have been worked out be be more intuitive, like re-sizing the forward sandbag and moving them towards the center of the button where they would land.  Or perhaps having a switch button to change the movement to dropping and vice-versa.  At least voters found Break a Leg to be more innovative and followed the theme well.  For a more in-depth post-mortem of the game, look at my previous post here.
Royal Flesh was a return to audio for me.  In this game, we were able to tag-team the code, which gave me time to work on both putting in some audio and get some artwork in as well.  Most of the comments center around the first build working, so only limited analysis can be gleaned from the rest of the commenters.  What little they said was mostly praise for the game's simplicity.  The ratings for the game show that innovation and theme are becoming fast strengths of the team.  I don't really have much more that I can glean from this, but I did do a longer post-mortem here.
With this last Ludum Dare, I had way too much fun creating Space Mashers.  I felt like I was on point in terms of coding, but I didn't really manage the team too well this time (analyzed here).  Comments centered on praise and a lack of affirmative feedback when the correct buttons are pressed.  I suppose we could have added more effects and background music, but I was just happy getting any sound working in this game.  I have not exactly found out how audio works in pygame, so any sounds were a strict bonus.  It sounds like my UI work left something to be desired and I need to add polish to indicate when the player does something right.  Innovation and theming were on point with this game, however.

That's all of the scoring that I have gotten for Ludum Dare games, but it's certainly not all of my games I've created.  You can see all of the games I've created, including the mini-dare games here and here.  If you have any comments on any of the games, let me know here or on Twitter!

Thursday, February 4, 2016

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.

Sunday, January 3, 2016

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!