Categories
Geek / Technical

Hamburger Menus Are Annoying and Terrible

A few weeks ago I posted a screenshot of my current project on Twitter for #ScreenShotSaturday.

Here’s the image I used with lots and lots of placeholder art:

Leaf Raking Game

And I immediately got some great feedback on my user interface:

Wait, what’s a hamburger menu?

Oh.

Oh, that three-lines menu thing has a name? And it’s “hamburger menu?”

I guess that’s apt.

So I looked it up and found a few good articles about why hamburger menus are terrible and should not be used anymore.

Why and How to Avoid Hamburger Menus by Louie A. digs into the problems with this kind of menu, including how it has low discoverability, and provides some alternative solutions, which requires reviewing your information architecture to see what is most appropriate.

I’m not a UX person, but I had a human-computer interaction major as a roommate in college, so I’m at least familiar with some of the terms. There’s more research to do, clearly.

Brent Jackson’s An Update on the Hamburger Menu was written as a follow-up to an article in which he argues that the hamburger menu never seems to be a good solution. He points out that since his first article many major apps have removed it, and when a major organization added it to their website, they seemed to have found a need to not only label it with the text “MENU” but also to pop up a notification to let people know that it is, in fact, a menu button. Ick.

So, no, hamburger menus still don’t seem useful, and now people have done A/B tests and have some experimental data about how less useful they are.

Basically it comes down to interface design patterns. Patterns rely on familiarity and emerge slowly over time. Most of the ones we use on the web today have been around for many years.

Users have plenty of new things to learn without adding contrived navigation patterns into the mix. Let’s stop trying to innovate device-specific interactions and leave it to the device manufacturers.

I recall when I first encountered a hamburger menu.

I hated them.

I hated them for all the reasons Louie A. says in his article.

I think it was on some artist’s fancy website which was trying to be super minimalist (a trend I hate) while being well designed. I just wanted to know who the artist was. Where was the About page?

Eventually I noticed the three thin lines in the corner of the screen, but I remember thinking, “Is that a minimalistic logo of some kind?”

Eventually I realized those lines were clickable, and I clicked. OH! There’s the navigation bar!

…What the heck? How was I supposed to know that those three lines are supposed to equate to navigation?

Then it showed up in Firefox and Thunderbird. It was subtle. I didn’t know it existed until I couldn’t find a way to do a somewhat common task when sending an email. There used to be a button to click at the top of the browser window. A quick search online later, and I shook my fist at the screen again.

And then it started showing up elsewhere and seemingly everywhere, and I felt resigned to it.

I’m wondering why I decided to use it in my own game’s interface. Maybe I was thinking, “Well, the kids are doing it these days…” but that’s no excuse for thoughtlessly throwing stuff onto a screen that my players will need to interact with.

I plan to replace the hamburger icon with another one. I’ve seen games use a gear or tools icon, which might be more appropriate here.

Or maybe I’ll find that those are annoying and terrible, too.

Categories
Game Development Geek / Technical Personal Development

Interview with Scott Anderson of Sledgehammer Games

Scott “Impossible” Anderson is an engineer at Sledgehammer Games, having worked on Call of Duty: Advanced Warfare, and was recently interviewed at We Are Game Devs, a site that highlights the various unsung and underrepresented talent who help create some of the fastest growing interactive entertainment on the planet.

Aside from his day-to-day responsibilities and advice for people who want to learn how to be programmers, he talked about his time as an indie game developer.

He touched on being part of Chicago’s early indie game development scene before his time as co-founder of Enemy Airship, working with Steve Swink on Shadow Physics.

And did that bring back memories!

I remember going to the Chicago Indie Game Dev meetings and Chicago-chapter IGDA meetings starting back in 2005. Reading my blog posts from that time is kind of embarrassing, but I guess that means I have grown.

Back then, Anderson was part of the duo that was Maw!soft, and I remember him as one of the key fixtures in the scene. If there was a game developer event in town, he was likely to be there.

During those years, he always had advice to share, a lot of which I ignored at my own peril, such as his comments on my goal for trying to use the IGF submission deadline as my project’s deadline or that I should release early and often with quick prototypes to find the fun.

I always enjoyed our meet-ups because if there was a fun idea to discuss, it was probably his, such as what a casual FPS would look like.

I hadn’t been keeping track of what the members of the old indie scene have been doing, but every so often I’d see Anderson’s name pop up in industry news, usually with me thinking, “Oh, I didn’t know he was doing that now.”

And now it sounds like Anderson will be working for Funomena soon?

Good luck, Impossible!

Categories
Game Design

The Systems Design of Tharsis

Zach Gage of Choice Provisions was the System Designer of Tharsis, a turn-based space strategy game involving dice and cannibalism.

Dice? Many video games involve random number generators, and some games such as Roguelikes use random numbers inspired by dice used in Dungeons & Dragons.

But Tharsis doesn’t just use random numbers to dictate results. It allows the player to roll simulated dice, then make decisions based on the results.

In this YouTube video, Gage explains his thinking behind the design of the systems of Tharsis and how the roll of the dice results in tense situations for the player:

And if you’re not familiar with Tharsis, here’s a tutorial video that explains how it works, giving some context to the previous behind-the-scenes video:

Although the Indie MEGABOOTH Tharsis page mentions it is supposed to be available for GNU/Linux, the Steam forums indicate that there are no current plans for a port, which is too bad. B-(

Categories
Game Development Marketing/Business

How to Create a Game Development Project Plan

In the past, my game development project plans have been little more than to-do lists of tasks and features. I had no real deadlines and no idea when anything would be done. I basically picked a date for the entire thing to be finished without any real sense of how realistic it was, and then I worked on whatever task I felt like working on until I felt it was good enough to move on to the next one.

And then I would blow past my self-imposed deadline, feeling frustrated about how much work I still had left.

I mentioned that I will be focusing on impactful results over progress in 2016, and to help me do so, I decided to create a more detailed plan for my current game.

That plan covers what I’ll be working on and completing for the next three months. I want to release a playable game to at least one player, whether it is a customer or an alpha or beta tester, at the end of March.

I fully expect this plan to be a living document that changes as I identify new requirements or tasks, finish things early or late, and learn more about what I’m making.

Creating this plan was tough at first. I struggled with how to start, and even started searching online for project planning articles.

Then I realized I live and breathe Agile software development, and Agile project planning is a thing.

I’m normally on the tail end of the process, though. At the day job, my team estimates the effort on user stories, breaking them up into tasks if they are too big. We work in two week sprints, and planning the sprint is based on how much effort we as a team think we can accomplish during that time. So, as a developer, I am usually working on directly creating the software that someone else needs me to make, and while I have input to tweak or change requirements (“We can’t do it that way because it will cause problems with the existing architecure. How about if we do it this way instead?”), I don’t generally have the ability to decide what project the company is working on.

For my business, I needed to start from the beginning, and creating this project plan was a great exercise and gave me quite a bit of insight into what I’m actually going to be doing when I say I am working on my game.

I thought about signing up for a service such as Trello or downloading an open-source project planning application, but I decided to create a simple set of spreadsheets. I already have LibreOffice on my computer and didn’t want to sign up for yet another service. Since it’s just me working on this project, it doesn’t need to scale much, but larger teams might need something they can share and update at the same time.

The plan has five parts to it: a product vision statement, a project backlog, a roadmap, a release plan, and the current sprint.

Product Vision

DO NOT SKIP THIS STEP!

This part I already had, but it’s such a key aspect that I wanted to focus on it for at least a few words.

Nothing kills motivation more than not understanding what you’re working on or why you should be doing so in the first place.

A clear statement that defines what the project is, who the audience will be, and how this project supports the overall strategy for your business does wonders for your mental energy and focus.

I can’t emphasize this part enough. I used to gloss over the boring idea of a vision statement or defining a clear mission for your business that I read in pretty much every book about running your own business, productivity, and effectiveness.

Think about it this way: you need to take a trip. How will you travel?

Without a vision or a mission, any mode of travel is a viable option, right? If you want to travel by ocean cruise, you can do so. If you want to fly, you can do that, too. Driving might also be a completely valid option. Heck, not going is fine as well. You don’t really have a wrong answer possible here.

But there isn’t a right answer either.

Now imagine that this trip is an emergency. Someone you care about is in trouble, and you need to go save him/her. A luxury cruise seems like a poor option, and not going at all is pretty much thrown out as an option. Flying is faster, but driving gives you flexibility in travel at the destination. Hmmm…

What’s the difference between the two scenarios?

What happened is that the emergency gave you context for your trip. You had decisions to make in both cases, but in the emergency, your decision-making became instantly easier because options were eliminated and you had criteria you could weigh the remaining options against.

One of the biggest jobs you have as an indie game developer and business owner is making decisions. Without a vision, a purpose, or a mission, your decisions can be random and take you anywhere.

So establishing a vision for your project gives you a high-level context within which you can make key decisions.

My vision for this project involves publishing a simple educational Android game to get more first-hand knowledge about potential customers on that platform. I’m not talking about personal information. I mean I always hear about how Android users are not willing to pay for games and that iOS is a better platform, but I want to confirm this data with MY games and not just the flood of games of varying quality in the market.

My principles for this project include that it should be educational, family-friendly, and have an accessible interface.

I changed my approach with this project last year because I realized the physics simulation I was working on didn’t serve the educational aspect of my vision.

Without a vision, I would have no direction. I could easily have kept working on the physics simulation version of this game because it was fun to try to get leaves to move in the wind just right; unfortunately, it would have been a waste of time as it doesn’t serve my vision for my business as a whole.

Establishing a clear vision for your project and ensuring that it is in alignment with the vision you have for your business (you have one of those, right?) is a hugely important step. It gives your project the context you need to make decisions easier.

Project Backlog

The backlog is basically a prioritized list of features. It’s slightly more involved than the to-do lists I complained about earlier.

The project backlog was fairly easy to make. I thought up a list of features I wanted and wrote them down.

The tough part was writing some of these features out as user stories. I found Mike Cohn of Mountain Goat Software has provided a sample spreadsheet-based product backlog, and I created my backlog based upon his recommendations. Cohn’s website has a lot of great articles on user stories, backlogs, and project planning, by the way.

Leaf Raking Backlog

He recommends the format: “As a <role>, I want to <do something> so that <business value>.”

By focusing on the player’s experience when planning this project, I am less likely to get mired in a fascinating technical problem for months. Not that those fascinating technical problems won’t happen as part of a user story, but it’s like having mini-vision statements to give context to your work.

The context of a user story around a technical problem should sharpen my focus on accomplishing my bigger goal as opposed to merely geeking out over a hard coding problem that my players won’t care about if I ever finish the game in the first place.

Writing such stories is hard if you don’t have experience with it. It’s easy to write user stories that are not really user stories or don’t really do a good job of explaining what the work is meant to be. Just following the format above isn’t enough.

As an example, here is how I started writing the Main Menu theme’s stories:

As a player I want to launch the main menu so that I can start a new game
As a player I want to launch the main menu so that I can continue an existing game
As a player I want to launch the main menu so that I can quit the game
As a player I want to launch the main menu so that I can change options

But it felt awkward and forced. The main menu is what comes up when you start the game, so there it’s actually more of a passive event. I’ve basically taken the notes I made myself “Create a main menu with four options: new game, continue, quit, and options” and tried to force them into a user story format.

Thinking about it some more, I made them better by focusing on what the player was doing and the real benefit or reason why:

As a player I want to start a new game so that I can have some educational fun.
As a player I want to continue an existing game so that I can pick up where I left off last time
As a player I want to quit the game so that I can go do something else
As a player I want to change options so that I can tweak/update my play experience

I kept writing, tweaking, and deleting features and stories until I couldn’t think of anything else I needed. I ended up with 41 stories for this project.

The next step was estimating them. At this stage, there is no point in trying to estimate each and every story accurately. After all, we suck as a species at estimating. I don’t expect to be 100% correct, but this exercise should help me identify roughly how large the project is.

I used the common project planning estimation technique of using t-shirt sizes. Stories were estimated as Small, Medium, or Large.

Finally, I prioritized the entire backlog. Given what I know about the project so far, what should be finished first? What’s less important and can wait? The idea is that whatever I’m working on is the most valuable thing at the time, and yes, I fully expect that priorities can change.

I used values spaced out by 10 so that future stories can be prioritized in between existing stories.

The most important features were assigned 10, and the least important 100, and all stories fell between those two values. Some stories shared the same priority value, mainly indicating that they should be done together.

I didn’t purposefully use numbers between 10 and 100, but it worked out that way. If I had more stories to prioritize, I probably would have kept increasing the maximum priority value beyond 100. You could use whatever values make sense for you, but the main idea is to have everything in your backlog ranked based on priority.

Just by prioritizing and estimating the backlog items, this project plan puts my past project plans to shame. I know at a glance what is important, what features I’ll be working on first, and how much effort I expect they will take. This information is good to know.

Project Roadmap

A roadmap is a rough timeline explaining when certain parts of the game project will be worked upon and when they can be expected to be finished. It’s not about features so much as what value the project will have at different times throughout the project’s life.

I’ve never made a project roadmap before, so I needed to do some research. It wasn’t that difficult. I already estimated the effort needed for the known features in my backlog, and they are already prioritized. I basically needed to look at groups of my priorities and identify high-level concepts based on my features.

I had to take my t-shirt estimates and apply them to a calendar somehow. I have no historical data as I’m starting a fresh project, and so I don’t know how many features I can accomplish in a given week. As someone with a day job and a family life, I only have so much time to dedicate, so things that might normally take a developer a day or two can drag out for a week or more split across multiple short work sessions.

So I guessed that Small features should take me about an hour, Medium stories are about two hours, and Large stories are likely going to need to be broken up into smaller tasks I can estimate as Small and Medium stories.

And given my goals for weekly development hours, I can figure out which features and stories will be done when.

Leaf Raking Roadmap

My game puts the player in the role of a child who is raking leaves to earn money. There are a few stories and features around the raking mechanic. Since raking is such a key part of the project, it’s one of the first things I want to finish early. I say finish even though I know game projects can change in development and I might change how it works at any time based on experiments and playtesting, but my roadmap shows I will have the raking mechanic done this month.

Raking requires neighbors and their yards, and so I will also start working on the neighborhood this month. Since I have a number of features involving them, some prioritized later in my backlog, I know I will need to continue working on this aspect of the game through to February. My roadmap reflects this knowledge.

Creating the roadmap helped me tweak the backlog priorities, and the backlog’s priorities helped me create the roadmap. I bounced back and forth between these two sheets in my project plan’s spreadsheet file until I felt I had the priorities and rough scheduling right.

And there it was: a visible communication to Future Me about what I wanted to accomplish with this project and by when.

Release Plan

A release plan explains at a high-level how you intend to deliver working software at the end of XYZ sprints. That is, some teams work for multiple sprints before producing a release. Others strive to ensure their software is always in a releasable state.

I decided to “release” weekly. That is, at the end of a week, I expect to have my game at a certain level of functionality identified at the beginning of the week. So my release plan identifies what I expect to work on each week from the beginning of the project until my expected release at the end of March.

Leaf Raking Release Plan

It doesn’t say exactly what I’ll be working on. That is, it’s not like I’m planning exactly which specific stories or features I’ll be working on between February 14th through the 20th.

However, that week I will be working on adding the concept of holidays to the game world’s calendar, which influences things such as whether the general store is open or if neighbors are out of town. I will add a new room to the player’s home that has specific functionality available. And I will also be working on a Large feature that I have designed as a game mechanic. By the end of the week, I expect all of those things to be done.

But I don’t necessarily know what those things should exactly look like today. I don’t have them planned as a set of tasks to work on yet.

And that’s OK. When I get to that week, the project might have changed so significantly that this feature is no longer relevant. I won’t waste time planning the specific work involved until that sprint is my next sprint.

Just like how changes to my roadmap and my backlog could impact each other, my release plan helped me figure out my roadmap.

Given my current estimates of both my backlog and how much I could accomplish in a given week, my roadmap had to be adjusted a few times. At a high level, I overestimated how fast I can finish a given set of features, and my lower-level release planning helped me see it and correct it.

Sprint Planning

Now I have a prioritized backlog, a roadmap to show me how my project will develop at a monthly level, and a release plan to show me what I’ll have accomplished on a weekly basis.

The next thing to do is plan the next sprint’s worth of work.

I first give the sprint a name. Maybe it’s not that important, but it’s another layer of context. What am I trying to accomplish this sprint? A good name helps me remember when I’m waist-deep in the work.

Here is where I take the stories I initially wrote and ask myself questions. Stories aren’t meant to be detailed project documents but invitations to a conversation, but since it is just me, I have the benefit of knowing what I mean but the disadvantage of not necessarily remembering or having thought of the details.

Sprint planning is when those details come out.

For instance, when the player selects New Game from the Main Menu, what exactly should happen from the user’s perspective? In the future I have planned to create a playable introduction to the world of the game, but I don’t want to work on it until I have the core game play down. So I specified that for now the player will start out in his/her bedroom. Suddenly this story requires the task to create an in-game bedroom.

I took each of the stories I planned to work on and broke them into as many tasks as necessary to make it clear to me what I specifically needed to do to say the story was done.

I don’t need to specify a lot of detail before I can start working. If something comes up that I hadn’t thought of before, I’ll make a decision then. You want to plan enough to know what you’re doing but not so much that you waste time on details you can’t possibly know the answer to until you face them.

I estimated the tasks based on hours I thought they would take to accomplish. I didn’t try to get it down to the minute so much as I tried to get a feel for how much time it will take me to get this week’s work done.

Leaf Raking Sprint Plan

My first sprint last week was estimated at about nine hours of work. Some tasks were done within minutes and others took much longer than expected. I ended up doing only 5.5 hours of game development to get all of this sprint done, so I was a bit off.

Each week I’ll do sprint planning again, and over time I’ll get a better feel for how much I can reasonably accomplish in a week’s worth of effort.

Was It Worth It?

Creating the initial plan took me only about a day’s worth of effort, although it was spread over a week’s worth of shorter sessions for me. Each week I can expect to invest some time in planning the next sprint, and each month I expect to spend some time updating the plan as a whole.

That’s quite a bit of overhead for a plan that is subject to change, especially with my limited, part-time efforts. The plan is also somewhat incomplete as it assumes I will be working on the project without interruption. I could get sick, and there is bound to be a weekend trip to visit family in the next couple of months that throws off my release plan if I don’t take it into account.

But even this early in the project it has been incredibly valuable to me.

Having a high-level roadmap and release plan helps me focus on my priorities. Instead of having a vague sense of wanting to finish a game and a list of ideas masquerading as features, I know what my next few months will look like in terms of my daily effort. My work for the day, the week, and the month has a much clearer context than ever before.

I am able to focus on my features from the perspective of the player as opposed to the perspective of me wearing the developer hat, which means my development will be more purposeful and effective. I will always know why I am working on something, which should help me be more conscious with my development choices. I should be less likely to find myself at the end of a year without a game published because I didn’t realize I was spending too much time on some neat algorithm.

And I have a reasonable level of confidence that I will create a first release of my game to at least one player by the end of three months. It will likely still be rough, with perhaps quite a bit of polish needed, but my goal is to get a release out then, and my plan shows me a way to get there.

In the meantime, I also have smaller planned releases of new functionality to test and get feedback on. For example, just by posting a screenshot of my project at the end of the first sprint I got some comments on Twitter that made me rethink the UI element I was using.

While I still believe in low-overhead, lightweight plans over intimidating 300-page documents no one will ever read, I think my past plans were too light to the point that it would be considered generous to call them plans. They didn’t help me figure out what I was doing or assist me in making decisions about the project. This project plan, however, has already helped me quite a bit, and I’ve barely started.

So yes, I believe spending time as a part-time indie game developer on detailed project planning was worth it.

Sources

I did a bit of research as there were aspects of this type of planning I had never done before. Here are some great links I found to articles, book chapters, and other resources that I found valuable:

Quarterly Planning Time and More on Planning by Steve Pavlina: some old articles on the importance of planning. He also had a recent newsletter in which he promoted the value of creating detailed, long-range plans.

Agile Project Management for Dummies Cheat Sheet: I’ve heard good things about For Dummies books. Although I haven’t read this book, the cheat sheet gave me a good overview and summary of the project planning process.

Mountain Goat Software by Mike Cohn: There are so many good free articles here that give you an overview of many aspects of Agile project planning and Scrum.

The Art of Agile Development: Release Planning by James Shore: This chapter portion focused on release planning, and I found it helped me understand what I was really trying to create with my release plan. There is a common idea of the “last responsible moment” to break down things into details, and this resource does a good job of talking about it.

How to do Agile Release Planning by Kent J. McDonald: Another article on release planning with links to quite a few resources on the topic.

We Need Planning; Do We Need Estimation? by Johanna Rothman: A quick read about the idea that detailed estimates aren’t a good use of time. You want to work on the most important thing and deliver results incrementally and iteratively. “This is risk management for estimation and replanning. Yes, I am a fan of #NoEstimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.”

Categories
Game Development Marketing/Business Personal Development

2016 Will Be Different

I know I’m a bit late to the New Year-themed posts, but I spent the last week thinking and working on my plan for the new year.

But first, I’d like to talk about 2015.

What Went Well in 2015?

First, I learned about a lot of stuff.

I read 54 books, which is a little more than one book a week. In 2013 and 2014, I read around 40 books each, so I’m proud of finally hitting this book-per-week accomplishment.

Audiobooks from the library and a 20 minute commute to the day job helped. Ebooks on my tablet to read during lunch and other periods of downtime also helped. Most of the ebooks were obtained through Project Gutenburg, Pragmatic Programmers, and the Humble Book Bundle. And I also enjoyed reading a huge stack of Terry Pratchett books that a friend lent me shortly before Pratchett’s death.

Only six books were directly related to either game development or personal development. The rest were fairly evenly split between fiction and non-fiction.

That isn’t to say that I didn’t learn much. I learned about the Prohibition era, the Wright brothers, and Charles Lindbergh’s historic flight over the Atlantic. I learned about the history of chess, and I learned about Phil Jackson and Michael Jordan’s leadership on the Bulls. I learned about prostitution in Chicago’s Everleigh Club, and I learned about how humanity’s understanding of information as a concept has changed over the centuries. I allowed myself to get fascinated with biographies and histories, and I think the exposure to all of these ideas and knowledge can only help my creativity.

Another thing that went well in 2015 was that I remembered my goals.

In the past, I would make goals for the beginning of the year, and then I would find myself at the end of the year remembering that I had set goals almost a year prior. I would lose sight of the big picture because I was focused on the actual details of work for a long period of time, or I would just forget that I had a goal and so not remember to make plans to achieve it. Some people hate New Year’s resolutions because they never keep them, and I would feel this frustration with my goals.

If I got sick, it would sometimes set me back so much that I had a hard time getting back into whatever daily habit I had established. It was too easy to get knocked off of my routine and keep me off.

Last year, however, I think I did a very good job of keeping my goals in front of me. I may not have actually MET my goals, but throughout the year I was making progress on them or at least being fully aware when I CHOSE not to give them a priority.

I made highly visible reminders for my quarterly game development and writing quotas I was trying to meet, my monthly “big deals” I wanted to accomplish, and my weekly outcomes.

At any given time, I knew what I was supposed to be focusing on. As an example of one result, I put in a lot more game development hours than I have in the past.

Considering that many business owners say that focus is one of their greatest challenges, I’d say that 2015 was a win in this area.

What Went Wrong in 2015?

Last year was the first year my business made no income.

That’s exactly $0.

It’s not hard to see why. The main reason was because I didn’t publish a game.

An entire year went by without me creating and publishing a commercial game, and a commercial game should be my primary way of trying to earn income for my business.

Now, I worked on a project during this time. I had some false starts with it, though, and I changed direction, and it took me awhile to get the design down to something manageable. I did paper and digital prototypes, and I did some infrastructure/technical work as well.

What’s frustrating is that I made an effort to put in more time towards game development. I have a day job and a family, and so taking advantage of my limited “spare” time to make progress on my game project required discipline and effort.

And quite frankly, THAT part worked out fairly well. As I mentioned above, I set quotas for myself, and I managed to spend more hours on game development in 2015 than on game development and writing combined in either 2013 or 2014. So, good job, Self.

The problem is that I didn’t have a specific plan. I had tried to make a plan, but it was little more than a list of tasks that weren’t necessarily well thought out.

This kind of a minimalist plan might be more than enough for some game developers, but since I didn’t set deadlines or milestones for myself, it was easy for me to take a task and work on it for way longer than I needed to. That game menu could be generalized and data-driven, right? I could write my own “simple” physics engine, right?

I tried not to worry about estimates or deadlines, and instead I focused on just making progress every day. The thinking was that eventually I would finish.

The thinking turns out to have a flaw. Basically, I was focused primarily on effort, and it didn’t get me anywhere very quickly.

In the past, I made some money through Google AdSense and Amazon affiliate links. Not much, but more than enough to pay for my web hosting.

These days, my blog isn’t as popular as it once was, and ad revenue has almost completely dried up. I used to make an order of magnitude more per month, and I could expect to get a check from Google every six months or so. Now, it’s been a couple of years since they last paid me because I haven’t hit their minimum threshold yet.

And according to my projections, they won’t pay me this year, either.

How Will 2016 Be Different?

In 2015, I set a goal of publishing at least one game by December 31st. I fully expected to publish one much earlier, but I gave myself that long deadline as a very generous cushion.

Every month, I would find myself realizing that I was getting closer to that deadline without much to show for it. Then it was December, and then it was 2016. Oof.

So, that generous cushion was stupid. I never felt any urgency.

At dsmAgile in September, I saw Geoff Wilson give a presentation called “Barely Manage to Lead”. He talked about a game project that failed after working for a year and a half before getting user feedback. Today, one of his keys to success is to create and deliver a Minimum Viable Product in 90 days or less.

I found that even though I actually had about 90 days after his talk to focus on creating this MVP, I still didn’t accomplish it.

The lack of a solid plan was my real failing. I erred on the side of too little formality. After all, it was just me in my business. It’s not like I needed to do any kind of formal reporting to a stakeholder about progress or release projections.

But remember, last year showed me that keeping my goals in front of me helped me remember to keep working on them. I realized what I needed to do was focus on impactful results instead of effort.

Since a more laid-back kind of project plan (or the lack of one) didn’t help, I’m going to swing the pendulum the other way and do more formal planning.

2016 Plans

I spent almost nine hours over the last week creating a project backlog, identifying all of the features and goals I have for my project. I created a project roadmap for the first time in my life, which helped me identify roughly what I’ll be working on and when. I created an initial release plan based on my rough estimates, breaking down what I’ll be working on each week for the next three months. And I have my first week’s tasks based on the items in my backlog that I will be working on.

I’ve never had such a plan in place for myself. The closest I came was when I was working on Stop That Hero! and had created a backlog with items allocated to sprints, but I allowed myself to slip self-imposed deadlines too often instead of doing the needed reprioritizing and replanning. I felt like I needed to do real work instead, and I never realized how much creating a prioritized plan IS real work.

This project plan, however, fills me with confidence that I will have something to show for my efforts in a few months. For the investment of a few hours, I’m sure I’ll save plenty of time and will be able to hit my goal.

I also want to direct my learning a lot more, and so I will create a skill-development plan.

I want to repeat my book-a-week accomplishment this year, but I want to be more conscious and deliberate about what I read in service of my skill-development goals. For example, if I want to improve my cooking skills, I’ll seek out multiple culinary books and audiobooks and read them all in a row.

My outcome focus also means I’m open to other ways to accomplish this learning besides reading. As another example, one of my goals is to learn more about Machine Learning, and aside from reading about it, I know I can watch Caltech’s Machine Learning lectures that a colleague told me about.

So, bottom-line: 2016 will be different because my focus will be on outcomes as opposed to effort and putting in hours. Those things will still be needed, especially as I’m a part-time indie game developer with a day job and family, but those efforts will be aimed at targets rather than be seen as good for their own sake.

I will take what I did well in 2015 and harness it way better. I’m excited about 2016, and I can’t wait to tell you how I succeeded.

Happy new year! B-)

