Categories
Game Design Game Development Games Geek / Technical

Encourage Creativity: Addicube

Encouragement

One of elements I’ve identified for living my life on purpose is encouraged and supported creativity. Even though it is part of my life purpose, it doesn’t mean it is just for me. Part of the point of a life purpose is that it applies to everyone around me, too. I’m not only focused on making sure my own life has encouraged and supported creativity, but I want to make sure that the people around me are encouraged and supported as well.

So when I learned that Corvus Elrod, former writer of Man Byte’s Blog and current writer of Semionaut’s Notebook, was partnering up with Charles Berube of The Wasabi Project to create a game called Addicube, I thought, “That sounds great!”

But then I learned that the project won’t get started until it is fully funded. See, the project is currently waiting for enough funding through Kickstarter.com, which is a funding platform which allows projects to ask for donations from fans and friends. If enough people donate, the project happens, but if there isn’t enough funding, then no one pays any money. Well, back in January, having newly created my life purpose statement, believing in Corvus Elrod, and knowing that I wanted to encourage and support creativity, I pledged my support at the Benefactor level. Sometimes “That sounds great!” is good encouragement, but money helps, too. B-)

As of this writing, Addicube on Kickstarter has 51 backers and 89% of the $3,500 it needs to be completely funded, but there’s a deadline. If Addicube gets enough funding by April 25th, then Elrod and Berube will get started.

Frankly, I want Addicube to happen, and I’d like to ask you to help. The deadline is looming, and they’re so close to having the Kickstarter project fully funded.

Please go to Addicube on Kickstarter, learn more about the game, and pledge $5, $10, $25, or more. If you really want to make an impact, pledge to be one of us Benefactors at $250+. Let’s encourage creativity and get this game made!

(Photo: Encouraging note | CC BY-SA 2.0)

Categories
Game Design

How Deep Is Your Game Design?

Measuring pole

Jay Barnson posted a link to a video of Chris Hecker’s game rant from GDC. More details from Hecker’s own site at Please Finish Your Game.

The rant is great, so I suggest watching the video and reading Hecker’s article. To summarize, he is concerned that game developers, especially indie developers, are too satisfied with making lots of quirky, simple games, especially within a short period of time. With competitions such as Ludum Dare encouraging developers to create games in a weekend, Hecker agrees that cool mechanics can come out of them, but he wonders if there could be more value in exploring those mechanics as deep as possible.

He gives the example of Jonathan Blow’s Braid. Hecker argues that Braid has more value than hundreds of Indie Game Jam games.

I think Braid has more value because it explores its mechanic to the depth the mechanic deserves. I strongly feel that game mechanics have a kind of natural depth and value, and it is our duty as developers to follow a mechanic to its logical and aesthetic extent.

In a somewhat related article, Alex Weldon of Bene Factum wrote Density, Not Volume last year, and he argues that game designers should create games that focus and serve core mechanics rather than try to pile on as much as possible. Adding to a work doesn’t always make it better. It just makes it more. He gives the example of the original Super Mario Bros.

In these games, the player has a very limited range of powers and the enemies are likewise more like variations on a theme than completely different entities – in Mario, for instance, the Koopa is essentially a Goomba that leaves a shell behind when killed. Buzzy Beetle is a Koopa immune to fireballs. Spiny is a Koopa immune to being jumped on. Terrain and power-ups are similarly limited. The level design is based around the interplay between the player’s finite abilities and this small range of assets and challenges, presented in different combinations. And that’s enough – the original Super Mario Bros. has 32 levels, but manages not to be repetitive, because the designers were forced to be creative with what they were given. The resulting game is simple but dense, in the sense that every ounce of potential has been squeezed out of these simple building blocks.

Hecker argues that game mechanics and dynamics need to be fully explored more often. Shipping shallow games quickly isn’t enough. Weldon argues that designing a game from a bottom-up, mechanics basis is the way to go. In both cases, quality and depth is praised over quantity and volume. Cranking out 20 games a month is impressive, and you can probably discover some cool mechanics in the process. Still, it would be much more valuable to players and the game industry if you went back to some of those quickly conceived games and fully explored what is there. For example, Blow explored time manipulation thoroughly, and he didn’t add unneeded elements, such as 3D graphics for the sake of it. The game had a lot of depth, and it didn’t feel disconnected or filled with useless cruft.

