Category: Game Design

Categories
Game Design Game Development

Stop That Hero! Mid-January Progress Update

The last major progress update for Stop That Hero! was in November (see Stop That Hero! November Development Summary), so I thought I’d post about my progress since then.

Between moving, prepping a new office, unpacking, and not realizing how much time was passing, I messed up my project management duties in December. Combined with Christmas and family time, there is very little to report, and I finished 2010 weakly.

January, on the other hand, is looking much better. Here’s an outline of the things I’ve worked on in just the last two weeks:

  • Integrated pathfinding system with game.
  • Created Command system to populate game world with game objects.
  • Updated level definition.
  • Re-architected the rendering system.
  • The Hero can clear towers!

Let’s dig into the details!

Integrated pathfinding system with game

The nature of working with unit tests is that a lot of features get implemented in a vacuum. The code you’re test-driving is interacting with interfaces implemented by mock objects to see if specific, isolated examples run as expected.

Sometimes surprises occur when the new features are integrated with the rest of the production code.

The pathfinding system was one such feature. Everything technically worked, but when using real data, I realized there was a problem.

In my unit tests, I would check if the path gets updated when an entity was at an exact node location.

In the game, the exact center of node (10, 10) is at position (10.5, 10.5), and I didn’t realize how it would look when an entity moved to node (10, 10) by trying to get to position (10, 10).

Even when I got things working and looking correctly, I found a problem. An entity moving through a long path would eventually miss its next target node and continue moving away in the same direction it was last moving. It was a precision problem. Again, an entity was rarely at an exact node location. The entity might be a little further away. Eventually the extra precision adds up to being completely off target.

To fix it for now, I just force the entity to jump to the exact center of a node once it reaches near it. It’s a little jumpier than I would like, but the entity is never allowed to lose precision and be off path. I can correct it later, perhaps with a better implementation for movement, but for now, pathfinding and movement is functional enough.

Created Command system to populate game world with game objects

When a level was loaded, it would make use of an image like the following:

The Tile Map

It’s blown up to make it easier to see, but the real data is a 50×33 PNG. Different colored pixels would represent the terrain, and I also used the pixel color data to create the towers, treasure chests, and hero’s starting spawn point.

However, level-loading time isn’t the only time objects can be created in the game. During a game, the player can create monsters, for instance, and I’m interested in the idea of letting the player create towers instead of being handed them at the start of a session. Also, it was awkward to have the level loader code know so much about all the different kinds of objects that could be created. There was a function to create the Hero entity, and I didn’t like the idea of lots of functions for each type of game object to create.

So I created a Command system. I suppose most game developers call them Events, but the point is that I pushed the responsibility of creating game objects to self-encapsulated pieces of code that can be created and passed around.

So now when the level loader pulls in object data, it requests commands depending on the data. For example, a white pixel specifies a basic Tower, so it requests a CreateTowerCommand. When that command is executed, the game world has a fully functioning Tower.

If I allow the player to build towers or if there is any reason why a tower should get built after the game session starts, it’s a simple matter of requesting a CreateTowerCommand.

It’s pretty powerful stuff, and I wish I had thought to do it long ago! I have commands to create the Hero entity, the towers, the castle, and treasure chests, and as new features get added, I find this command system provides an easy way to centralize and encapsulate certain activities.

I’m sure there are ways to improve it, but for now, it’s working well.

Updated level definition

If a tower is represented by a white pixel, by default the terrain around it is defined by other pixels. A tower spans multiple tiles, but the pixel’s location defines only the entrance of the tower. How do I get the terrain around the tower entrance to act like obstacles?

In the end, I didn’t solve this problem yet, but in trying to, I realized something wrong with my level definition. I was trying to use a single piece of data to define two different things.

I took the level PNG and split it into two. One PNG defines the terrain, and the other defines the objects that should exist in the level. In the image above, the white, red, black, pink, and yellow pixels are in a separate PNG associated with the level.

At the very least, now it is easy to define what the terrain around a tower looks like without worrying about the ability to define the location of the tower. I suppose I could have used the same image in a different way, but again, this works for now.

Re-architected the rendering system

At some point, I realized early architectural decisions were making it hard to separate the player’s interface with the game from the game. While I managed to get the game simulation well structured and easy to work with, I had a messy implementation for rendering, and I had no easy way to implement a UI.

I explained how I got sprites rendering in the correct screen locations based on their in-game world position in Stop That Hero! Sprite Rendering Questions, but the problem is that the sprite objects were mixed into the game’s object model.

Now, imagine switching resolutions on the fly. If the sprites are all there, they have to be replaced by more appropriate sprites. And rendering requires an updated viewport to deal with the new screen resolution.

Now, what does the simulation care about how it’s being rendered? Nothing! Or at least it shouldn’t!

It took a bit of refactoring, but not a lot. I was able to leverage what I had to get to a new solution.

I now have a concept of a View. Now, I’ve looked into Model-View-Controller, and quite frankly, I didn’t think it worked very well for what I was trying to do. This isn’t a simple application with buttons and a database.

But I did like the idea of a separate view and something to process player input. The input processor is still missing, but there is now a View that handles rendering using data from the game world but without being part of the game world.

Or at least, it will. Right now, Sprite data is still part of the entity, and I’d like to change it so that the View worries about Sprites while the game objects have RenderableComponents which merely describe what Sprite the View should get. So if a Tower has a RenderableComponent that says “Use TowerSprite”, then the View can get TowerSprite out of the 800×600 sprite collection or the 400×300 sprite collection, depending on the View’s resolution.

The Hero can clear towers!

For some time, the Hero had the ability to target Towers, find a path to the nearest Tower, and move to it. But then he’d stand there. It was still the nearest target.

It didn’t take me too long to implement a way for the Hero to change the Tower’s target status. Basically, the game had to detect that the Hero was in the Tower’s entrance, and then it requested a ClearTowerCommand. That command will get more code eventually as more features are added to the game, but for now, it takes the Tower’s Targetable component and deactivates it.

Now, the Hero moves to a Tower entrance, and then he searches for the next nearest Tower until there are no more left. While the implementation details could use some cleaning up, this mechanic is such a central part of the game, and it’s great to finally see it in action again.

Conclusion

My last two weeks have been quite productive, and I wish a screenshot could show it, but most of the work is under the hood. Still, simple infrastructure work has already paid off in implementing some game mechanics more easily. I’m pleased with my recent progress.

Categories
Game Design Game Development Marketing/Business Personal Development

Six Months As a Full-Time Indie

Mike Kasprzak wrote about his five years as a full-time indie, and it’s a fantastic read. Especially fascinating was how long it was before he made Smiles and his first real income. After years of burning through savings, suddenly things came together for him, and he was winning prizes and being pretty awesome.

In contrast, I’ve been running my business officially for almost five years, but I’ve only been full-time since the end of May. On the one hand, that means my story won’t be nearly as fascinating or interesting as Kasprzak’s, but on the other hand, existing part-time indies aspiring to make the jump to full-time might appreciate reading how things look for me in the short term.

I wrote about some of the reasons why I went full-time indie, but part of it was freedom. Spending 40-60 hours a week on stuff unrelated to my business meant I was giving my business short shrift. I spent so many years learning about game development, but I could only dedicate a few spare minutes to actually doing it? It wasn’t right. So I quit the day job.

Ah, Freedom!

Did I hit the ground running? No. The World Cup was starting, and I was going to watch as much soccer as I could!

I was even writing about it at my new website, Modern American Soccer, which actually got quite a bit of traffic in the weeks leading up to the first game due to the US Central-time specific calendar I created on Google. In fact, that site was going to advertise the soccer-based social networking game I was going to create with a colleague before that project fell through, so it was related to my games business initially.

Either way, my first month as a full-time indie game developer was spent getting used to not having a day job to worry about. I knew that it meant a month of spending my savings with nothing to show for it, but I decided at the time that it was acceptable. I was taking a break and getting my bearings (and watching soccer).

Now What?

When I finally sat down to do real work related to my business, I found it frustrating to not know what I was doing at any given moment. Not knowing when my next infusion of income was coming from made me feel a bit antsy, and yet I felt a bit overwhelmed by the number of different tasks to accomplish. I wrote about how it felt in the article Clear Goals or Trivial Pursuits, and I realized I needed to define some specific goals to tackle, or at least pave the way to learning what those goals should be.