Categories
Geek / Technical

User Poetry: But Not Me

While cleaning and rearranging my office, I found an old tech support email from a job I had many years ago. I printed it because I was amused with how the author spaced out the lines and capitalized the first letter of each line. It almost looked like poetry.

By the end, I think it starts to feel like it would fit into a techy version of “Where the Sidewalk Ends.”

So I labeled it “User Poetry” and titled it “But not me”. I’ll change the author’s name and other identifying info to protect the innocent.

Attn. Unix Guys,

I can log into Unix session by telnet to dvap8 with my userid (jsmith) and my password.

However, I can not get to it by Hummingbird Exceed session. I go to Hummingbird Exceed session

In my Computer and put my userid and password successively and Hummingbird session takes it but clocking

And clocking with its welcome window screen. When others login with their userid and password in Exceed

In my computer, they get everything but not me.

Categories
Game Design Game Development Games Marketing/Business

Making Your Game Accessible to People Who Are Color Blind

I’ve written in the past about designing games for color blind players because I believe accessibility is important. It doesn’t take too much effort, and a significant number of players will appreciate it.

Alan Zucconi wrote a multiple-page, interactive tutorial on making your game accessible to color blind players.

He provides a shader that simulates different types of blindness, such as Protanopia (red-green color blindness), in order to help a developer test a game to see how accessible it is.