How do you feel about Hecker’s rant? Do you agree that more game developers need to “follow a mechanic to its logical and aesthetic extent”? Are indie games too shallow by and large?

(Photo: Measuring poles | CC BY 2.0)

Categories
Game Design Game Development Marketing/Business

Is Single-Player Gaming Dead?

Sharing the experience

Back in October, Raph Koster wrote about a PC World interview with the lead designer of Dragon Age, a major single-player game from Bioware. Mike Laidlaw on single-player games talks about the idea of creating such games today, when games such as World of Warcraft and even Facebook games such as FarmVille dominate by leveraging their social components.

Social networking games are the current big thing. For indies who would prefer to keep making shareware, the idea that someone could make a ton of money through a relatively simple MMO is as frustrating to hear about as major game developers who learned that Tetris, as simple as it was, sold much better than anything they were working on. I know more than a few indies have grumbled that while selling virtual items and subscriptions to an MMO is piracy-proof, they don’t want to make those kinds of games. With major indies reporting piracy rates of for-sale games in the 90+% range, sticking with single-player games sounds like a tough bet.

So what do you do if you want to make single-player games? Give your player a way to share his/her story.

Instead of a game that tells the player the same story that every other player will hear, give the player the means to create his/her own story. Make the experience of playing the game personal. And make sure the player has a way of sharing that experience.

NetHack is a perfect example of a single-player game that lets you experience a story to share with others. The in-game story is minimal, the NPCs aren’t very complex, and there’s not a lot of dialogue. What the game does do is provide plenty of fuel for stories that players love to share with one another. Yet Another Stupid Death, or YASD, is a common phrase for NetHack fans. I’ve even posted my own stories of these deaths. See Engraved Note to Self and YASD, the First for 2008 for short stories about my own travels in the Mazes of Menace.

Of course, those stories aren’t shared inside of NetHack. While you can watch others play online, most people talk to each other or write about what happened. The game doesn’t easily facilitate communication between friends.

But your game can. Dragon Age apparently has a Social Engine, but as Koster points out, most successful Facebook games are successful because of the player’s ability to interact with others. Even if your game is meant for one person to play, it doesn’t have to be a solitary experience.

Dragon Age has its Social Engine.

There are iPhone games that allow players to send progress updates to Twitter.

Facebook notifications let you know if someone has challenged you in Sea Friends.

Can a friend go to YouTube to view a replay of the way I handled a tricky boss? Can I show off an achievement? Could my friends send me time trial challenges?

What does your game do for allowing shared experiences?

