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!

What is a casual game?

 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 seventh episode on how I'm defining the genre that my game is going to be in:

 Welcome to the Adventure Mechanics Side Quest and today it's just me, Chandler. As I've gotten feedback from early playtesting, I found that I've kind of lost sight of my initial design. The initial design for CartograTour, what I'm renaming my prototype I was calling The Mapper, was for it to be a casual-style cartography game.  As I've developed it, however, it's become more reflected the type of games that I've been playing, i.e. games that tend to be played more in rounds rather than as a casual experience. That made me realize that I never really went through and defined what a casual game was for me. So for this sidequest I'm going to be diving in and trying to explore what, exactly is a casual game.

So, what is a casual game? The most common definition I could find was a game that was easy to pick up and easy to put down.  But what does that mean?  Are sports games a sub-genre of casual games?  Is a one on one fighting game?  By this vague definition, they very well might be.  That doesn't feel right, though.  A sports game is pick up and play with relatively short time commitments, but if it's American Football or Cricket, the player will need to have at least some basic understanding of the rules of the game, which adds a bit of a barrier.  A more complex game is a less approachable to new players and a casual game is supposed to be inviting.  In the same vein, fighting games seem to fall flat in terms of complexity.  Sure, just playing a casual round of Street Fighter may be quick to pick up, but the complexity of the meta-game can quickly turn off a filthy casual like myself.  The competitive skill ceiling also makes playing with your more talented buddies far less interesting.  A skilled player will stomp a new player way more often than that new player will be able to beat the skilled player.  That's not really approachable as a casual game to play.  I think that this limited definition of a casual game needs to be a little bit more fleshed out.

So, what do I think it means?  Well, a casual game still needs to be easy to pick up and put down.  But the controls also need to be intuitive, as well.  If we take those requirements and rework the definition to something that encompasses it all, we can get to this first part of the casual game definition:  A casual game is limited in scope and complexity.  That means that a casual game won't have an overwhelming number of mechanics and won't have too many controls.  Moreover, any controls that are in the game need to be as clear as possible, be it through instructions in the game or leveraging the player's intuitions.  Any unexplained instructions will need to be intentional choices, not something that was overlooked in development.

That's great and all, but that now begins to include games like Diablo.  Is Diablo a casual game, too?  Is the core gameplay loop in it of killing, looting and equipping lend itself to a casual game?  It doesn't really feel like it should.  There's an urgency and agressiveness in the gameplay that doesn't really lend itself to a more casual game.  So, to better define a casual game, I'll need to refine the definition again.  It needs to have less urgency than a game like Diablo.  So a calmer core gameplay loop is necessary.  Twitch reaction and  deep strategic thinking aren't really part of the core loop for most casual games.  That means a casual game need to have a calmer core gameplay loop.

That takes the definition for a casual game to be a game that's easy to pick up and put down with limited scope and complexity that has a calmer core gameplay loop.  Does that mean we have a good definition of the genre for CartograTour?  Well, not quite.  Casual games as defined will certainly include CartograTour, but it doesn't quite fully encompass the core of what CartograTour will actually be.  After all, Cards Against Humanity could be called a casual game.  What I envision CartograTour to be is something called a life sim.  A life sim is a sub-genre of casual games that focuses on some specific aspect of life that the player may or may not be familiar with.  If they're familiar with the core gameplay, we can leverage the player's experiences in real life to intuit what to do in our game.  That greatly eases bringing new players into the game when they can guess what to do.

Just having that one definition doesn't really encompass all of what makes a life sim game, though.  Could a puzzle game like Tetris a life sim?  It currently fits into our definition of a casual game, but it doesn't really feel like it should be included in our definition for a life sim.  Sure, you can play it alone and have a blast, but ideally, a life sim is something that's shared.  A high score just doesn't feel like it's enough to me.  So what if we add that a life sim has some sort of social aspect?  That would exclude straight puzzle games from the life sim genre.  But what does including a social aspect mean?  The obvious answer is that it has people playing the game together.  Two people playing something like Stardew Valley is obviously social.  But if the multiplayer update wasn't added to it, does Stardew Valley still count as a life sim?  I would argue yes.  That's because having a social aspect doesn't necessarily mean that there has to be multiple players in the same game world.  What about the interactions that the player has with NPCs?  Trading, completing orders and being able to romance them all are something that we expect to do with people in our daily lives.  That brings back the pre-multiplayer update of Stardew Valley back into a life sim.

