Applying Definitions to CartograTour

  I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eighth episode on apply the definition of the genre I want CartograTour to be in to the game itself:

Welcome back to another Adventure Mechanics Side Quest.  It's me, Chandler.  If you were looking for one of the mainline episodes, don't worry, we're still doing them.  We just ran into scheduling issues and had to push the episode for July.  We'll be continuing on as normal next month.  Consider this a side quest extravaganza.  Last side quest, I ran through what genre I want CartograTour to fit into and how I, personally, define that genre.  For those who don't remember, I want my game to be a casual life sim.  I defined a casual game as a game that is easy to pick up, put down, with limited complexity and a less urgent gameplay loop.  That's quite a mouthful for my definition, but I wanted to define it as precisely as possible.  As for a life sim, I defined it as a game that simulates someone's life, or portion of their life coupled with a social aspect.  Keep in mind, I define a life sim as a casual game as well.  I can imagine that there are some life sims that aren't casual games, but I struggle to think of a specific example.  If you can think of one, leave a comment.  I would be interested in seeing a game that does that.

As for applying my definition of a casual game, let's apply it to CartograTour.  Is my current build easy to pick up?  It doesn't have a tutorial right now, nor does it have any cheat sheet for controls in-game, so that's likely not true.  I'll have to add a controls menu under options at the very minimum to even start to say yes to that question.  I'm not going to start in on the tutorial until I get all of the mechanics into the game.  This may be a mistake, but conventional wisdom for game design says that the first parts of the game should be done last, as the team is most familiar with the mechanics and will be (ideally) putting their most polished work into it.  That being said, there does need to be something to on-board the player into the game, and right now I'm doing none of that.

For the second part of that phrase, is my game easy to put down?  With the implementation of saving and loading, the player can certainly leave the game and come back at any time.  It may be too easy to do, at least looking at other casual life sims out there right now.  As it stands right now, though, I'm happy to let the player cheese the saving/loading to find their way back to the home tile.  At least I have that portion handled.  The player will be able to put the game down at any point and not feel like they need to complete something or make it to a certain point before quitting.  I don't know about you, but I appreciate that sort of laid back attitude in my games.  Well, at least the casual ones.

So, what about the limited scope?  Am I living up to that in CartograTour?  Currently, yes.  All of the game focuses on filling out the map and using that information in some way.  As I look at my game design document, however, I do see some things that aren't necessarily in service to that.  Is allowing the player to place and customize a house in service to that?  Not really.  Is creating a social network while building the town relavent to cartography?  Again, that's not, strictly speaking, relavent to the core gameplay loop.  That being said, I think those types of features will make the game more interesting and will keep the player more engaged with the game longer.  That may be worthwhile to deviate from strictly adhering to a limited scope to include.  More importantly, they are potentially the cornerstone of why I want to call it a life sim.  I'll get into that a bit later, though.

First, I should finish off my definition of a life sim.  In CartograTour, the player can spend as much time as they need exploring and planting flags to create their map.  The player doesn't even to ever engage with the quest board in the current iteration of the game.  That sounds like a really non-urgent game to me.  I don't ever plan to add any survival mechanics to the game, so this shouldn't change too much as I flesh out the day-night cycle.  The only thing that may change is that I plan to hook up the time expiration mechanic to the quest board.  That may push the player to complete the quests faster.  It may end up making players feel rushed to complete the quests before they really feel ready.  I won't know that for certain until I implement it and get some solid feedback, though.  And if it doesn't feel right, I can always pull it out.

The other part of my definition of CartograTour's genre was the social sim, so I guess I should talk about that now.  In terms of simulating the life of a frontier cartographer, putting together a map for others to use definitely feels right in the current build.  To further drive that feeling home, I need to implement more interesting things to put into the world, such as rivers and other natural barriers, animals and other hazards and whatnot.  For the astute players, these features are already stubbed out in the last release, but it's exactly that, a stub.  If this game is going to be much more than what I already have, I'll have to implement these.  I do want the player to also feel like they are on the frontier, so I plan on putting in a basic building that they customize with things that they find in the world or get as rewards for quests.