(Photo http://www.flickr.com/photos/wanderingone/ / CC BY 2.0)

Categories
Game Design Game Development Games Marketing/Business

Marketing Is More Important Than Product Quality

GamesIndustry.biz recently published a post called Marketing influences game revenue three times more than high scores. Research has shown that the belief that game reviews have an impact on the sales of a game is a false one.

Or at least a poor quality game with big marketing dollars behind it will sell much more than a good quality game with poor marketing.

On the one hand, it’s discouraging. Gamers already complain about bug-ridden games, the need for patches, and subpar playing experiences. I was shocked to find that FIFA ’09 for the Nintendo DS had crash bugs in it, and according to at least one comment in a game review out there, it seems that FIFA ’10 has its own share of show-stopping bugs. That the FIFA games are at the top of the charts in terms of sales has to make game players feel disheartened. And when game companies start shoveling anything they can out the door, customers will feel the need to be more discerning about their purchases. The video game industry already had a crash when anyone could and did make an Atari game. People stopped trying to find fun in video games when most of the products were horrible. And, of course, marketing dollars become even more important, which means the larger companies with the greater capabilities win.

On the other hand, none of this is really news, is it? Ask anyone who knows anything about marketing, and they’ll tell you that marketing is way more important than most people think it is. If you create a fantastic game that no one wants, of course it won’t sell. If you create a game that a lot of people want, even if the attempt isn’t the best, it will sell. Part of product development should be market research: finding out if anyone cares about what you’re creating.

It’s true across all industries, and it’s true for the video game industry. That said, what can an indie game developer do?

Generating Buzz for Indie Games and Advice for Aspiring Indies have some marketing tips which should fit your budget. It also helps to remember that major publishers such as EA and Nintendo need to make a lot more money than you do, and so your marketing budget doesn’t need to match theirs in dollars. You can spend much less and still make enough money for your business. Also remember that your time is a resource, and there are plenty of ways to improve your marketing that just happen to take more effort than money to pull off.

Marketing will have a huge impact on your sales potential. Don’t ignore it.

Categories
Game Design Game Development Games Marketing/Business

EA Acquires Major Facebook Game Developer

Facebook has grown to be a powerful social networking force to be reckoned with, and game developers who have taken advantage of the popularity are pulling in plenty of money through ads, virtual good sales, and exposure. And now, EA purchased PlayFish, the biggest publisher of social games on Facebook, for about $400 million.

So what does it mean? PlayFish’s business model, selling virtual goods through social games, is appealing enough for a major mainstream game publisher to buy into it. And if EA is buying into it, it means we’re going to see a lot more of it.

On the one hand, indie developers now have to directly compete with EA on the Facebook platform. It was bad enough for a small developer to try to gain some exposure when Zynga and PlayFish were dominating. It isn’t too far-fetched to think that EA is going to get the most eyeballs and sales, leaving everyone else with smaller pieces of the pie.

On the other hand, this is Facebook. With over 2% of the entire world’s population running active accounts, it’s a very large pie. Also, just because PlayFish now has a lot more marketing and production muscle behind it, it doesn’t mean that the smaller indies can’t produce major hits themselves. Long-lasting indie games are the rule. If a game doesn’t last past a month, it doesn’t succeed. If you can create a high-quality game that takes advantage of the social aspect of gaming, you have a good chance of competing.

Earlier this year I created a social game called Sea Friends, based off of a simple game I created called Minimalist. The mechanics are simple, and I’ll be the first to admit that it’s not a great game, but at one point I had almost 400 people playing it in a single month. I was surprised to find people I wasn’t friends with becoming fans of the game! The game was an experiment in outsourcing and rapid project development, and I wrote a Sea Friends post-mortem if you want to know how it went, but for a game that I think loses its appeal after a few sessions, it seems to have at least a tiny bit of staying power. As of this writing, I can see that a handful of people played it today, and many more have played it in the past week. The top ten players for the month all scored over 50 levels, and the number one player for the month broke 170! Who are these people?! I don’t know, but they’re saving real coral reef when they play, so that might be part of the appeal of the game.

Here are some questions: with EA on Facebook, what will happen to the markets outside of Facebook? Will casual portals see Facebook taking away their traffic? Will we find Facebook Connect on many non-Facebook sites? Can the market get saturated with virtual good economies, or is there unlimited potential here? Can Facebook as a platform be ignored if you’re going after a different part of the market, or is its size going to require you to acknowledge it in some way, even if you don’t make a Facebook app?

And when did single-player games become such a tiny niche product?

Categories
Game Design Game Development Marketing/Business

Generating Buzz for Indie Games

Paul Taylor of Mode 7 Games, creators of Determinance, wrote an article for Gamasutra called Building Buzz for Indie Games which I think ties in and expands upon Christopher M. Park’s advice for aspiring indies that I wrote about last week.

He starts by emphasizing marketing, quoting Tim O’Reilly’s message that obscurity is a bigger problem than so-called piracy.

Most marketing books and articles will tell you that marketing should start with product creation, that if you created a product before finding out if anyone wants it, you’re going to fail. Taylor and Jeff Tunnell will argue that the nature of the video game industry makes it harder to predict what people will want to play. Who would have thought that World of Goo would have been the success it is?

The bottom line for Taylor: if you are passionate about something, it will be easier to develop, but you’re going to need to find a way to get it in front of people. The more mainstream the product, the easier it is going to be, but the wackier it is, the more work you’ll need to put into marketing. And given that you’re an indie, you’re probably not trying to make something pedestrian or mainstream in the first place.

He talks about the importance of building your presence early on. All you have is simple concept art or a crazy programming demo? Post them up! SOMEONE is bound to care about them. Look at Dejobaan Games for an example. I remember seeing early videos of AaaaaAAaaaAAAaaAAAAaAAAAA!!! – A Reckless Disregard for Gravity before I even knew what it was. Wolfire Games has a development blog that constantly gets updates with technical details, concept art, videos, and general information about the business of making games. These two indies give their fans a place to rally for them.

Taylor wrote a four page article with marketing tips, taking you from concept announcement all the way through to post-release. Read the entire thing, and check out the links at the end of the article for more information.

Categories
Game Design Game Development Games Marketing/Business

Advice for Aspiring Indies

Back in August, Christopher M. Park of Arcen Games gave advice for aspiring indie game developers.

He has a number of observations after releasing his first game, A.I. Wars, and my favorite part is categorizing what class of indie game you might have your hands on. He separates them into three main groups: Indie Darlings, Undiscovered Gems, and Hobbyist/Nonprofessional.

Knowing which category you’re in is important because it allows you to realize what you can do to improve sales and get publicity. It is very important to recognize if your game is part of the last class. If you think you are running a business, but you don’t set your priorities so that you treat your business as one, it will be an uphill battle until you admit that you haven’t been dedicating the time and effort that a business calls for.

Another set of observations I liked: art is really important, but it’s usually not as important as most people think it is. Releasing a finished game with placeholder art is much better than not, and you can always release an update or a sequel or a completely new game with better quality.

As a side note, I used to think that graphics were much less important than I think they are now. Thanks to my time spent in the Game Design Concepts course and in Twitter conversations on the topic with Krystian Majewski, I’m now of the mind that the audiovisuals are as much a part of the design of a game as the mechanics.

Majewski said:

Otherwise, you run into a situation where you have an addictive game with exchangeable, hollow visuals. A growing problem today.

Bottom line: art is really important, but don’t let it be an excuse for not finishing your game.

Park’s other big observation echoes what you might hear from any discussion about marketing and sales. Refine your story. Tweak your copy. I love that Park gives multiple examples of emails he has sent out over three months.

The article has some good nuggets of information, so I would suggest reading it in its entirety. It’s not going to detail a plan for you to follow, but it is always a good educational opportunity to see what someone’s business looks like when it makes contact with the market.

Categories
Game Design Games Geek / Technical

Randomness in Game Design

Greg Costikyan gave a presentation at GDC Austin ’09 titled “Randomness: Blight or Bane?”.

It’s a long post to read, but I like how this one is actually readable. Most presentations end up online as slideshows only. Without the speaker there, the context of a slide is also missing, and it is hard to know what you’re expected to take away from the presentation. In this case, it seems he took his presentation, put it into blog post form, and used the slides as images to break up the text nicely.

He opens it up by explaining how our sense of accomplishment requires that we feel we used skill to win. If you press a button that has a 50/50 chance of declaring “YOU WIN”, it’s not really compelling by itself. We won’t feel we earned anything. It was blind luck that resulted in a victory.

So naturally you would think that if you want compelling, interesting games, you need to eliminate randomness, right? Well, that’s a tall order, something I wish someone would have told me when I was designing early games in the Game Design Concepts course.

And yet, lots of popular, long-standing, “stood-the-test-of-time” games have random elements in them. Some are more random than others. For instance, a game I’ve been enjoying with my friends these days is Farkle. It has many different names and various implementations, so if you want to know how to play, you can read the rules yourself on the Wikipedia page. The point is that Farkle is a dice game, and as such relies heavily on the results of dice throws. It’s pretty random, and nothing about the result of your roll is impacted by your skill. And my friends and I are enjoying it.

Fun fact: Sierra Games put out a Hoyle-series game with a version of Farkle.

Ok, but when you win in Farkle, why aren’t you bored? It’s probably because the player is choosing when to rely on luck. If I have 1200 points, and only one die left, there is a 1 in 3 chance of rolling well and continuing with all six dice for even more points. If I take the chance and win, that’s a huge win, enabling me to increase my score greatly. If I lose, I lose the 1200 points I racked up. On the other hand, if I want to play conservatively, I can pass the die to another player and keep the 1200 points on my score sheet. Now the next player might roll that one die and try to build on my score, essentially riding on my success, or he/she can roll all six and start over.

Another way I impact the game is in how I choose which dice to keep. If I roll six dice and get a 1 and two 5s, I can keep all three of them, but I could also keep only one of them so when I roll the remaining dice, I have a chance of getting better results.

Without the randomness, however, what would Farkle be? Part of the game is essentially gambling. I sometimes take high-risk rolls on the off-chance that I will leap ahead in scoring. I sometimes fail. If I couldn’t fail, it wouldn’t be fun. I’m basing my decisions on my understanding of the odds of scoring with the remaining dice in my hand.

I would highly suggest reading the article, but here is a quick summary of the role of randomness in game design:

  • to heighten the realism of a simulation.
  • to break up symmetry.
  • to ensure variety of play, preventing players from predicting what happens next.
  • to offset the vast differences in skill levels between players to allow everyone a chance of winning.
  • to generate algorithmic content.

There is a point where Costikyan talks about why games like Chess and Go, which have no random elements and players in symmetrical starting positions, are able to remain interesting while games such as Hex and Twixt are “solvable”.

Games in which all players pursue the same strategy result in a win by the player who makes the fewest mistakes — or, if none, by the player who has the player-order advantage.

This is dull.

Chess and Go have strategic depth, and the symmetry is broken soon enough. Hex and Twixt have an optimum strategy. In Chess, each player isn’t using the same strategy. There are many that can be pursued, especially as the game develops. This reasoning is why my early attempts at those game designs sans random elements were so hard to make interesting. Especially because it was an early, rough design, there was no strategic depth! Whoever went first would win, and if someone was mathematically inclined, they would find a way to solve my games. One of the things I did in an attempt to fix this problem in my High School Reunion board game design was make it possible for each player to pursue different paths to victory. Apparently I was on the right path in attempting this, but as Costikyan points out, Chess was developed and refined over thousands of years, whereas I was designing my game part-time for a class. I’m not going to easily create a great game design if I am trying to avoid using luck to play a role. B-)