Life sims will also need to have some sort of major goal.  Sandbox worlds where the player can make their own goals are great, but a life sim doesn't really need to be open like that at all.  Take Papers Please, as an example.  It's a life sim of a very limited aspect of a person's life; their job.  They don't have the freedom of doing whatever they want, they are living out the life of a border guard.  This is a more guided goal meant to evoke a specific feeling.  A goal that forces the player into the mental state of that specific border guard is acceptable.  Our definition of a life sim needs to include this.  A life sim ends up being defined as this:  A game that is simulating some portion of a person's life with a social aspect and either open or directed goals.

Whew!  That's a lot of defining!  But, now we have a definition for what, exactly, I want CartograTour to be.  It's going to be a casual life sim.  In the next side quest, I'll be going over what that means for the game and if I need to adjust anything already implemented or change what I'm working on putting in.  If you have any suggestions or want to use a different definition of what either a casual game or a life sim is, reach out to me on Twitter as @jcsirron.  This has been The Adventure Mechanics and I'm Chandler.  I'll talk with you next time.

The Importance of Pre-Production

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 my first episode on accountability:

Welcome to the Adventure Mechanics Side Quest and it's only going to be me, Chandler, today. This is going to be a mini-series where I look at some of the grittier parts of game design. It's also going to be a form of accountability for me as I take a game from prototype to a more fleshed out game. I have been a hobbyist game developer for a while now, and need a kick in the ass to get a project past the prototype phase and actually publish something. For this mini-series, I'll be taking one of my prototypes I made for a game jam and fleshing it out to a complete game.

So, where do we start? Well, if you haven't done something like this, the first step is planning. It's not the sexiest part of game design, but if you approach it with creativity, you can end up with something great. This first step is going be coming up with a workable idea. How do you come up with a concept? Well you can peruse through old game jam themes for inspiration or looking at an existing game design for your game. The most important part to keep in mind, however, is how much you can realistically make. If you're a solo developer and want to make your Magnum Opus, be prepared for the years of work that will take, despite it, "just being a copy of that sweet MMO/Battle Royale/whatever." The games you're using as a rubric had many developers each with more experience than you. As a side note, if you have made and published a game and are for some reason listening to this, I would love to hear your experiences.

The prototype I'll be using for this is an entry I made for OMGJam6 about mapping the world around you. I called it "The Mapper". It was my first solo entry for any game jam, despite participating in about a dozen game jams before OMGJam. I didn't get nearly far enough to really test out the concept of this game, so I am going back to this and working on getting the prototype more fleshed out. I feel like there's a good game in this idea and I want to spend some more time working on it to see if I can suss it out. For the purposes of this pre-production, I'm giving myself a month to get the prototype out. Here's what I have planned for this game so far:

The pitch:

You are a cartographer that has arrived at a small frontier town in need of your services. Problem is, you haven't mapped the area yet. You need to set out on expeditions to map areas of interest, making sure that you bring enough supplies to survive in the wilderness. With the hard-earned information you gathered, you can then help the town thrive. Be careful to not put yourself out of business, however. A townsperson with a whole map won't need to come back to you for your services again. You have bills to pay, after all.

[The Mapper] is a top down exploration game where the player must manually create a world map and sell portions of it to to make ends meet. The cartographer's office needs to be maintained and the player needs to be fed, creating the tension of the town getting the supplies it needs while not giving too much away where the townspeople no longer need the player.

To further flesh out The Mapper, I'm going to be formalizing the gameplay loops that I am envisioning for it. What's a gameplay loop? A gameplay loop describes what the player will be doing during a typical game session, or series of game sessions. The primary gameplay loop describes the lowest level repetitive task the player will be doing. For Diablo and it's clones, the primary gameplay loop is: kill a monster, pick up loot, sell loot that isn't of value to player. There is more to Diablo, of course, but the primary gameplay loop can be condensed down to that. Any gameplay loop that builds on top of the primary is a secondary (or higher) gameplay loop. In our Diablo example, a secondary gameplay loop is to navigate to a given location, collect an item, and return it to a townsperson. There can be many secondary gameplay loops, but it's important to define all the gameplay loops that you want to implement beforehand.

For my The Mapper prototype, I'm aiming to get the primary and secondary gameplay loops ready. The primary gameplay loop is:

- buying supplies for an expedition

- exploring the world outside town

- noting where things of interest are on a map that the player manually fills out

- returning to town before the expedition supplies run out

A secondary gameplay loop I am planning is going to be something like this:

- player selects townsperson quest from queue

- player selects the tiles (or path) from their map that they are going to sell to the townsperson

- townsperson paths to the goal tile

- if townsperson returns, they go back into the available for gathering resources pool

There will be other gameplay loops that I will want to implement, such as updating the map to reflect improvements, evading predators, and collecting supplies in the wilderness, but this will be enough for the first prototype. I only have a month to finish this, after all.