In July, I hosted MiniLD #20 with the theme Greed and the special rule “Only One of Each”, which was meant to discourage people from reusing content and code. It was one of the more successful MiniLDs, with plenty of submissions, but my game wasn’t one of them. My project, The Old Man and the Monkey Thief, was the first game development project I started since quitting the day job, and I didn’t finish it in time.

Inventory and Treasure!

It was the first game I’ve made that involved a scrolling screen, and I remember feeling incompetent. How can I have thought that I could be a full-time indie developer when I didn’t even know how to make a game with something as basic as a scrolling background? It was a scary thought. Had I made a huge mistake? Was I not as prepared for making a go at a game development business as I thought I was?

Again, one of the reasons why I went full-time was so I could dedicate many more hours towards my games. If I felt incompetent, it is because I didn’t spend nearly as much time on it as I should have, and now is my chance to do otherwise.

Setting Monthly Goals

I decided that August would be the month that I would try to complete three small games in an attempt to learn as much as I could as quickly as I could.

My first project was my MiniLD game, which was taking me much longer than I expected, partly because of how unique everything had to be in the game. I didn’t finish it until right before Ludum Dare #18, and I didn’t feel it was worth releasing.

My second project was my LD #18 project, Stop That Hero!, which involved the most complex AI I’ve ever implemented. That is, I’ve never implemented pathfinding algorithms more complex than “go directly from point A to point B”, and in The Old Man and the Monkey Thief, I learned that there was a lot of problems with a character that couldn’t avoid obstacles well. Stop That Hero! took me three days to finish, but I was fairly pleased with how it turned out and wanted to flesh it out later.

Stop That Hero! is finished

I never did make a third project.

Still, two finished games in a month taught me a lot, and I was getting feedback from friends and colleagues. Even though I failed my August goal of making three games, I made good progress towards it and learned plenty.

Unfortunately, September started without goals set for it. In order to figure out what my goals should be, I spent a good chunk of the first week or so figuring out my options as an indie game developer. I thought it would take me a night to write down the options, but then I thought I could write up an article or two for ASPects, the Association of Software Professionals newsletter. It ended up being four full length articles, and it took me almost the entire month before I submitted all of them. If you’d like to read the articles, for now the only place they’re available is in the ASP members-only archives.

I also caught up on some reading. Business articles, audiobooks, and other literature were consumed. I would highly encourage anyone starting a business to read The E-Myth Revisited. For a long time I ignored it because I thought the E- part of the name meant it was a book about how Internet-based companies aren’t get-rich-quick schemes. I didn’t know it was a book about why most small businesses fail and what you can do to succeed.

Anyway, I spent the latter half of September analyzing the heck out of Stop That Hero! and trying to figure out what design directions to take it in. This time coincided with the creation of an organized daily schedule. It gave me some much needed structure, and I felt much more productive and focused, and I didn’t feel like I was letting anything fall through the cracks. I had time for writing, reading, organizing, and most importantly, game developing.

The October Challenge

While I wanted to flesh out and sell Stop That Hero!, I was having difficulty figuring out out how long to allow the project to run. I didn’t want to put together a skimpy game in a matter of weeks. Who would pay for it? And I didn’t want to spend six months working on it since that would be half of my burn rate. I don’t want to spend all of my savings on one game, and I don’t want to put together disposable games. I learned that Flashbang Studios used 8-week projects, but they had entire teams working on their games. Did I need longer? Could I afford to take longer?

Then Mike Kasprzak announced the Ludum Dare October Challenge, and I had my deadline. Make a game and sell it by the end of the month? I could do that! It took me only three days to make the prototype, so a full month should be plenty of time to make Stop That Hero! with multiple campaigns and different game modes. Right?

I wrote an October Challenge post-mortem, but suffice it to say that I didn’t get the game finished in time. Read the post-mortem for more details about what went right and what went wrong, but one of the biggest problems was not realizing how much technology I didn’t have to leverage.

Hacking a dinky game together virtually from scratch in a weekend is one thing, but making a full-scale game requires a lot of infrastructure and technology that I didn’t have. Rather than go without, I did research and development, which took up a lot of time. Tracking entities and game objects in a way that didn’t require a ton of dependencies was surprisingly difficult, and I wrote about my difficulties in implementing a component-based system in State of the Art Game Objects.

Of course, developing infrastructure is not developing the game. It’s just laying down the groundwork for a game. Kasprzak took time off to work on a framework after PuffBOMB HD, but it sounds like a lot of it was already in a game and he was cleaning it up and improving on it. While I had some prototype code, a lot of it needed to be reimplemented. Stop That Hero!‘s pathfinding algorithm was fairly hacked together, leaked memory like crazy, and required a few other algorithms to compensate for when it wouldn’t work well on its own. The new version is less dependent on knowledge of the entities moving through it and works very well, but it took me way longer to write than I would have liked.

Besides creating the necessary technology for the game, I’ve never worked on such a large scale before. Programming is not software engineering and hacking is not project management. I didn’t have much experience leading or creating a serious project before this one, and I found myself struggling with choices. What do I call this class? Should this be its own class in the first place? Is this overengineering or good practice? And that’s just the software architecture. There was also the question of project scope. I was behind schedule, and it wasn’t due to feature creep. What was I doing wrong?

Continuing the March Towards Completion

But if I could get the game done by Christmas, I think I’d still be doing well. The October Challenge was just a fun deadline and wasn’t a must-hit, urgent business deadline. According to the work I have identified and my actual rate of work, I thought I had a more accurate project estimate, and Christmas seemed to be a doable deadline. From what I’ve been told, there is a trend of increased sales around Christmas, so it might work out better for me. I pushed forward.

I was making decent progress at first, but the end of the month involved Thanksgiving and moving out of my apartment. To make matters worse, individual game systems weren’t working quite right, so I spent part of the last week finding and fixing bugs for work I thought was finished. I was finally hitting my weekly estimates, but there were also setbacks. Progress was still slower than I would have liked overall.

Unfortunately, near the end of November, I saw my schedule slip even more when I identified a ton more work. When hacking a prototype together, there can be missing menus, level selectors, data permanence, or any number of other aspects of a game. A full game missing these features isn’t a full game, by and large. When I initially planned out the project, I glossed over a lot of these kinds of details. I wanted multiple game modes, but I didn’t plan for them, nor did I figure out how I wanted the player to access them. Suddenly my project ballooned to almost twice its size, with a likely deadline in February or March, which made Stop That Hero! the six month project I wouldn’t have started if I knew.

Burn down towards February

The Future!

It was demoralizing to miss the October Challenge deadline, but this new estimated deadline was frustrating. I initially hoped to make my first sale at the end of October, and now I might not do so until after winter? And that’s assuming anyone is interested in buying it in the first place!

All this time, my savings account has been slowly reducing in size, and it will continue to do so. I’m well aware that I don’t make money producing a game. I can only make money selling a game. I could shelve Stop That Hero! temporarily while I work on something smaller, but I fear I’ll simply end up in the same situation writ small. That is, a smaller game still requires a lot of technology and infrastructure that I don’t currently have. Plus, I don’t like the idea of dropping a project midway and starting a new one. I’m tired of unfinished projects on my résumé.

I read a lot of things that get me second-guessing my choices. Is Stop That Hero! too complex and hard to make? Should I focus on “evergreen” mechanics, as suggested at Lost Garden? Is TDD inappropriate for getting games finished quickly, or is it necessary for getting games finished quickly? Am I expecting too much from my first project, or should I take the problems I’ve encountered as a sign? Am I running into the same kind of problems everyone runs into, or do I need to scale down my ambition until I have more experience? Do I need to work on smaller projects to build up my technology and code base, or can I continue building what I need when I need it for this project? And before you ask, yes, I have made a Pong clone, among other simple games, so it isn’t like I was jumping into a very large project without any experience at all. Or, maybe the problem actually is that I don’t have enough of these simple games under my belt.

There’s a lot of uncertainty, and it would be easy to panic or freak out (and I have at certain points!), but it is good to have some perspective. In six months, I’ve done more and learned more than I have in the last five years prior. While I expected to learn a lot during this time, my existing knowledge wasn’t as helpful as I thought it was. I’m taking on roles that I never had experience with before. Before I went full-time indie, I didn’t make decisions that would have a major impact on my business, and it’s an enormous responsibility.

And yet it isn’t a crippling responsibility. It’s exhilarating!