The article also mentions a few uses of random elements which seem pointless. For instance, weapon damage in Quake was random, but never enough to impact the game in a meaningful way. Most people wouldn’t know that it was random at all. So why include it at all?

His explanation of how randomness regresses to the mean, allowing strategic elements to dominate if both randomness and strategy is possible, is also fascinating stuff.

In game design, randomness is a tool. Like any mechanic, having a deep understanding of it can only help you apply it better.

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

LD#15: Mineral Miner Post-mortem

Ludum Dare #15 is over, and I already wrote that the results are in. Aside from placing well in Community, which shows how much I love participating in LD48, I also saw my overall ranking come in at around the 40 percentile. I was ranked #63, which sounds good, but there were a number of ties for previous rankings. Out of 144 entries, Mineral Miner was 87th. It’s much better than coming in almost dead last in the previous Ludum Dare (and not completely last only by virtue of two other entries not getting rated at all), but I’ve done better.

Let’s look back on this project and see what happened. First, let’s go over a summary of the game. Mineral Miner turned out to be a puzzle game in which you drive around a cavern in a tank, getting out to collect minerals. You can only collect one mineral at a time, so you need to drop off collected minerals in your tank to collect more. If you are near a monster lair and not inside the safety of your tank, a monster will come out and chase you. If a monster catches you, you lose. If you collect all the minerals, you can leave the level and win.