While the download and tutorial itself is Unity-specific, he provides a good amount of background on the different types of color blindness. That information could be applied no matter what game development tools you use.

Even if you didn’t want to use the shader in question, the tutorial explains the theory behind it so you could always implement your own tool.

For example, I used SDL and a custom engine to create my casual strategy game Stop That Hero!, so adding shader support just to test colors seemed like a lot of work.

Instead, I took a screenshot and the RGB values Zucconi provided, then manually plugged those values into the Channel Mixer tool in GIMP to generate the following image:

Stop That Hero! with Protanopia

If you don’t have Protanopia, you can see the difference. The image on the right looks darker, and some of the colors aren’t discernible. I am pleased to see that my use of contrasting colors mostly worked, as the mountains and trees are easy to see compared to the ground.

On the other hand, key visual indicators are lost. My use of red to represent a depleted health bar is almost indistinguishable from the green part if you have red-green color blindness. Whoops. B-(

The images in Zucconi’s tutorial have a slider that lets you see how different kinds of color blindness may change how your game’s visual will be received. It’s amazing to see a gorgeous, colorful game like The Witness become washed out and almost monochromatic.

And for some people, it’s a permanent filter they can’t opt-out of, so if your game depends on color in order to play, you’ll want to make sure it doesn’t inadvertently leave these people out.

Categories
Game Design

Improving a Game’s Design in Mere Minutes

Recently I volunteered at an event in which I facilitated a simple math game for 10 minute sessions with a rotating group of children ranging in age from 4 to 7 years old.

The event I volunteered at was a celebration for refugee children who had just finished taking one of their last math tests in an educational program. There were math-themed games and a potluck after.

We had about eight game stations, each of which consisted of a simple math game at a table with a few chairs and at least one facilitator. Some of the games were made up by the educators volunteering, and others were given or found online.

An Incomplete Game

I was assigned a game called Double It.

Double It Game

It consisted of a die, transparent markers in two colors, and a sheet of paper with a 4×6 grid of even numbers between 2 and 12, with each number repeated four times and placed in some arbitrary order.

I took some time to look at it before the event started. As a game developer, I immediately noticed a problem with the game: the rules weren’t comprehensive.

“Roll the die. Double the number. Cover the answer below.”

So, what’s the victory condition? I felt like maybe it was implied, but there were a number of variations I found that could work in this format.

If it was a square grid, then it could be math-based bingo card, but it wasn’t a square grid. Maybe whoever gets the most markers on the board wins?

But then I realized that with only four copies of any one number, there was going to be a situation in which a player will roll a number, double it, and find that the answer is already covered. What then?

I hesitantly asked the obviously very busy organizer of the event, who said, “Well, just let them roll again.”

Ok. Seems satisfactory.

And immediately after she left to continue her work, I realized that the game would then always end in a tie.

I had mere minutes before the event started, but I was not happy with this game.

On the one hand, I get it. It’s less about the game and more about teaching math skills. It doesn’t have to be an award-winning game. It just has to be a framework to let them practice within it.

On the other hand, the point of it being in game form is to be a compelling experience. As it stood, maybe the children wouldn’t recognize that it was a foregone conclusion that it was going to end in a tie, and maybe they wouldn’t see there was no challenge or conflict involved, but it seemed like chocolate-covered broccoli, and I wanted to do better for them.

Game Design in Five Minutes

So I gave myself the constraint that the original rules had to be the base of the game, but I set to work to make it a real game.

Given that Double It was supposed to be for 1st graders, I made sure not to get carried away with complexity. There’s no sense in turning this game into something like Vlaada Chvatil’s Mage Knight. In fact, with mere minutes to do this work, I only had time to do some simple tweaks.

Luckily, I got a chance to playtest with one of the other facilitators, and it really helped to talk about the rules changes aloud.

So here are the new rules I added:

  • If a player has all four answers covered, then he/she has a monopoly on that answer.
  • When trying to cover an answer, if there is no uncovered answer, and if the opposing player does not have a monopoly, then the player must remove the opponent’s marker from an answer and can place his/her own marker on that answer.
  • The winner is the player with the most markers on the board once the entire board is filled or time has run out.

The second new rule adds conflict and actually allows for the victory condition described in the third new rule to be met. The first new rule came about as a way to reward the player for getting all four answers, as it seemed like there should be a way to prevent the opposing player from taking your markers off the board.

Playtesting

So how was this game? Well, luckily I had a rotating group of playtesters to let me know!

When each game session started, I found that the children were relatively quiet. Some of them were able to double numbers effortlessly, and it was fascinating watching them quietly roll the die, place a token, and pass the die to the other player. Some had more difficulty and needed help, so I held up my hands and tried to let them visualize what it meant to take a number and double it. In general, this early game was somewhat compelling on its own due to the math and it being a novel set of rules.

But once the board started getting filled up, my new rules came into effect, and I was pleased to see eyes lighting up and smiles breaking out. Some of the children got really animated, and you can tell the engagement level changed. Now they had a reason to pay attention to their opponent’s die rolls, and there was this sense of protection over the board.

I was worried that someone would get upset that he/she had a marker “stolen” by the other player, but instead I saw sheepish grins, which surprised me. Even losing felt fun, apparently.

End Results

Given the very little time I had, I think I did fairly well. With some more design iterations, I might have been able to add some skill and decision-making into the game.

The end result is determined by die rolls, much like how the card game War is determined by the order of cards distributed. There was no skill involved, and so my game still lacked something to make it truly a game.

On the other hand, it still seemed more compelling to add conflict to the game. There was a sense of risk, which gave the players a sense of ownership. That they had no control over what happened may not matter as much for a game for children.

The Future

If I wanted to continue to iterate on this game design, I would start with allowing players to choose between covering an uncovered answer and taking an opponent’s covered answer. Now randomness isn’t the sole arbiter of the game. The players would have some agency, and it could make monopolies feel like a real accomplishment, but I feel like there should be a risk involved in not taking an uncovered answer.

Also, I found the grid layout seemed to bias people to expect it to be a bingo-like game, and so I would change the layout to remove that expectation.

Of course, designing a game for children means that the game doesn’t need to be more complicated than it originally was. Maybe. Perhaps if it got too lopsided, one player would stop wanting to play. This is why playtesting with real players is important.

The original focus was on doubling numbers, and I wonder if educational games work better when the educational aspect is presented as a prerequisite for playing in a subtle way.

That is, now doubling numbers was something you had to know how to do in order to play, and it was not presented as the entire focus of the game. Children who struggle with math seemed to be nervous about the early part of the game, but once the new rules kicked in, I noticed they were more quickly getting through the math part so they could see what happens next. It was as if they had found a higher level reason for bothering to do math rather than just doing math for its own sake.

It’s like learning how to read in order to better play The Oregon Trail or learning how to count to play Candyland. These games weren’t ostensibly about learning how to read or count, but as you played, you HAD to get good at those things in order to play the game better.

Another bit of evidence for this kind of education is also anecdotal. On my Apple II C+, I had Stickybear Typing, which was supposed to teach me how to type. I didn’t like it much. Yet, when I learned how to program and started trying to get the computer to do things for me, I found myself practicing key presses to the point that one day I didn’t have to look at the keyboard. Typing was a skill I picked up because I had a context in which to do the typing. When typing on its own was the goal, I struggled.

As I’m not an educator, anyone know if there is already a name for this kind of learning/teaching?

Credits?

Thinking about exploring this game’s design made me wonder where the original game came from.

A quick search online shows that Double It seems to be Doubles Aren’t Trouble, which is a freely available exercise from Jennifer White’s First Grade Blue Skies. The name and design of the paper is different, but the layout of the numbers and the initial rules are exactly the same. White has a number of free and for-sale resources for the classroom, including games and craft exercises for a variety of grade levels.

Categories
Game Design Game Development Geek / Technical Personal Development Post-mortem

LD33: Free Me, You Idiots! Post-mortem #LDJam

Ludum Dare #33 is months old, and the next Ludum Dare is about to begin. It’s about time I wrote a post-mortem about the game I submitted.

The theme was “You Are the Monster”, which, as usual, caused a lot of panic among the participants who worried that it was impossible to make a game based on that theme in two days. And once again, despite such worries, there were almost 2,000 entries submitted, so people found a way to do it.

I ended up making a fairly compelling, somewhat humorous, non-violent strategy game about being an imprisoned evil using its influence to escape. I called it Free Me, You Idiots!

What Went Right

  1. Quantity Over Quality: Fleshing Out Concepts and Designs Early

    It’s easy to want to get started right away. You only have 48 hours, and every second counts. But I also knew from experience that it helps to spit out as many concepts as possible early on, then pick the one that seems most promising. You are more likely to have a good idea picking the best of a thousand ideas versus the best of ten ideas.

    So I spent the first couple of hours thinking, doodling, and discussing with people on IRC.

    The theme had a lot of obvious and not-so-obvious applications. The obvious choice is to harvest ideas from classic movie monsters, such as vampires, werewolves, and ghosts. It’s direct, and you could have monsters who are genuinely scary or you could have them be misunderstood by the populace.

    The next-most-obvious choice is to think about metaphorical monsters, such as people who have the most evil and disturbing thoughts. It could be a psychological thriller in game form.

    I thought about characters, origin stories, and settings, and I had a lot of fun thinking up ideas as varied as space aliens and beings frozen in the Arctic for centuries.

    I went with the idea of the incarnation of evil imprisoned in a tree for centuries. With no previous story, I was free to write my own with no preconceptions.

    I fell in love with the idea, which really helped me drive the development of the game. If I hadn’t spent time upfront thinking, I might have settled for a merely OK idea, and I might not have found myself as passionate to work on it.

    I spent quite a bit of time thinking about this concept. I threw out a lot of ideas early on and managed to find the core of the game. I had originally thought about having a bunch of stones surrounding the tree that you were imprisoned in that had to be removed by the nearby villagers under your influence. I mocked them up and played with the idea for awhile.

    Concept: An imprisoned evil

    Imprisoned Evil prototype

    Imprisoned Mock Up

    The idea was that rock-gathering was an activity for the villagers, and the villagers would grab these forbidden rocks.

    I’m glad I threw it out because I ended up having entities that did hardly anything but explore and pray. I would have run out of time without a way to remove those rocks and finish the game.

    I think if I had more than two days that those rocks would still be in the game and the entities would be mining, chopping down trees, and more, but because I had a wealth of ideas to choose from, discarding some didn’t feel like I was gutting the game of its essence.

  2. Iterate Like You Mean It

    In the previous Ludum Dare, I spent a lot of my time on animations and art, but not much at all on game play. By the end of that compo, which had a theme of “An Unconventional Weapon”, I had a monster that could chase around the player when you got his attention either by shouting at him or by crossing his line of sight. I wanted the monster’s head to turn separately from the body, and there was going to be this idea that the monster can trip over itself when it is moving in the opposite direction that it was looking. I spent a too much time creating the complex animation system when I could probably have gotten away with something simpler, and as a result, what I submitted wasn’t anywhere near a finished game.

    I didn’t want to make that mistake again in Ludum Dare #33. Even so, I didn’t start writing code until the compo was well underway. While I was worried that I wasn’t going to make everything I wanted by the deadline, my approach meant I was always going to have something to submit.

    My first focus was on interactivity. If the player can do something, I can build upon it, even if I have to cut most features or change the direction of the game design completely.

    It meant I was also playing the game frequently. I would make a change and immediately see how it felt. I can identify things that may be buggy or hard to understand, and I can fix them immediately or prioritize them.

    For instance, when clicking on an entity in the game, an arrow appears over them. This was a simple bit of polish that I thought seemed important enough to add early on. With a bunch of entities moving about, this arrow meant it was easy to identify which entity you were looking at.

    But moving around the world was a bit jarring. You click, and the camera centers to that location. I knew I wanted to add interpolation to smooth the camera’s movement, but I also knew that what I had was passable and could be fixed if I had time for polish later. So the working yet jarring camera movement stayed throughout the rest of the game’s development.

    What was exciting was that by making small yet meaningful changes, it allowed me to add a relatively complex economy without much effort.

    LD#33 Game Play

    The game features a few variables that are interdependent and make it feel quite rich to explore. For instance, the player has Evil Energy to use to influence villagers. Evil Energy replenishes one point every second.

    The number of followers influences the amount of maximum Evil Energy a player has. More followers meant more maximum Evil Energy, which opened up options for the player.

    When you have followers, they will pray to you. When the total amount of prayer time exceeds 10 seconds, the player gets an extra point in Prayer Energy, which can be spent on upgrades and ultimately on the ESCAPE option, which ends the game in victory.

    I originally didn’t intend to add so much because I was worried about spending too much time on balancing all these variables, but without all of these different values and their interactions with each other, the game felt very simplistic.

    I’ll admit feeling worried that I might find that the whole thing was unworkable and would result in nothing but wasted time. Learning about and playing with game economies from the book Game Mechanics: Advanced Game Design by Ernest Adams and Joris Dormans gave me some confidence I could pull it off by adding pieces of it throughout development and building upon them iteratively. Each addition was relatively risk free and easy to fiddle with.

    I was very pleased with the results, and so were the people who played the game. I was surprised by how many actually played it all the way to completion!

  3. A Goal for Being Cool

    I realized that back in pre-20 Ludum Dare compos, it was easy for me to play almost everyone’s games because there was less than 100 entries. There would be a burst of game development activity for a weekend, and then maybe a week of playing and rating games, and then going back to regular life. Plus, back then you didn’t need to rate games to get your game rated.

    Today, with thousands of entries, it takes much more of a commitment. Your game won’t show up in the random sampling for entrants to rate if you don’t also rate other games. It’s a fair system.

    After the compo, I was on vacation from the day job and so I spent the next few weeks playing games. I set myself a Coolness goal. I figured that if I played a handful of games a day consistently for the next couple of weeks, I would be able to hit it.

    And when I rate games, I like to give feedback to the developer. I don’t just post “Nice!” or leave no comment at all, so I wasn’t going to allow myself to speed through reviews in order to quickly increase my Coolness. I was going to play games, give them a fair shot, and give an honest review with constructive feedback.

    LD33 Coolness Result

    I only got 63% Coolness, but it was enough to earn me a bronze medal. I don’t understand how that percentage is calculated. I know I didn’t rate anywhere near 63% of the nearly 1,199 games submitted, yet it seems like I could have hit 100% with only a few more handfuls of rated games if my math was correct.

    But I know that if I hadn’t set a Coolness goal, I would have either made the mistake of not rating enough games, resulting in my own game not getting rated by many participants as in past recent compos, or I would have spent a lot of my waking hours doing nothing but playing LD games, ignoring my other responsibilities. I think I had the balance mostly right.

What Went Wrong

  1. No Polish and No Sound Effects Again

    In an effort to speed development along, I did the opposite of what I did in the previous Ludum Dare compo and ignored animation and polish as much as I could. It wouldn’t matter how cool something looked if the player had nothing interesting to do.

    As a result, the game lacks life. The entities move around without turning or animating, and there is no indication when a player successfully influences someone. The grass tiles had markings which were too subtle and resulted in a sea of green that made it difficult to tell if the player was actually moving the camera.

    Now, it wasn’t completely bad. The prayer bubbles added a nice touch, as did the Evil Energy ball in the HUD scaling quickly when it replenishes. The flavor text had some humor and lore.

    But no sounds, no animations, and no special effects left the game feeling like a lot was missing.

  2. Buggy Engine Code

    There were a few problems with the custom engine I was using. One was something I saw in the last Ludum Dare in which tiles would seem to separate as you moved the camera around. It turned out to be a floating point error that resulted in me accidentally scaling the tiles so they would sometimes be one pixel smaller in width and/or height. I must not have pulled in the fix when I was putting the project together, so I easily fixed it, but it still took me some time to figure out what exactly I was missing.

    Early on I noticed that entities seemed to walk over the tree. They should look like they are in front of the tree when standing in front of it and behind the tree when they were behind it.

    So why were they always appearing on top of the tree no matter where they were?

    I recently ported my code from libSDL to libSDL2, and sprite rendering was done differently to accommodate scaling and rotation. Unfortunately, I introduced a Z-ordering bug which, after spending time on figuring out what was going on, I decided to ignore for this compo rather than spend more time trying to fix it.

    The risks of using your own code instead of a ready-to-go engine such as Unity or Game Maker is that infrastructure bugs like this are not only likely but also might be something you feel inclined to fix immediately. If Unity had a bug, I’d work around it because I’d have no other choice. If my own code has a bug, I’d feel like I could fix it while working on my game and might underestimate the effort it would take to do so.

    So while it wasn’t fatal, I had buggy infrastructure code that slowed me down and prevented me from making a better game.

  3. Missing: Some Features and Any Challenge

    One of the upgrades in the game is CAUSE FEAR. Do you know what it does?

    If you guessed it caused the villagers to be afraid, you would be wrong.

    It does nothing. Why?

    Because I never got around to it. I had ideas for what CAUSE FEAR would do, but since so much of the game didn’t get made, such as the mining and wood cutting I mentioned earlier, there was no real reason to cause villagers to be afraid. Maybe it would make them pray harder for a bit, and so CAUSE FEAR was similar to trading Evil Energy for Prayer Energy but in an indirect way.

    I had a few ideas, but none of them got implemented. Unfortunately, I left the option in even though it did nothing. Whoops. B-(

    Similarly, because there was no real conflict in the game, there was no challenge. There is nothing in the game that prevents you from converting every villager, getting all of the energies you need, and winning the game.

    I wanted the good villagers to try to convert back your followers. I wanted different kinds of villagers, such as priests and acolytes, and have their presence force you to change your tactics. Perhaps if your followers got numerous enough, the other villagers would go to war with them.

    Something. Anything.

    But instead, there’s nothing. There’s enough economy and variety that it seems to hide this lack of conflict, but without conflict, I can’t really say I have a complete game.

What I Learned

  1. A Design Document Is Key

    Throughout the compo, I set myself goals. I set an initial goal of settling on a concept within two hours. I set a goal of having interactivity early on instead of waiting until the end. I set a goal for rating games after the compo.

    Each goal gave me some control over the outcome. I was able to focus on what was needed and ignore what wasn’t. While the lack of polish hurt, it wouldn’t have hurt nearly as much as having a fairly incomplete experience.

    What really helped in setting goals was having a design document for the project. Now, I’m not talking about a 300 page document that no one reads. I’m talking about a living document that changed throughout the 48 hours I used it to help guide me.

    Everything I thought of went into that document, which allowed me to assess what was a priority and what was nice to have and what didn’t need to be there at all.

    I could see what was left and compare it to how much time I had left, and I could make intelligent decisions about feature cuts and what had to be there no matter what.

    I credit Hybrid Mind’s Ludum Dare #29 timelapse for In the Black for showing me how effective a design document can be for even a short 48-hour project. Thanks, Dave!

  2. A Game’s Economy Can Have a Big Impact on the Game’s Appeal

    I was glad I decided to risk adding more to the economy of the game. Evil Energy and Prayer Energy play off each other in an intuitive way, which makes the game more compelling.

    I think people kept playing because throughout the game there was always something to aim for. Converting a follower resulted in an upgrade being made available, which required Prayer Energy to attain, which in turn allowed more followers to be converted more easily, all with the aim of using ESCAPE to end the game.

    I could have had a simpler economy. If I eliminated Prayer Energy and made things more directly available, it could have worked, but it might have felt too simplistic.

    What I’m not happy about is that the richer economy hides a lack of challenge. I don’t want to use economic designs to act as a bandage on a fundamentally broken game.

    But I did learn that doing a decent job designing an economy can result in a great return on investment.

  3. Keep Your Nose to the Grindstone

    During the 48 hours of Ludum Dare #33, I slept, I ate, I showered, I talked with my wife, and I blogged.

    But most of my time during the 48 hours was spent on design and implementation.

    According to my records, I did a little over 24 hours of game development between Friday and Sunday. Just over half of the time spent on the compo was spent doing actual game development, and I’m pretty sure that because I lived and breathed this project, I was even making progress while showering or eating.

    Even with the failings I mentioned, I can see that this laser focus was the real reason why I was able to get a decent game finished.

    I’ve done compos in which I was distracted, and they didn’t always end well. Either I was dealing with poor health, in which I couldn’t sit at my desk for long periods of time, or I was going to a party or a soccer match.

    For this Ludum Dare, I made sure that I was 100% focused on the compo with no outside commitments to keep me from doing anything but game development that weekend.

    It was grueling and exhausting, but that concentrated effort made things move along so much more quickly than if I had spread out the development effort with frequent and potentially long breaks.

    I’m not saying breaks are bad. I took breaks.

    I am merely saying that my mind was focused on game development and not on how to interact with other human beings in a social situation or how frustrating it is when your team is losing due to the same blunders they always make.

    I rested when I needed to rest, but I didn’t allow myself to procrastinate or do much of anything other than participate in this compo.

Summary

The results of this compo were very encouraging to me:

LD33 My Results

Out of 1,199 entries, my game was rated in the top 36% overall and top 8% in innovation. My only rating that was in the bottom half of the group was for graphics, and even then it was at the top of the bottom half. B-)

I credit my ability to focus that weekend on game development almost exclusively, and all of the tools that allowed me to leverage that focus, such as my design document and setting milestones.

The main complaint from players is that there was a lack of music and sound, followed by the noticed lack of challenge. For future compos, I’ll want to focus on not only interactivity but also adding real conflict.

I may want to experiment with adding audio iteratively. Normally I add it at the end, and an informal survey indicated that a lot of other game developers add it at the end as well. I wouldn’t want to spend time on something that might get thrown out before the end.

Still, the idea is that if I can have a playable game early on in a compo, I can also have a playable game with audio early on in a compo, too.

Categories
Politics/Government

Syrian Refugees Are NOT Potentially Poisonous Grapes

In the debate, I often saw an argument along the lines of, “If I gave you 10 grapes and told you two were poisonous, would you eat any?”

It sounds clever. There’s a risk. Most intelligent people would say no, and so the idea is that taking in Syrian refugees when potential terrorists could be hiding among them is akin to consuming grapes when you know they could be poisonous.

This argument is old, as this tweet shows:

Back when the Jews were fleeing the Nazis, nations all around the world denied them access because Nazis might be hiding among them. As a result, many more were killed in the Holocaust that could have been saved.

But what bothers me about the argument is how simplistic it is. It makes it sound like the probability is known, and that the only defense against risk is to avoid it entirely. It also makes the issue about the person being posed the hypothetical and not about who the grapes are.

Saving Syrian refugees isn’t the same as benignly eating a bowl of grapes or M&Ms and “knowing” some are poisonous.

It’s like knowing that there are people in a burning building and questioning whether or not to bother trying to get them out on the chance that some of them are arsonists.

“If there were 10 people in a building, and I told you two were arsonists, would you rescue any?” is about how the grape analogy sounds. Now suddenly we KNOW that there are arsonists among them. We even have a specific number, which makes this choice seem like a balance of odds.

And yet, despite knowing we could always find non-poisonous grapes or even some other food, allowing us to pass on this specific bunch of grapes, we still feel like the non-arsonists deserve to be saved from that building, right? I hope?

Syrian refugees are people fleeing a real danger. We have an opportunity to do the right thing and save them from the people we are supposedly afraid they are.

We lock our doors to protect the people inside, but I would question what kind of person you are to leave outside someone who is literally begging for his/her life.