While I have the added burden of figuring out what specifically is important, I get to focus on it as much or as little as I want. While it’s a little scary to think that my decisions can make or break my business, they’re my decisions, and part of the fun of running your own business is in learning how to make better ones. The stakes are high, but at least I’m not settling for less out of a need for security.

Six months ago, I had very little idea that I’d make the progress I have and face the challenges I did. I knew it wouldn’t be a cake walk, but I also knew it wasn’t impossible. If I could change anything, I’d have tried harder to produce results while working part-time. I wish I had more direct experience working closely with other people making games so I didn’t have to figure out nearly as much on my own.

Still, I’m only six months out, and I’m in it for the long haul. In 2015, I hope I’m writing my own five year retrospective with plenty of good news to report.

If you are a veteran game developer, do you have any specific wisdom to share or regrets to warn against? If you are an aspiring game developer, do you have any questions about what the future might hold? Please post them below!

Categories
Game Design Game Development Linux Game Development

Stop That Hero! November Development Summary

I wrote up a October challenge post-mortem at the end of the previous month, and almost an entire month has gone by. I haven’t written much, partly because I went off of my self-imposed schedule to do more game dev work at the expense of writing and reading time.

What progress have I made with Stop That Hero! in the month since?

First, I implemented my own component-based object system. I know, I know. I wrote about the frustrations of trying to implement state of the art game objects and said I would give up, but eventually I found my own way. In trying to proceed with the game’s development and putting the frustration behind me, I found that I was very close to doing the same kind of work anyway. I’ll write more about the details of my implementation in another post.

Even after I had the infrastructure for the object system, I still had to figure out how to use it. In a running game session, I understand that the game’s systems will make use of the object system and components, querying and updating them as needed, but what about initialization? Specifically, how does the hero get created? Should that object and all of its relevant components get created when the level is loaded, when the level is initialized, or as part of the first update to a new game?

Some entities will get created during the course of a game session, such as when the player creates a monster at a tower, but the hero is there from the beginning, and I was having trouble trying to figure out how to treat his creation.

I already have a number of components:

  • Position (current location data)
  • Sprite (the current sprite image to display)
  • Spawn Point (a position where an entity will be initialized when created)
  • Movement (speed and direction data)
  • Targeting (a list of potential target type IDs and the current object ID targeted)
  • Targetable (a target type ID)
  • Pathfinding (a list of traversable terrain IDs and the current path)

With the above components, I can already see the hero moving from a start location (the spawn point) to a target, which is an object made up of only Targetable and Position components. The hero picks the nearest object with a target ID matching the set of IDs he is allowed to target, avoids obstacles such as trees and water, and moves along the path generated by the pathfinding system.

The pathfinding system was surprisingly difficult. A* is such a common algorithm, and there are plenty of code examples around. Essentially, it’s a solved problem, right? The problem was that all of the code examples and most tutorials and pseudocode were node-based, whereas I was looking for something that gave much more focus to the connections. That is, it should be possible to get from one node to another in more than one way. For example, if you have a bridge, you can jump off of it very easily but you wouldn’t be able to get back up unless there was a ladder, and climbing the ladder would cost more than jumping down. Or, if the height is great, climbing down the ladder would be less risky than jumping and potentially hurting yourself.

The book “Artificial Intelligence for Games” has a focus on connections, but the pseudocode was a little difficult to follow. When the pseudocode makes use of whitespace, it’s hard to tell what code block you’re in when the source spans multiple pages. While the book says that there is a working code example on its website, I couldn’t find any code related to the pathfinding chapter. I emailed this error but the website still doesn’t reflect it, and I haven’t heard back from anyone about it.

I thought I had my pathfinding system working since my unit tests passed. Obstacles were avoided, and short paths seemed to finish as expected. It wasn’t until I gave the hero a target about a quarter of the map away that I saw a problem:

Debug Path

The hero’s path is specified by the multiple hero sprites and the black line. The dotted yellow line is what I think a more appropriate path should be if the pathfinding algorithm was working correctly. I found it very odd that the path was complete yet so suboptimal. I eventually realized that part of the problem was a bug in my node sorting, and here’s the relevant line:

lessThan == costSoFar < r.costSoFar

I didn't see the problem for a long time, but I eventually posted the code online. Phil Hassey pointed out that I was testing equality instead of assigning a value. Doh! Sometimes you just need a fresh pair of eyes.

There was also another bug in that line. "Artificial Intelligence for Games" argues that you should be using the costSoFar value to sort nodes in the open list, saying it is the only value that isn't a guess. I didn't quite understand why, but I figured such a thick text book written by experts who have worked on more games than I have would know better than I would. So, here's a lesson: never implement an algorithm without understanding it. Everyone else in the world argues you should use the estimated total cost to sort nodes. After all, you're trying to guess which one will get you to the target node in the fastest way. Sorting by cost so far means that there will be a bunch of nodes, possibly in multiple directions, that can be first. Once I changed the value checked from costSoFar to totalEstimatedCost, my paths were straighter and shorter.

Still, my pathfinding system isn't working quite as I expected. The hero can only walk on grass, but other entities could fly over everything. While they might prefer flatter areas, they should still be able to fly over trees, mountains, and water. I created a hero with the ability to move over all of these different terrain types, and I was disappointed to find that the path didn't change. He was still avoiding them as obstacles.

I realized that part of the problem is how I mapped the world representation to the pathfinding graph. Does the terrain have an absolute cost, or should terrain costs be entity-specific? That is, is a mountain always harder to traverse than grass, or should a mountain troll bias towards mountains while a slime prefer the plains? If every entity had the same kind of movement restrictions, it makes sense to have absolute terrain costs. An obstacle for one will be an obstacle for another. But if some can move through water or fly in the air, does it make sense for terrain to have an absolute cost? If I give each entity weights for terrain types, why not just get rid of the absolute costs entirely since the weights are what ultimately matter? How does a game such as Advance Wars handle it?

Other issues I had to deal with included problems with using floating points versus ints. I was using floats to represent world positions for objects, which is fine, but when I was integrating different aspects of the system together, I found that other data structures were implemented using ints. I was losing all of the precision I needed, and it wasn't until I was printing out text every few lines that I could see the problem. Unit tests didn't catch this issue because separate objects and components worked just fine.

But with pathfinding and targeting working fairly well, Stop That Hero! is much further along. Once I can move an entity to an expected target, the rest of the game will hopefully come together much more quickly. Hopefully.

Categories
Game Design Game Development Linux Game Development Personal Development

Stop That Hero! Development Continues

With the Ludum Dare October Challenge over, I am still working on Stop That Hero!. Even though I had said that the Challenge deadline wasn’t important to me, I still had this desire to meet it, and I think I had a lot of competing thoughts in my head since I never made a firm decision to hit the date or ignore it. On the one hand, it’s mentally freeing to not have a deadline breathing down my neck. On the other hand, I don’t want to take forever working on the game.

Project Estimation

My old project schedule estimates were based on a few key pieces of data. I had a deadline I wanted to meet, which was October 31st. I had the number of estimated story points for the entire project, which came out to 75 points total. Going backwards, if I did 20 points of work each week, I’d hit the date with some time to spare. Putting together a sample iteration, I felt 20 points was reasonable at the time.

In the last month, I found that I added new stories each week, so now the project’s total story points have increased to 89 points. I’ve also found that 20 points per iteration was overly optimistic, and it seems 10 points per iteration might be more doable. With this new data, I decided to estimate the project with a different set of data, and you can see the project comparison below.

Burn Plan Comparison

The flat lines to the right are basically projecting into the future based on no work being done, so you can ignore them. The blue line indicates the ideal. In the first case, I was expecting to hit 0 points on October 27th. In the new schedule estimates, I’m likely to be finished by December 8th.

What’s nice about these graphs is how much they can show you in an instant. So long as my actual burn rate and the actual backlog stay under or at the blue line, my project is healthy and progressing nicely. If they cross over to the top of the blue line, something has gone wrong. In the first case, you can see that the project was in trouble from the start. I thought that if I could start hitting 20-point iterations that it wouldn’t be that bad, but I couldn’t do it.

With the new estimates, those weak iterations were actually relatively strong, even though the last week was very poor. I only managed 2 points of work then, and I ended up adding 6. I hit a snag in development, but I am recovering from it. Still, you can see that over the life of the project, I’ve been adding to the backlog, and with the previous week, my backlog matches the estimated backlog at this time. It doesn’t give me much room to add more to the backlog, but it isn’t scary yet. If it is mid-November and my backlog is far on the upper-left side of the blue line, however, then I’ll have to question what’s going wrong.