What Went Right:

  • Rapid Prototyping on Paper I took a free, online game design course at GameDesignConcepts.wordpress.com, and I was able to put use those skills to great effect. During the competition, I posted about my prototypes. With only 48 hours, it can feel painfully slow, but I iterated through the design, adding a new mechanic, trying it out, and deciding whether to keep or remove it, and then repeating until I had something I thought might be fun. Painfully slow? It took me almost no time at all. In previous LD48s, I’ve been known to add mechanics at the last minute in an attempt to make a game out of the code I was writing. This time, I knew exactly what mechanics I needed, and there were no real surprises here. The finished game ended up playing exactly how I hoped it would. Prototyping!
  • Quick ‘n Dirty Graphics I’m not terribly familiar with art tools, such as The Gimp, and so every LD48 I find myself looking up how to use it to create what ends up being ugly art for my games anyway. I decided that this time, I wouldn’t try to make anything fancy. If I have any images that need text, I will use the basic text tool instead of the script-fu that creates cool looking logos if you tweak parameters just right. The tank? A square with a dot to let you know which way is the front. The driver? A yellow circle. Hey, it worked for Pac-man. I was able to focus more of my time on making the game because I wasn’t frustrating myself with trying to create halfway decent artwork.

    Screenshot-Cavern Game

    CavernGameCollisionDetection

  • I Made Sound Effects This is my fifth Ludum Dare, and only the second time that a game I made had sound effects. Because I had a game that pretty much worked the way I expected it to, I had time for some polish. I made a list of sound effects I thought I would need, used sfxr to create the beeps and boops, and wrote the code to tie it all together. Adding sound really makes a big difference to a game, and I was glad that I could do so for this one.
  • Faster Build Times and Lighter Distributables Because I had been doing some work on my Vampire Game, work that involves using TDD from the first line of code, I also did some work on my build scripts. Going from a 10 minute build time with a distributable that is already 10+MB due to including source libraries to a build that finishes in seconds and is less than 2MB is amazing for productivity, especially as it comes down to the final hour of the competition. Everything happened so much faster, keeping me focused on game development instead of getting distracted as I waited for a build to finish. Now, it isn’t as if my builds always took 10 minutes, but going from checked out source code to a complete build would. Once the libraries were built with my old system, compiling and linking would still take some time, much longer than the time it took with my new build scripts. Plus, one of the complaints I would get from previous competitions is that my game package was so large, so that’s one complaint I did not see this time around. B-)
  • Simple AI Goes a Long Way I remember taking a few minutes to think about how I wanted the monsters to interact with the level. Should they obey the walls and other obstacles, like the player has to? If so, that would take a bit of AI programming. I don’t have much experience with AI, and I didn’t want to take the time to learn it for this LD48, so what did I do? I made the monster head towards the player every step, ignoring the environment. I could explain it away. It’s a monster. Maybe it climbs walls like crazy? The big surprise was how well it looked. Besides making it move towards the player, I also made the monster randomly move horizontally or vertically to do so. Combined with the sound effect when it comes out of its lair, the twitchy looking monster moving really fast at the player actually feels scary.