Once you have your idea, come up with the absolute basics of your design. What are the controls of your game? Are you going to be using existing conventions, such as the traditional FPS health packs or regenerating health? How do you expect the player to interact in your world? Write down the basics of what you want the player to do or feel. This is the most important part of coming up with a design. Once you have that, any feature you consider adding will have to either be in service of your initial design, or the design itself must change to accomodate the added feature. This step ends up forcing you to consider the game holistically, so you check yourself before adding to the game impulsively and getting yourself stuck in a cursed problem where two features you want are fundamentally incompatible.

In The Mapper, I will be breaking up the game into two different parts: The meat-space, where the player controls an avatar through the world, and the map-space, where the player interacts with the map they generate. With the meat-space, I'm planning on it having controls similar to the Legend of Zelda, with one hand controlling the movement of the player and the other interacting with the world. I plan on having support for both a controller and a mouse and keyboard. I'm not envisioning the player needing more than four buttons for interacting with the world. As the player moves around the wilds, they will see interesting features. Features will be of four different types: Landscape, such as forests and rivers, Resources, such as berry-filled glades or fishing spots, Fauna, such as fowl or bears, and Improvements, such as abandoned towns or roads. It is up to the player to notice and note where they find these features on their map. There will also be hazards in the world that the player will have to deal with, but I do not intend to add any real way to permanently deal with flora or fauna hazards. To that end, the player will not have an attack to use on hostile fauna. I envision that the player will be able to carry equipment to placate or distract the fauna, allowing the player to get away. These may be placed into a context menu or basic inventory.

For the map-space, I plan on having the primary interface to be selecting map tiles and either adding or removing features from the tile. Whatever control scheme used for the meat-space will be mirrored in the map-space. That means if the player chose a controller, the map-space interface will accomodate a controller. That means the map-space navigation will have to be flexible enough to accomodate either input method. The controller setup will focus on moving, highlighting and selecting tiles. The keyboard/mouse setup will work similarly, but will not force to have a highlighted tile. While exploring, the player will be able to open up the map at any time and select a tile to add or remove features. The interface will not highlight the tile that the player is currently on, but rather keep the last tile modified highlighted. I do not want the player to use inappropriate clues from the map to verify it's accuracy. When "selling" information to the townspeople, there will be a goal tile and, if there is a specific path the player wants the townsperson to take, a path from town to goal. What the townsperson needs will be shown on screen somewhere during this pathfinding process.

Notice how I haven't mentioned anything about the technology to use when I described the basics of my interface, beyond the input device support. That step will come after you have come up with your design. Pre-existing game engines are great, but some are better at some things over others and your design should guide you towards an engine/language/whatever that is best suited for your idea. If your concept comes with an existing prototype, great! The choice of what to make it in is that much easier. Otherwise, you'll need to consider what you are most comfortable with or are willing to learn versus the capabilities of the engine that you are looking at.

In my case, The Mapper jam entry I created for OMGJam6 was created in PyGame. PyGame is a simple engine that gives me control of input devices and has basic capabilities of drawing to a screen. I chose to continue in PyGame because it was what I was most comfortable with and had enough capabilities for my purposes. I could have used a more feature-rich engine, such as Unity, Godot or Unreal, but I wanted to push myself to really know what was going on in my engine. I didn't want to have easy access to those extra features so I am forced to work them out. That is why I ended up settling on PyGame once again.

One last thing I wanted to talk about for pre-production is creating a timeline. On larger projects, this falls onto project managers who (hopefully) know what the capabilities and limitations of their team are. On a hobby project, such as this one, that falls onto you. Keep realistic goals in mind, breaking it down to accomplishments you can achieve in short time frames, such as a week or two. This is not the time for optimistic projections. This is what you will be using to hold yourself accountable, so build in some padding as you move forward. You don't want to set yourself up for failure and giving leeway for unexpected roadblocks only ensures that you won't fall behind.

In my case, I have broken my progress down to milestones on a week by week basis. I am only doing this on a spare-time basis, so breaking it down further wasn't going to help me measure my progress. I also chose a week length, since I find that I will put off tasks that have longer timelines. So, for the next month, I have a series of milestones that I am pushing myself to achieve. By the time the next episode of this podcast releases, I will have a prototype ready, along with another topic to discuss as I push to get this game to release.

Thank you for listening this rather rambly podcast. As always, if you have any thoughts, questions or feedback, reach out to me @jcsirron on Twitter. This has been the The Adventure Mechanics Side Quest. I'll talk to you next time.

Bye!

 

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.

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!

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

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