My main concern is that there will be many more stories added to the backlog, especially since I was surprised to learn how much of the basic technology I needed to build in the last month. Also, I worry about not being able to dedicate all of my time to the project that I normally would. Besides the fact that Thanksgiving and Christmas are coming, I’m also moving at the end of the month. I’m more than certain that my project’s schedule will be negatively impacted, but since I am aware of it now, I can take steps to plan for it.

The Game’s Status

What’s implemented so far? I have a menu system which allows me to select what level I want to load. A level loader will populate a level instance with map data from a PNG file. The level uses that map data on initialization to know where to place towers and treasure chests, as well as what type for each, and it also knows where the hero’s initial spawn point is. The level loader also sets the hero’s starting lives to a hard-coded value.

There’s still a lot left to do, but the biggest thing missing is the concept of an entity.

Near the end of the previous month, I ran into trouble when it came to actually implementing the hero. The large number of added points were partly because I took a vague story for implementing an Entity and broke it down into multiple, specific stories related to various aspects of the creation of an Entity. Now instead of trying to create an entity and all of its behaviors at once (and not knowing when I’m finished or how to start), I will be working on rendering an entity, moving an entity according to its speed and direction, and other very specific tasks that are easy to understand and focus on.

Other major components include pathfinding and player actions. The prototype had a poor-but-workable pathfinding solution. While I was happy with it in terms of a weekend project, I knew it wasn’t as good as it could be, and I learned a bit more about A* implementations since then.

While the main activity for the player involves picking a monster type and deciding which tower to create it at, I’d like to investigate other things the player can do to impact the game. In previous posts I’ve mentioned ideas such as banners that all monsters will gravitate towards or clicking on resources at controlled towers in order to collect them. I’ll hold off until I get the fundamental activities implemented, but I think they could change the feel of the game in a positive way.

Once I have the ability to create entities and some way for them to move, fight, and die, the rest of the game will fall into place relatively easily. Victory and defeat conditions depend on the entities actually doing things, animation requires things to animate, and there are details and balance issues that can only be addressed when I have something to detail and balance in the first place.

Of course, I’ll continue to write about the game’s development. B-) Is there any aspect of the game’s development that you’d like for me to explain in the coming weeks? Let me know by leaving a comment!

Categories
Game Design Game Development Games Marketing/Business Personal Development Post-mortem

Stop That Hero! October Challenge Post-Mortem

October 31st came and went, and Stop That Hero! was not in a position to be sold, even as a beta or alpha project. Partway through the month I realized that even if I was able to finish the project, the work of setting up the payment systems, customer support, and even the website was going to take some time as well. According to my estimates, I’d finish the game sometime between the end of October and the beginning of December. As disappointing as it would be not to finish in time for the October Challenge deadline, I also knew that it was a “fun” deadline as opposed to a hard “must-hit-this date” for my business.

I will continue to work on Stop That Hero! because I believe in the project, but I’d also like to get better at project management. Now that the deadline has passed, I can look back on the month and think critically about how I did. Even though there was no business-related urgency in getting the game finished for the Ludum Dare challenge, I still wanted to do so, and it was demoralizing to realize that the game wasn’t going to be finished in time.

For the unfamiliar reader, Stop That Hero! was originally created for the Ludum Dare 18 Jam. The player was an evil villain in charge of a castle and a number of towers, and a hero character was trying to conquer the castle, liberating towers and collecting treasure chests along the way. The player would create minions at any of the towers, and those minions would try to kill the hero. Kill the hero three times, and you win. Lose the castle, and you lose the game.

For this project, I wanted to make Stop That Hero! a commercial-quality game that required no proprietary dependencies and ran on at least GNU/Linux (my preferred platform) and Windows, with plans for a Mac OS X port and an eye toward mobile devices. I wanted the game to be data-driven instead of hard-coded. I wanted the game to have multiple game modes and levels, and I wanted me and the players to have the ability to create our own custom levels with custom rules. I realized that it was a lot to do for a first release, so my intention was to make the game hard-coded yet easy to change so that it was using external data and scripts. Future updates would involve replacing the hard-coded bits with loadable data.

What Went Right

While it might seem strange to think that anything went right for a project that wasn’t finished, I do believe there were some good things that positively impacted the project.

  1. Planning and Preproduction Time. Even before the October Challenge was announced, I knew I wanted to take Stop That Hero! and make a full game out of it. I spent a few weeks at the end of September looking at every aspect of the game, from resource handling to monster variety to game modes.

    While I think the original LD18 game’s mechanics were marred by a lack of game balance and probably could stand on their own, I wanted to investigate every possibility for making this game the best it could be. I identified major design challenges that I wanted to focus on early on. I also speculated on how much of the game could be data-driven or scriptable. This early planning helped me visualize how I wanted the finished game to look and feel.

  2. A Regular Work Schedule. As an indie game developer, I have no boss imposing a schedule on me. Keeping my job doesn’t require my presence during official office hours anymore. Since I determine my own schedule, I can do whatever I want, whenever I want. It’s not a license to slack off and take vacations every week, of course. My income depends on the output of my efforts.

    The thing is, my time usage wasn’t very productive or balanced, and it hasn’t been for months. If I spent time on game development, I’d find that my writing would slip. If I wrote, I’d find that magazines and books would pile up in my inbox. If I read, I’d realize that I almost missed paying an important bill. Coinciding with the time I started preproduction for this project, I realized that I needed to do something to change my situation. To make my productivity a bit more predictable, I created a regular set of hours for myself. Until I had a game to sell, I wasn’t going to make any money, so production took up the lion’s share of the time I spent in a day. To ensure that there was balance between game development and everything else I wanted to get done, I gave myself regular hours for writing, reading, and organization. I use Google Calendar to setup recurring events. You can see an example of my day below:

    Regular Hours I discovered I wasn’t very good about waking up early enough for the morning stretches part, which is something I want to work on next month, but I tried to stick to the schedule. If I missed stretches, I wasn’t making it up at the expense of being late for game development. If I was late for game development, I wasn’t going to encroach on writing time. If I did make such allowances, it would destroy the whole point. For the most part I stuck to the schedule, which meant I was doing about 4-5 hours of game development per day, an hour of writing per day, an hour of business or game development reading per day, and an hour of organization per day. While part of me wondered if I needed more time dedicated to game development, the balance allowed me the time I wanted to learn, share, and prevent things from slipping through the cracks. While I might tweak the hours going forward, I definitely prefer this self-imposed, organized, and regular schedule over letting each day’s activities be determined by whim.

  3. Agile Scheduling As Early Warning System. Once again, I’m pleased with the knowledge I learned from using nothing more than a couple of cork boards, some index cards, and pins. Before the project started in earnest, I created an estimate of the work I needed to do as well as an estimate of how much I thought I could do per week. As the weeks passed, I realized how poorly I was doing in terms of keeping with the schedule.

    I wrote about it in Agile Alert: Slow Project Progress as well as Balancing Current and Future Needs, but the point was that without using story cards and a burndown chart, I wouldn’t have any idea when this project would be finished or what I could do to improve my situation. It allowed me to make project decisions earlier rather than later as well as weighing the advantages and disadvantages of delivering the finished project later.