What Went Wrong:

  • Distractions I have two cats, and both of them have been featured in previous LD48s, so I won’t focus on their antics too much. My home office wasn’t in a usable state, so I was out in the kitchen or living room. The cats love distracting me from productivity, and LD#15 was no exception. The one thing I did my hardest to control was external obligations. Anytime someone wanted to make plans with me for the weekend of LD48, I would politely tell them that I was busy. And it worked! I was able to focus almost entirely on eating, sleeping, and LD48ing…except for the Chicago Fire game.

    Chicago Fire vs D.C. United

    I won tickets to the Fire vs D.C. United game, which happened to be the same weekend. They were really good tickets, too, and so I made an exception. In practical terms, I lost a good chunk of Saturday. I was able to get the game finished, but having an extra hour or two would have been good for tightening up the graphics and audio. On top of knowing that, the Fire lost, so it wasn’t even as fun a game to watch from the 2nd row as it could have been.

  • The Sound Effects Were Very Rough By far the biggest complaint from people playing my game is that the audio hurts. I was able to get audio in within the last hour of the competition, but I didn’t have time to adjust it. I knew that some of the sound effects were loud and obnoxious, especially the one that plays when you bump into walls, but I couldn’t dedicate the time to tweaking it. The deadline was looming, and I still had a few more programming tasks to complete.
  • There’s Only One Level Right before the end, I realized that I did not have a victory condition. I had programmed a way to lose if a monster caught you and also if you tried to leave the level without collecting all of the minerals, but someone will eventually collect all of them. What then? Ideally, I would have added code to load the next level, created that level, and kept going. In fact, Level 2 is in the distributed game, although it is a copy of Level 1 and there is no code that knows about it. I was thinking about taking Level 1 and breaking it up into at least three levels, with each level introducing new puzzles and getting progressively more difficult. Three doesn’t sound much better than one, but it would have made a big difference. The player would have felt that progress was being made, and the later levels could introduce the trickier ways to deal with monster lairs.
  • Level Loading Bug I could not figure it out in time for the deadline, and I still haven’t looked at it since, but every so often, the level loading code would choke on the data, bringing the game to a halt. Sometimes shutting down the game and rerunning it would work. The data came from a text file, and my code is supposed to load a single character at a time, mapping the value to a tile. Sometimes, however, it would choke because a single character variable would have a value that is two characters long. For a time, I was dedicated to fixing it, but with only 48 hours, a good chunk of which I couldn’t make use of, I decided that since it wasn’t a show-stopper, I would keep going. I really wish I could have figured out why that bug was there. Besides ruining the perceived integrity of the game, I know at least one person didn’t review it due to this crash.
  • Making a Puzzle Game I didn’t set out to make a puzzle game. I didn’t want to worry about creating a lot of content. One level might not be such a problem if the level was varied and fresh each time you played. I could have created a procedural level generator, but I never built one before. I didn’t want to spend time learning how to do so, nor did I want to spend the time tweaking the algorithm to make nicer levels even if I did end up accomplishing it. Out of all of the ideas I came up with, the game I liked the most ended up being a puzzle game, which unfortunately meant I was either going to spend a lot of time making clever levels or finish a game with hardly any levels. It ended up being the latter.