On that note, I plan on taking the quest board out and force the player to interact with non-player characters (NPCs) to get the quests instead.  That wil require a rework to the current system, but I think it will be worth it.  I want the player to get familiar with the NPCs and (hopefully) build a bond with them.  I am currently working on the first iteration of them, and, to be honest, they feel like I'm just talking to a quest board.  That's because they are little more than the quest board, but I'm working on getting them to be feel a bit better.  Hopefully by the time the next release comes out, there will be at least one NPC to interact with that doesn't feel like little more than the quest board.  I suppose that depends on how much I get done, though,

Now that I've applied the genre definition to CartograTour, I should talk about what I have been doing to it over the last couple of weeks.  I made a foolish mistake of perusing other developers' tutorials out of boredom shortly after the last release and one of them pointed to a lot better way of laying out the game, also known as the architecture of the game.  So, instead of implementing more features into the game, I spent the last two weeks on a complete rework of what I had already implemented.  It was soul crushing to do so, but I know that the new way everything is laid out will make it easier in the future to add features.  At least that's what I keep telling myself to justify spending two weeks on converting everything over.  We'll see how fast I can add features now.  If I'm wrong, at least I learned a lot from it.

Anyhoo, that's all that I have for this side quest.  Next side quest, I'm going to be talking about the importance of the tutorial.  As always, if you have any questions, comments or musings that you think I'd find interesting or funny, reach out to me on Twitter as @jcsirron.  This has been the Adventure Mechanics side quest and I'm Chandler.  I'll talk to you next time!

On Random versus Luck

As I hosted the Game Developers Forum at the TinkerMill last week, we began discussing the concept of luck.  It started with a video by PBS on the topic.  In it, the host Jamin Warren equated luck and player skill in the game Dark Souls.  I initially found this to be rather incompatible when it comes to player interaction; After all, when I'm rocking a game and showing it how I've mastered the mechanics it laid before me, I don't really consider that to be luck. From a developer perspective, Jamin argued that the skill of the player could be considered a form of luck.  One player can struggle with one section while another will simply breeze through it.  I'm not entirely convinced of this argument, however.

First I must try to tease out the difference between random and luck.  I don't feel that these two concepts are interchangeable.  When someone is "lucky," they are assigning either goodness or badness to what just happened. A gambler will say, "It was a lucky streak," when they win several rounds on the roulette table, despite it being an almost completely random game.  Where the ball lands on the wheel is almost completely beyond the control of the player; It is no more likely to land on one number over another (wheel rigging notwithstanding), yet the player will assign a quality to it.  "It was a hot streak," "I had a bad run," or "It was a lucky drop," are all things you could commonly hear around a roulette table.  In this context, luck is an emotional quality the gambler assigns to the random outcome, not the random outcome itself.  I feel that this nuance was somewhat lost in the PBS presentation.

With that framework in mind,  I want to re-examine the assertion that Jamin Warren postulates; That a player's skill can be considered luck in the mind of the designer.  If we agree to this viewpoint, "lucky" streaks that the player has are nothing more than anomalies when compared to the aggregate of player performance.  This doesn't really seem like an emotional response, especially with game design in mind.  These streaks are more likely the players that have mastered the game, rather than the ones that merely gotten a good run. Although interesting, this should not have an emotional component conflating the outliers.

Another view of the player skill he mentions is "luck execution."  This is the idea that no matter how good a player is, they will fail a certain amount of the time.  The reasoning he states for this is the "human factor," or the fact that we, as human beings, are not perfect.  No matter how well we know a game, we will have a lapse of judgement or something that prevents a perfect game.  Although interesting, I'm not sure that this is quite the same as luck.  This lack of a perfect game is what makes pursuits of high scores and speed runs worthwhile.  It's not exactly luck that gets the high score in games like Mario, where any given board is not likely to have a random element.  Rather, it's the focus of the player and the mastery they have over the mechanics.  A lapse in mastery is not necessarily the end for a great run.  This, too, runs into the outliers, where perfection is the goal, unlike the bulk of the player-base.

Although Game/Show has a good description of luck in games, it plays a little too fast and loose with terms to be a great resource on the topic for my tastes.  I understand the ideas this particular episode was trying to convey, but I think it misses by a bit when it tries to equate luck, random, and player mastery into one blanket term.

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!

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

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 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