What Went Wrong

  1. Not Planning Time For Art and Sound Work. The Jam version of the game features all art and sound created by me. I’m not that great of an artist, and I’m no sound designer. If this game is going to be polished, I was going to need to hire someone else to do the work. Of course, until I needed the higher quality assets, I could use my current art/sound assets as placeholders.

    The thing is, I never really had a plan for how I was going to go about finding contractors to provide the replacements. For a project that was originally expected to be sold by the end of the month, I should have had a plan in place for getting all of the final polish in. It would have been hard to ask for finished art when the game itself was nowhere near playable, so it isn’t a total negative, but I could have started a search for artists and composers. At the very least, I could have looked into pre-made art and sound packages. Otherwise, I would be spending a lot of time learning how to create half-way decent art and settling for lame sound effects and no music.

  2. Underestimating the Complexity of the Software Architecture Hacking a game together in a weekend is relatively easy because the code is prototype-quality. It’s meant to be used for a few days, and you don’t need to worry about maintenance or future updates. The future is mere minutes later, and then it is over. For the October Challenge, I wasn’t interested in a single sale. I was interested in the health of my business. When there is one sale, I expect more to come later, and so I wanted to make high-quality software that is easy to provide support for.

    Unfortunately, I didn’t realize until late in the month how little experience I have with creating a full-fledged project from scratch. When all of the code is in a single, monolithic file with almost no external data driving it, it takes no work to determine what data structures should live where. When you’re working on software with flexibility and maintenance in mind, it’s a completely different mindset. Since I didn’t have much in the way of reusable code that was of the quality I desired, I was spending a lot more time working on infrastructure and scaffolding than I expected. I could write an individual piece of code well enough, but I had very little experience with knowing what individual pieces of code I needed to write in the first place.

    Also, with unit testing, the code that “works” would only work in tests, whereas the actual game still needed a number of other parts of the project finished before I could see anything that looked like progress on the screen. It’s good to see the green bar as often as I do, but it’s frustrating that the actual game doesn’t do anything more than it did the week before. I now understand what the stakeholders felt like at my last day job whenever I would say “Yes, I’m making great progress. No, there’s nothing new for you to see yet.” Sometimes you just need to throw something, anything, up on the screen every once in awhile.

  3. Not Being Decisive About What Game I Was Making. Since I wanted the game to be data-driven and scriptable, I thought that the major design work would take place with malleable data rather than rigid code. I wanted multiple game modes, and I had an idea of what each one might include. I thought that there could be single level instances as well as campaigns of levels that tie together somehow. I wanted victory and defeat conditions to be scriptable, but I also wanted some core mechanics to be as well. For instance, while the basic game might provide all of the towers up front for the player with no way to retake a tower that the hero has liberated, a different level configuration could require the player to conquer independent towers first and provide the ability to retake them if they are liberated.

    The problem with the game designer’s “I want it all” approach is that it put a lot of pressure on the programmer to make the software incredibly flexible. Since the designer and the programmer positions are both filled by me, it meant that I was asking a lot of myself. I knew better than to make a game engine that could be any genre, any game, but I didn’t realize that making a Stop That Hero! engine that essentially allowed for endless variety of game modes and mechanics wasn’t any less difficult. While the previous sentence sounds like it should have been self-evident, I didn’t have 20/20 hindsight to help me write it back when this project started. It seemed to be so simple. So long as the game was driven by data and scripts, I could make any mode I wanted.

    At the beginning of the project, I had supposedly made a decision to implement a particular game mode as part of the version 1.0 of the game, but I didn’t want to give up on the flexibility to do any of the others I had thought of. If I really wanted to hit the end of the month deadline, I probably could have pared down the feature requirements list. Flexibility can be retroactively coded in after 1.0 was released. Instead, I gave myself the impossible task of getting everything done and hoping it could be done in time without regard to how long it would take. It’s no wonder the schedule slipped.

  4. Getting Into a Developer Funk. Towards the end of the month, I hit a point where I could not make forward progress no matter how much I wanted to do so. I was second-guessing myself, partly because I probably felt overwhelmed with the architecture work, and partly because I made the mistake of doing research and development on the state of the art for component-based game objects. Basically, I wanted a component-based game object system since it would help me in my quest for a flexible and data-driven game, but I learned a number of competing ideas, and I found that any new code I wanted to write had all of these new mental filters in the way. Data-driven Programming vs Object-oriented Programming, game objects vs game entities, encapsulation vs getting things done, etc. It was a lot to take in, and I had difficulty getting all of the new information to settle down in my head.

    When I finally abandoned my attempt at the component-based system, I still couldn’t make progress on a less flexible entity system. How hard can this be? I did a working version in the original Jam version of the game, right? Well, once again, I wasn’t throwing all variables and data structures in the same class anymore. I couldn’t make decisions because I was paralyzed with the fear that I would make a poor one.

    I experienced a smaller version of this when I was getting into unit testing for the first time. For instance, I’m not used to the need for as much Dependency Injection as I did on test-driven work, and I was losing confidence that I was doing software development “right”. Early in a project, you might think of one reference to an interface that an object needs, so you provide that reference in the constructor of the object. Weeks later, and you might have 4, 5, or 6 such references as parameters, and suddenly you’re faced with the need for another one. At this point, it starts to feel wrong, especially since it can hard to keep it all straight in my head. Since I was working alone, I didn’t feel I had anyone to discuss it with, so I would have to move forward reluctantly. Eventually, the fear that I was doing something wrong paralyzed me.

    I did eventually get out of my funk and started making forward progress again, but it was only after a long phone conversation with a more software architecture-knowledgeable friend. Thanks, Larry! When you think you’re lost, sometimes all you need is some guidance and advice.

What I Learned

  1. How Much Technology I Needed and Didn’t Have. If I didn’t care about making my game available for GNU/Linux or avoiding proprietary solutions, I could probably have used technology such as GameMaker, Unity, or Flash to make a game. They offer plenty of game development-specific support, either directly or through libraries. Instead, I had to do a lot of work myself. While libSDL provided a number of basic hardware abstraction services, I still needed to write a lot more game-specific code.

    Again, I understood I wasn’t writing an end-all, be-all game engine, but I still lacked a repertoire of code to help me make the game. A lot of my time was spent laying down the basic infrastructure to allow me to work on the game. It’s odd since I can easily hack together a working game in a weekend, but when the project’s seriousness demands more, I found that I lacked the basics. While I knew what tools I would use at a fundamental level, such as which compilers and libraries I would use, I didn’t realize I needed to figure out what technology I needed to create. If I did, I probably would have planned for it in the schedule or I would have pursued a simpler project in the first place. For instance, while I knew I needed AI pathfinding, it didn’t occur to me that I’d need something more sophisticated to track all of the objects in my game than a bunch of independent collections of data.

  2. How Much I Still Need to Learn Between software architecture and the basics of game engine requirements, I hit a number of stumbling blocks that forced me to pull books off of shelves and search online for answers. I would have thought I knew enough about game development to make a game, but I had underestimated how much more work there was to take an otherwise working game that was hacked together and writing the code in a way that made it easier to debug, fix, and change.

    Working with others would help us all glean knowledge from each other, but as an indie, I’m going to need to interact with game developers in more than a social way. Also, I need to get better at project estimations. I was too optimistic this time around.

  3. How Difficult It Is To Talk About Game Development When It Is Not a Hack Fest. Most of the people I talked to on IRC were helpful when it came to particular aspects of what I was doing, but they almost all seemed to perceive that I was hampering my efforts with the use of unit tests and the desire for high code quality. “Just finish the game” is easy to say when you’re working on an LD48 competition entry for fun, but when your business depends partly on the ability to provide customer support without introducing bugs and problems, it’s not just fun and games anymore.

    Selling a copy would have been nice at the end of the month, but I also want the ability to sell more copies later. Selling a hard-to-support game isn’t a good way to improve my ability to stay an indie long term. The October Challenge wasn’t an end in itself for me. I saw it as a kick in the pants to get me focused on moving my business forward. By and large, it worked. I have a project that is still moving forward even if it is at a slower rate than I would like. Still, it was difficult at times to talk about game development as a business-related endeavor since not everyone had the same long-term goals.

As I said, I am continuing this project even though the October Challenge is over. Using the project data so far and assuming I continue to work at the same rate, I can expect to finish the game by December. It’s still just an estimate, but it is a much better informed one than the one I made at the beginning of the project. While it is disappointing that I couldn’t finish this project in the month, I am pleased with some things. My schedule helped me make consistent progress, and I have a much better understanding of the game’s design questions since I spent so much time thinking about them before the month started. Still, while I had done a simple technical feasibility assessment, I needed to do a deeper study to realize all of the things I needed for this project. Basically, as much as I tried to plan ahead, there were some things that just weren’t on my radar. I know better now. Besides having done a lot of work for this project that can be reused, future projects should benefit from pursuing a better understanding of their technology requirements.

Categories
Game Design Game Development Geek / Technical

Stop That Hero! Sprite Rendering Questions

In the previous post, I reported that levels could be loaded and rendered. So why isn’t it drawing the towers and chests? The short answer is that I didn’t get to them yet, but in all seriousness, it took a little thinking before I could start.

In the original implementation, almost everything was done in a single file of code. The code to draw a tower was:

pHardwareLayer->renderSprite(towerSpriteName, m_towerLocations.at(towerIndex).first * TILE_WIDTH + WORLD_X_START, m_towerLocations.at(towerIndex).second * TILE_HEIGHT + WORLD_Y_START);

TILE_WIDTH and TILE_HEIGHT were each 16, since each tile was 16×16. WORLD_X_START was 0 since it started drawing from the left side of the screen, and WORLD_Y_START was 87 since the UI was drawn at the top.

So depending on which tower I was drawing, I would get the x and y world map offsets, then multiply them by the tile dimensions, and offset by the top left corner of where the world was being rendered.

Why can’t I do the same thing now? Because I didn’t want to hack out everything in one file. A tower is no longer represented by data strewn across different data structures in the game code. A tower is now its own class. A Tower class has these members:

Point m_position;
std::string m_sprite;
int m_type;
int m_status;

There are more variables associated with monster creation and ownership status, but these are the variables relevant to this post.

The Problem

To draw a Tower, I could use the sprite specified by the name in m_sprite and the coordinates in m_position. The problem is that m_position isn’t screen coordinates. It’s map coordinates.

No problem. I’ll change m_position so that it specifies the screen coordinates.

Except m_position is being used in pathfinding, and it is important that it represents a specific tile in the world.

No problem. I’ll just multiply m_position by the tile dimensions, just like in the original implementation.

Er, but, why should the Tower know anything about the tile dimensions? It should only know about towers. Maybe it knows how large it is in terms of tiles, but why should it know how large a tile is? It doesn’t need to, except when it renders a sprite.

No problem. I’ll provide a second Point variable called m_spritePosition which represents its screen coordinates.

That would probably work for stationary towers, but what happens when I need to render moving entities such as Slimes? Unless the on-screen position is mathematically tied to the entity’s position, I can see those two numbers diverging. I could update both pieces of data each time I update one, but what a pain that would be!

The Solution

Create a Sprite class to encapsulate all of it, and let the Sprite class worry about where to render.

Since towers are now encapsulated in their own class, it makes sense that the way I render them (and almost everything else in the game!) should be encapsulated somewhere. The Tower class no longer has its data members polluted with a bunch of members related to sprite drawing, and it doesn’t need to worry about what to do with that data, making its interface and internals a bit cleaner. Also, Sprite classes can be reused for other objects, such as monsters and treasure chests, in a standard way.

To handle the rendering of images, I created a SpriteImage class with the following members and commented explanation:

Point m_position; // The sprite's position
std::string m_imageName; // Name of the sprite in the sprite collection which stores this particular image.
Rectangle m_imageRect; // What rectangular area in that sprite that holds this particular image
IViewPort * m_viewPort; // Explanation to follow.

At first, this solution doesn’t seem to solve the major problem identified above. It looks like the last problem in that the tower’s position and the tower sprite’s position are stored in two different areas.

The trick is that a Sprite defaults to a 1 to 1 mapping between its position and the screen coordinates, but it’s possible to scale it between arbitrary mappings, too! The secret is in m_viewPort.

If a SpriteImage is given a view port, it will scale its position based on what the view port says the scale should be.

How is this useful? Imagine having an 800×600 screen resolution, and you wanted to render a UI button near the bottom right corner. You could make a SpriteImage of a button at position (700, 500), and it would probably work fine.

But then what if you change the screen resolution to 400×300? It’s possible that you’ll port your game to a mobile device with such a resolution. The button would render off of the viewable screen. You’d have to change the button location manually in order to see it at the bottom right corner again. This goes for every image in the game. It could be tedious and error-prone.

Alternatively, you could use a view port that knows the screen resolution is 800×600, and it could be configured to scale based on a percentage. Now, instead of placing a button at (700, 500), you’d set its position at (87.5%, 83.3%). Then, if the screen resolution changes, you simply change the view port, and any sprites associated with it would know the correct scale to use! It’s very powerful and easy to move elements of the screen by horizontal and vertical percentages.

That’s great for rendering sprites anywhere on the screen, but what about my example above? How does a Tower draw on an arbitrarily-sized and arbitrarily-positioned area of the screen, and how does it know where to do so if its position is based on tile position?

As I said, the view port can do arbitrary mappings. In my case, if the world is made up of 50 tiles x 33 tiles, and the area to render everything is 800×528, and it is offset from the top of the screen by (0,87), how would a sprite use this information? Offsetting is easy so I’ll address it first. Wherever a sprite ends up wanting to render itself after scaling, the view port will tell it to move down the screen 87 pixels. As I said before, I use this offset to give room for the UI at the top.

Scaling is almost exactly as it was at the top of the screen. Mapping 50 tiles to 800 pixels requires multiplying by 16, which is the size of each tile. Similarly, 33 maps to 528 with a factor of 16. So if a Tower is set at (50, 33), its going to render at the bottom of the viewable area, whereas a Tower at (25, 0) would be centered at the top just under the UI. Below is a quick example of how I load level data from tiny PNGs.

Level Data To World Map Rendering

If you click on the image above, you should be able to get a better idea. The level is described in the small PNG that consists of almost all green pixels and a single white pixel in the middle. When this level data gets loaded, what you see on the screen is a lot of grass tiles and a single tower where the white pixel corresponds. While the PNG is 50×33 pixels, the tower renders in the correct location on the 800×528 view port, even though the tower’s location is in terms of the 50×33 level.

And does it work for moving objects? Absolutely! Let’s say I have a Slime monster located at (2, 3) on the world map, which corresponds to (32, 48) on the screen. When a slime moves to the right, I can’t simply change its position to (3, 3). It would jump the entire width of a tile to get there! Slimes are slow. So why not move it in fractional increments? The scaling still works. A slime moved to (2.1, 3) would correspond with the sprite rendering at (33, 48), which is one pixel over. Technically, it would render at (33.6, 48), but fractional pixels don’t make sense, so for purposes of rendering, we can truncate or round it to the nearest integer.

Again, this view port mapping allows me to do spatial logic at an arbitrary level and not worry about the screen resolution. The only thing I would have to worry about is loading a set of sprites that make sense at lower and higher resolutions. Otherwise, sprites would either overlap or have space in between them. This functionality could also be used to render minimaps and allow zooming and panning.

I like this implementation because the sprites don’t need to have any special logic about what they represent. They just need to know what scale and offsets they’re being rendered at. The object that owns the towers knows where it wants them to go, so it can be in charge of the view port. Tower positions can still be used in pathfinding, and the sprites can still render correctly. The only tricky part might be knowing when I’m loading a sprite at the default scale of the screen resolution and when I’m loading one based on a view port’s scale. To render an image centered at the far right of an 800×600 screen, a sprite at (700, 300) makes sense, but it wouldn’t work if the scale settings assume that positions will be specified in percentages. It would be rendered far off to the right by 700 screen lengths! To specify it in percentages using pixels, (700/800, 300/600) would work.

Also, I’m really happy to have a higher-level sprite class. How did I survive so long without one?

Categories
Game Design Game Development

Loading An Arbitrary Stop That Hero! Level

Since last week, I made some significant progress in terms of loading a level for Stop That Hero!. Here’s what renders so far:

Stop That Hero! Level Map

Does this look familiar? Compared to the original game’s finished level, it looks pretty naked:

Stop That Hero! is finished

What’s missing is the rendering of the towers and treasure chests, but otherwise the level is being loaded from the same map data.

In the original game, each individual tile was rendered every frame. This time, when I initialize a level, I load the map data and generate a single surface made up of tiles corresponding to the data. Then, when it is time to render the level, I make a single large blit instead of hundreds of tiny ones. It’s much more efficient.

And it’s also not hard-coded to load the same level each time. Depending on what level you choose, it can load a different map. Right now, that boils down to loading an image just as I did during the original Ludum Dare event and mentioned in My, What a Fancy World You Have There!, but I can easily change it to load meta data in the future. For instance, if I do want to change the game to allow arbitrary level objectives, I would need some configuration file associated with the level, too. For now, I’m assuming every level will use the same game play and differ only in level layout.

The level knows where the towers and treasure chests should go, but at this point, they aren’t rendering. Also, the level provides the hero’s original spawn point, and it knows the difference between a basic tower and the castle as well as the difference between a health chest and a weapon chest.

Categories
Game Design Game Development Marketing/Business

Balancing Current and Future Needs

Related to the fact that I’m having slow project progress on Stop That Hero!, I wanted to expand upon this thought:

I’m using Test-Driven Development on this new version of the game to ensure that bug fixes and game updates are as easy as possible. If a paying customer finds a bug or if I release a new feature, I want to make sure that new code works and that old code doesn’t break.

I also wanted to discuss over-engineering.

Estimated Project Progress

This chart shows my estimated burn down if I was working at the ideal rate of 20 story points per week, assuming my project doesn’t exceed 80 story points.

BurnDown-20

In the last two iterations, I’ve found that I’ve only accomplished 7 and 10 points. Assuming I can continue at 10 points per week, here’s my updated chart:

BurnDown at 10 points per iteration

It might be a bit hard to tell since Google Docs don’t give me much ability to change the axis in these charts, but in the first case, I am well on my way to hitting the October 31st date. In the second case, this project won’t be finished until the end of November.

With Thanksgiving coming and plans to move out of my apartment, November isn’t an ideal development month either, so it’s more likely that it will be December before the game is finished. And what about playtesting and game balancing?

Yeesh. Well, the solution is simple, isn’t it? I just need to do 20 points worth of work each week. Quit being so lazy, Self!

In all seriousness, though, the 20 points was an estimate of the points I could complete each iteration, and that estimate wasn’t based on hard data yet. Two weeks later, armed with some data, I was able to generate a few charts such as the ones above and analyze them.

My Analysis

My original estimates didn’t take into account how much time I’d spend getting the basic infrastructure of the game under test. More importantly, I didn’t specify how data-driven this game would be at the outset.

The more data-driven the game is, the easier it is to modify, configure, and improve. I read that a game such as Age of Empires literally used a database to specify each entity in the game. It allowed designers to modify the database values for various units and see those changes in the game quickly.

The original Stop That Hero! is almost completely code-based. The only data loaded is the level layout, and out of all of the things I could tweak in the game, that level layout was the easiest to change. The level was loaded based on this image file, which is blown up to make it easier to see:

The Tile Map

I could update that image in an art program, then see the update the next time I ran the game. It would have been even faster if I could reload the file on the fly instead of having to restart the game. Still, the point was that it was easy to change the terrain and the location of towers and treasure chests without recompiling the game first.

But what about the enemies in the game? They are all implemented as instances of the same class. In fact, the Hero is just another instance of that class. Couldn’t they be loaded from a file, too? Sure! I could load a file that specifies what sprite to use, the dimensions of the monster, the speed, the strength, and a number of other attributes. If I had done so, I’m sure balancing at the end of the Ludum Dare Jam would have been easier and more effective.

Variables such as enemy stats, resource costs, and chest contents are great to put in configuration files and scripts, but how far do you take it?

Ideally, even game logic could be loaded at run-time. Instead of hard-coding that you win when the Hero has no more lives left, why not make it a specific instance of a Victory Condition? This way, I could create other Victory Conditions for different kinds of game modes. I could make a tutorial level where the Victory Condition involves creating one of each type of monster, for instance.

And speaking of levels, the original game only had one. How do I create multiple levels? I’d have to create some kind of level collection or campaign, and each level might have its own Victory Conditions. And if I’m going to be able to do so much configurable work, I might as well let the players come up with their own mods, too! I wonder how quickly someone would make a Tower Defense game out of Stop That Hero!…

Yes, the more data-driven the game is, the more interesting it could be. Bug fixes, patches, expansion packs, and feature updates can be as simple as adding or changing data, and if code is needed, it should be relatively simple to write.

The thing is, to get to such an ideal data-driven game in the future, I’d have to do a lot of work NOW. Maybe later balancing and game play tweaks and entire rule changes can be easy to implement, but for now, I’d need to lay down a lot of infrastructure.

Infrastructure and Over-engineering

The biggest source of stress for me is the oscillation between wanting to implement just enough of the game to sell a complete copy by October 31st and wanting to implement a game that I can easily update.

Again, October 31st isn’t a hard deadline for my business. It’s a deadline for an inspiring challenge, but missing that deadline isn’t the end of the world. Besides, once the game is finished, there’s still a lot of work to do. Customer support and maintenance are my chief concerns.

If I really want to hit the challenge deadline, I probably can’t make the game very configurable or provide multiple game modes. Still, if it means having a finished game out and selling sooner, maybe lassoing in the scope is a good thing. After all, I could always update the game later with new features, and I can even have the benefit of customer feedback. “Release early, release often.”

On the other hand, I might implement the game in a way that is hard to change. After a weekend of Ludum Dare, I have a rigid, hard-to-change game. If I make this new release fairly rigid as well, what happens when customers complain about bugs? How hard will it be to fix them? I could always add features later, but how much more effort would it require if the code isn’t set up to make it easy?

By taking my time, I could end up with a much better game. It can be slow-baked to perfection instead of being rushed out. It would be easier to configure and mod, and I believe it would result in a much better value proposition for the customer.

Of course, it’s all speculation. It could be that I’m putting in all this effort and over-engineering the implementation for nothing. While it is good to think long-term, what if I don’t need to do everything now? I could forget about creating configurable Victory Conditions and other rules for the moment. If I focus on loading variables from files while assuming that the rules are still the same, I could go a long way.

I think you could only say that something is over-engineered if it anticipated future needs before they became real needs. In this sense, making the game configurable is a real need, and so writing the code to allow it wouldn’t be over-engineering.

But I’d have to make such a need explicit, and I don’t believe I had at the start of the project. Oddly, I felt torn between two different assumptions: I’m releasing at the end of October with as good of a game as I could make by then, and I’m releasing the game only when it full-featured and highly polished. My anxiousness about wanting to develop just enough to release something soon versus wanting to make something with more value was because I hadn’t spent much time on project specifications.

It sounds more formal than it is. Basically, I haven’t decided on exactly what game I’m making, and I was hoping to offload that work to the configurable nature of the engine I’m writing. I wanted to make the game so easy to modify and change that I can experiment quickly and see what works best. While it can ultimately work out really well, it’s a recipe for taking as much time as I am allowed. Of course, I work for myself, so no one is there to hold me to a deadline but me.

A concern is that until I start earning income from paying customers, I’m relying on my savings to live and work. I can’t afford to spend 3 years on a single game, but even spending six months in development would translate into losing a huge chunk of my savings. It’s too risky. On the other hand, I don’t want to try to churn out lots of games in mere days or weeks. I can’t see making anything worth being paid for in that time frame, and spending months releasing poor work isn’t a good use of my time, either.

In the case of Stop That Hero!, releasing it sooner, even with fewer features, is better than spending forever trying to make it perfect. I can always make it perfect with the benefit of customer feedback, and earning any potential income sooner rather than later is a nice bonus, too. B-)

Categories
Game Design Game Development Marketing/Business

Agile Alert: Slow Project Progress

There are less than three weeks left before the Ludum Dare October Challenge ends, and I’m worried.

I’ve been doing weekly iterations on the assumption that I would accomplish about 20 points worth of work each iteration. After the first week, I only did 7 points of work. Not only that, but I added a few points of unforeseen work. Ok, no need to panic yet. I lost some time that first week. I can see how the next week goes. Maybe I’ll do things faster than expected.

Now that Iteration 2 is coming to a close, it looks like the first one: less than half of the work was accomplished, and extra work was found.

Ok, time to panic!

Wait, don’t panic! Part of the benefit of managing the project in an Agile way is to gain some insight into the health of the project. I’m not happy about how slow I’m going, but I am pleased that I can tell that I am going slow so early in the project. Let’s figure out why progress is slower than I’d like it to be.

In three days, I made Stop That Hero! for the Ludum Dare Jam. In two weeks, I’m barely able to draw arbitrary sprites and process input.

Why the difference?

With the Jam version of the game, I hacked it together during the time I didn’t spend eating or sleeping. My current work schedule is less intense. I spend between 4-5 hours a day on game development. Why not more?

Since I work for myself, I have no fixed hours given to me by someone else. In an attempt to give my days some semblance of structure, I’ve decided that certain hours of the day are dedicated to exercise, game development, writing, reading, and organization. I don’t have enough hours in a day to do more game development without taking time from other aspects that I deemed important. Maybe it’s too lax for a newly full-time indie game developer, but I don’t need to force myself into crunch time yet. Besides, any time outside of the scheduled time is mine to do with as I please. If it means that I occasionally have days where I work more hours, all the better. All that said, I don’t believe my work schedule is the culprit here.