What I Learned:

  • Rapid Paper Prototypes Work My game design skills are sorely lacking, but I’ve been able to practice what I learned in the game design concepts course, and it really paid off with Mineral Miner. I’m not claiming that it’s a fantastic game, but it did rank #45 in the Fun category, putting it in the top 50%, and #27 in the Innovation category, which puts it in the top quarter! It feels good to know that the game design I prototyped early on before writing a single line of code came together, and the comments for my entry showed that people saw a lot of potential in my game. Everything I wanted to put into the game, I learned from minutes of drawing on paper and messing around with tokens. I didn’t need to have a game engine coded up to explore, discard, and introduce mechanics, which means I saved a lot of time that would otherwise have been wasted on code that would get thrown away and changed needlessly.
  • Quick ‘n Dirty Graphics and Audio Can’t Be Permanent My art and audio work was minimal and saved me a lot of time, allowing me to work quickly at getting the game play up and running. Unfortunately, my overall rating got hurt here. I was near the bottom in the Graphics category at #104 and surprisingly a little better in the Audio category at #77. I was hoping for time near the end to replace crude art and sounds with better ones, but it didn’t happen. On that note, even if it did happen, it wouldn’t be more than marginally better since I don’t have the practice and skill with my art tools. One suggestion was to use images of my prototype work, and I agree, the drawings look much nicer.
  • My Pacing Still Needs Work I felt much more confident about my entry this time around, but I still found myself finishing the game at the last minute. There’s very little time for polish when the complete game forms only an hour before the deadline! It’s especially a concern since I decided to go with quick and low-quality art in order to get the game running as quickly as possible. I probably could have set mini-deadlines for myself. 48 hours sounds like an incredibly compressed period of time to make a game, and it is, but it’s still enough time to flounder. Early on, I have two whole days to worry about everything. In the last 5 hours, I’m in crunch mode. I could stand to manage my time and prioritize my tasks much better.

If I could do LD#15 over again, I would try to manage my time better. I could have had the prototype work done much earlier on, leaving me with more time to do the actual programming and arting. I might have been able to get more levels and variety in if I didn’t waste 5 or 10 or 20 minutes at a time wondering what to do. Still, even though Mineral Miner wasn’t a winner of Ludum Dare, I felt it was a success. I designed early on paper instead of designing with hard-to-change code, and I was able to focus on making the game I felt had a chance of being fun. People said they enjoyed the game and wished there were more levels. It was a complete game, meaning that aside from the level loading bug I mentioned above, everything that happens in the game happens because I designed it that way. In 48 hours, a complete game that provided some entertainment for others is a good accomplishment.

Categories
Game Design Game Development Games Geek / Technical Linux Game Development Personal Development

LD#15 Results Are In!

It’s 2 weeks later, and Ludum Dare #15 is officially over. The results are in, and I placed 5th…in the Community category. Unfortunately there was no food category this time around, or I could have gotten the gold in that one. B-)

Seriously, congratulations to the makers of the top ten overall entries! The #1 overall game was Beacon by ChevyRay, which was also featured on IndieGames.com’s Freeware Game Pick not too long ago. Congratulations to ChevyRay for making a splash there!

I’ll have a post-mortem of the Mineral Miner soon, but here’s a summary of how I did: badly in graphics and audio, decent in humor and fun, and well in innovation and theme. A number of people REALLY hated the audio, but they seemed to really like the actual game play. When people are unhappy that there is only one level, it means I left them wanting more in a good way. B-)

My entry ranked #63 overall, being 87th out of 144 entries. There were a number of ties for various placements, so the ranking only goes to #107. I’m a little disappointed in how well my entry did, but there was some great competition. I did much better in LD#13, but I still consider this Ludum Dare to be a success for me. I had a finished game by the end of 48 hours, one that got some great feedback from players. I got to practice skills from the game design concepts course I took this summer, and I would say they really helped me put this game together before a single line of code was written.

Once again, congratulations to the winners! There are some fantastic games in the mix!