As I mentioned in the post on development challenges and concerns, I’m using Test-Driven Development on this new version of the game to ensure that bug fixes and game updates are as easy as possible. If a paying customer finds a bug or if I release a new feature, I want to make sure that new code works and that old code doesn’t break.

Unfortunately, I’m paying up front for it. I’m reasonably confident that the code I’ve written works correctly. I just wish I had more working features!

What I am finding, however, is that the code is easy to use in small pieces. There’s more cohesion and less coupling. Even without explicitly trying, my code is organizing itself in a way that would let me script it more easily. It’s more data-driven, in other words.

But is TDD slowing me down? I have a deadline to sell a game by October 31st. If I can’t get a playable demo of the game completed by next week, this project is in danger of not shipping on time.

On the other hand, October 31st isn’t a hard date for my business. It’s a good target date for a fun challenge and some motivation, but I don’t have sales projections and quarterly revenues depending on it. If I take a few weeks longer to make the game good versus shoveling something out the door, I think I’ll be better for it. As an indie, I have that freedom.

So what’s the solution to my project planning?

The latest issue of Game Developer has a post-mortem about Final Fantasy XIII, and one of the things that went wrong is the development of a “universal engine”. Basically, since Square Enix wanted to create an engine that worked across all the new console hardware for all games in development, they spent a lot of time trying to make sure they accommodated every team’s needs. It wasn’t until they decided to give priority to Final Fantasy XIII over the other games in development that they were able to make good progress.

Similarly, I need to be extra wary of overengineering. With TDD and Agile, I should be implementing only what I need when I need it. You Ain’t Gonna Need It (YAGNI) is the principle I need to follow more closely. I think a big reason for my slowdown is that the things I have coded are a bit more general purpose than I need them to be right now. It will be great to reuse a lot of these features and pieces of code in different games, but it’s not helping THIS game get finished faster.

For instance, I created a basic data-driven menu system as opposed to the relatively hard-coded system I had before with code strewn about here and there in my game. I based the design off of what I read in Game Programming Gems 5. It’s easy to create menus and their buttons, and it can be extended later, and it’s unit tested to boot!

But couldn’t this game have been served by menus that aren’t general purpose? Maybe it wouldn’t be as nice, but it would have been workable and I could have spent more time on the game entities and their interactions. I clearly didn’t learn the lesson from my last post-mortem:

As in previous Ludum Dare compos, I’ve found my biggest problem is deciding where to spend my time and for how long.

I think I should continue to use TDD. It’s helping me design almost naturally-scriptable code, and there are many other benefits. What I need to focus on is finishing the game with the smallest amount of basic features implemented as opposed to spending an inordinate amount of time on any one feature. Otherwise, I’m just creating a game engine for unknown future projects and their unknown requirements.

Categories
Game Design Game Development

Designing Resource Usage in Stop That Hero!

As I mentioned in the post on Stop That Hero!’s development challenges and concerns, the original Ludum Dare implementation has a flaw related to how resources are obtained and used in the game.

Current Implementation

The original implementation works as follows:

  • Assign the player a small starting number of resources.
  • Every so many seconds, increment the player’s resources by a tiny base amount plus a small amount per tower controlled.
  • If a monster kills the hero, increment the player’s resources according to how strong the monster is. The weaker the monster, the more resources obtained. If the hero is killed by a bat, the player is rewarded more than if the hero is killed by a dragon.

Again, I only had so much time to tweak values and work on game balance during the compo. I was trying to prevent the player from using a dominant strategy, spamming the world with dragons right away when the hero was weakest. It’s harder to do now, so I succeeded, but there are a few problems with this setup.

First, it takes forever for the player to gain enough resources to do anything. I had no intention of making the player feel impotent as the hero marches through the world, but when you don’t have enough resources to create even a bat most of the time, it can get quite frustrating and boring. In any given game session, you might create only a handful of monsters, and usually you can’t have them all on the screen at the same time since the hero would have killed some of them by the time you receive enough resources to create another.

Second, as the game session goes on, it gets worse. As the hero conquers towers, the player is getting even fewer resources! Here’s the actual code:

m_numResources += 1 + getNumActiveTowers()/2;

Every 15 seconds (assuming you don’t use the fast mode), you get 1 resource, plus one resource for every two towers you control. In the current game with 7 towers, that means you get a total of 4 resources (the fractional part is ignored) every 15 seconds. It takes one minute to have enough resources to purchase a bat. Every two towers the hero conquers results in the lowering of your puny income by 1, which means you have to wait even longer.

If the hero has conquered all of the towers and is coming for your castle, it would take you almost 4 minutes before you’d have enough resources to create one bat. Even if you did have that much time, which you wouldn’t, you’d lose that bat immediately since the hero would be way too powerful for a bat to bother him anyway. This end game example illustrates the pacing and balance issues more than any other example I can think of. I wish I had thought to do the math on it during the Ludum Dare weekend. I would have realized immediately how badly it was going to work out.

Third, it is disastrous when the hero takes out a tower after you’ve created a monster from it. When the hero takes out a tower, any monsters that originated from it are automatically destroyed. On the one hand, it gives the player an interesting decision to make. Do you create a monster near the hero so you can attack right away, or do you play it safe and wait for the monster to find its way to the hero? On the other hand, imagine creating two dragons at a single tower. That’s 60 resources out in the world depending on that tower to exist. If the hero manages to make it to the tower, boom. Those two dragons are gone. Since the player is getting fewer resources by virtue of losing the tower, it’s even harder to make up those 60. Losing a tower can be a harsh double-whammy.

Alternative Designs

So if the current design isn’t going to cut it, what can I do instead? I’ve come up with a number of options.

  • Mine resources.
  • Each tower produces resources for itself.
  • A tower gains resources based on distance to resource reservoirs.
  • Gain resources from treasure chests that monsters collect and return to tower.
  • Player starts with no towers and conquers them to gain more resources.
  • Collect resources by raiding towns.
  • Gain resources based on each monster in existence.
  • The area around the tower develops like farm land, requiring the player to click on the tower once the crops are ready to collect them as resources.
  • Unlimited resources.

Each option could change the feel of the game in subtle or drastic ways. By creating mines, raidable towns, player-conquerable towers, and treasure chests that monsters could collect, I think there should be a way for the player to tell monsters to go to specific locations. I’m not sure if I like the idea of directing individual monsters, though, and partly because of the UI challenge if the graphics are tiny or if there is a swarm of monsters on the screen.

One of the things I wanted the game to do was mimic what typical games do: the hero encounters weaker enemies at first and stronger enemies later. With the current setup, I couldn’t figure out how to make it easier to create stronger monsters as you lost towers while preventing you from being super powerful at the beginning of the game. If a tower produces resources for itself, it changes the game slightly. The player wouldn’t be able to create monsters at any tower at will. Each tower would indicate what monsters you could afford. Perhaps if towers nearer to the castle gained resources faster than towers further away, it would work how I would like. The first monsters the hero encounters would be weaker since the player couldn’t create anything stronger, and as the session went on, the hero would encounter stronger and stronger resistance since later towers would gain resources faster.

I also like the idea of clicking on the towers to collect resources if only because it becomes a new activity for the player. I’m not sure if it makes sense to combine it with individual tower resource pools versus a single resource pool, though.

And of course, unlimited resources is an option. Just get rid of the concept entirely. I would need to limit monster creation in other ways. Perhaps there is a maintenance limit, so you can only build so many monsters and have to be strategic with which ones you choose. Maybe you can create monsters at any tower, but they take time to summon, and while you’re summoning one, that tower can’t be used to summon another until it is finished.

So as you can see, the nature of the game can change completely depending on how I approach resources.

My Decision

Of course, depending on how scriptable the finished game is, any of these design choices could become a mod or special mode, but in the interest of actually finishing the game anytime soon, I’ll be focusing on one. I’ll wait to see if customers actually like the game before I release an update with scriptable tools.

I think I’ll try a combination of the current setup with the idea of towers gaining resources faster based on their vicinity to the castle. If I can make the monsters weaker and the hero stronger, maybe it will be more fun simply because the player will be able to create many more monsters. Even in the late game, it should be possible to create relatively strong monsters. My design concern then becomes a matter of balance. The player shouldn’t easily kill the hero at the end simply by waiting on built up resources. And I’ll toy with the idea of clicking on ready resources to collect them.