Categories
Game Development Geek / Technical General

Integrating LodePNG with an SDL Project

In efforts to port Stop That Hero! to the Mac, I ran into a strange issue involving PNG image data.

See, the level layout in “Stop That Hero!” is defined by a 50×33 PNG. The colors of pixels in the PNG correspond to tiles and structures in the game. Grass tiles are represented in the PNG as green pixels, water is blue-green, mountains are gray, and so on.

This PNG (blown up since 50×33 is so tiny):

Level 4 PNG

results in this level layout:

Stop That Hero! Bringing evil back...

I use libSDL_image in order to load image formats other than BMP, and on Windows and GNU/Linux, everything works as expected.

On the Mac, however, I was seeing a problem. It was as if most of the tile data was not getting loaded correctly. Instead of seeing grass, fields, forests, and mountains, I was only seeing mountains. And structure data was also not loading correctly. The player’s castle wasn’t appearing either, so the game always ends in defeat.

After ruling out endian issues (Intel-based Macs aren’t going to require any data-parsing changes from Intel-based Windows or GNU/Linux), I found that the pixel colors being returned from a loaded PNG weren’t what I expected.

I expect red-green-blue(RGB) data to be (0, 255, 0) for grass tiles, but the color that I was seeing was slightly different.

And it turned out that I wasn’t alone. A thread on the libSDL mailing list discussed a similar pixel bug on Mac OS X, and it turned out to be related to libSDL_image’s use of Apple’s ImageIO for the backend. I’m still not quite 100% clear on what the actual problem is, but the best I can figure out is that ImageIO tries to helpfully convert the image you’re loading so that it is more optimized for rendering on the specific Mac running the code. It’s not a problem if all you want to do is render images to the screen, but is a problem if you’re depending on the pixel data to be accurately decoded.

Last week a fix was introduced to solve this issue, but as it isn’t in the release version yet, and I didn’t want to convert my data or change how I was doing things, I decided a better way would be to replace libSDL_image in my own code. Thanks to a conversation on Google+, I was introduced to stb_image and LodePNG, both of which are liberally licensed, comprehensive, PNG-handling modules of code. By comprehensive, I mean that unlike libSDL_image, I don’t also have to require zlib. You just drop in a couple of files into your project, and you’re done.

I opted for LodePNG because unlike stb_image, it not only loads PNGs but also saves them, and I want to make sure I don’t have to switch libraries again when I get around to creating a level editor. Also, quite frankly, it was less intimidating than stb_image being a .c file that leaves the production of the associated .h as an exercise for the programmer.

LodePNG had some examples associated with it, and while one example uses libSDL, it wasn’t clear how to load a PNG into an SDL_Surface. The example simply rendered the PNG to the screen. It was not what I wanted, and I could not find any code out on the Internet that used LodePNG and libSDL together.

So, in the interest of filling this gap, here’s how to load a PNG with LodePNG and store it into an SDL_Surface:

SDL_Surface * loadImage(const char * filename)
{
    //Using LodePNG instead of SDL_image because of bug with Mac OS X
    //that prevents PNGs from being loaded without corruption.

    std::vector<unsigned char> image;
    unsigned width, height;
    unsigned error = LodePNG::decode(image, width, height, filename); //load the image file with given filename

    SDL_Surface * surface = 0;
    if (error == 0)
    {
        Uint32 rmask, gmask, bmask, amask;

#if SDL_BYTEORDER == SDL_BIG_ENDIAN
        rmask = 0xff000000;
        gmask = 0x00ff0000;
        bmask = 0x0000ff00;
        amask = 0x000000ff;
#else
        rmask = 0x000000ff;
        gmask = 0x0000ff00;
        bmask = 0x00ff0000;
        amask = 0xff000000;
#endif
        int depth = 32;
        surface = SDL_CreateRGBSurface(SDL_SWSURFACE, width, height, depth, rmask, gmask, bmask, amask);

        // Lock the surface, then store the pixel data.
        SDL_LockSurface(surface);

        unsigned char * pixelPointer = static_cast<unsigned char *>(surface->pixels);
        for (std::vector<unsigned char>::iterator iter = image.begin();
                    iter != image.end();
                    ++iter)
        {
            *pixelPointer = *iter;
            ++pixelPointer;
        }

        SDL_UnlockSurface(surface);

        SDL_Surface * convertedSurface = SDL_DisplayFormatAlpha(surface);
        if (convertedSurface != NULL)
        {
            SDL_FreeSurface(surface);
            surface = convertedSurface;
        }
    }

    return surface;
}

Technically, the piece of code related to convertedSurface isn’t necessary, but SDL_DisplayFormat and SDL_DisplayFormatAlpha convert the surface to one that is optimized for rendering. And it doesn’t modify the pixel data, which means that if you depend on it for map layout or for doing interesting effects at run-time, it just works, like you expected.

Categories
Game Development Marketing/Business Personal Development

Reviewed: 2011; Previewed: Next Year

Welcome to 2012! I hope you enjoy your stay!

How was the last year for you? Mine was a mixed bag.

First, the good:

  • I went to the Game Developers Conference for the first time, meeting and hobnobbing with the best and brightest of the game industry. GDC was a blast!
  • I got engaged on the balcony of Neuschwanstein Castle in Germany while taking a once-in-a-lifetime trip through Europe with her graduate class.
  • On the way back from that trip, I learned I had a new niece. The last time I saw her, she was already starting to walk.
  • In January, I started my term as a new board member of the Association of Software Professionals and ended up becoming the President two months ago.
  • I finished a game for the Ludum Dare #20 Jam in May.
  • I started taking pre-orders for Stop That Hero! at the end of September, and I released the alpha version of the game for sale a few weeks ago.

Now, the bad:

  • I’m probably in worst shape than when I started the year.
  • I missed the IGF deadline.
  • I’m out of money.

While 2010 saw me make the leap into full-time indie game development, 2011 saw me struggle to stay there. My burn rate estimate said I should last through to October using only my savings. Years ago, I bought a few shares of stock, and I had to sell those recently at a loss (Thanks, economy!) to cover my expenses. While I’ve sold a few pre-orders and a couple of alpha versions since its release for Windows and GNU/Linux, Stop That Hero! isn’t finished and won’t likely pay the bills anytime soon. And I still need to find a way to get the Mac port made for the Mac pre-order customers. I feel terrible about not having it made yet. B-(

So in terms of my business, was 2011 a failure? Yes, in the sense that my project was really late and overbudget, ruining any plans and revised plans continually throughout the year. Yes, in the sense that I no longer have my savings to allow me to focus on my business full-time. And yes in the sense that I feel I wasted my opportunity.

But no in the sense that I’m wiser for it all. I got an education without being saddled with student loans, at least.

Now, I learned a lot. Yes, I learned more about the technical details of making games. I gained some valuable, in-the-trenches experience in running a business on a scale I’ve never seen before.

But to be honest, that’s small comfort when I need look into contract work to make ends meet now.

I got a lot of advice throughout the last year. People told me that I was focusing too much on the technology and not enough on the game, that my insistence on making a downloadable game for GNU/Linux was a poor business decision when I should be targeting mobile and web-based platforms, that C++ was a poor language to use, that I should be focused on making quick games to see if one becomes a hit, that, basically, I was doing things wrong. In other words, I was being way too indie for their tastes, that I should be indie their way instead. B-)

It was all good advice, but I ignored most of it. It was my decision. And if I had to do it again, I’m not sure I would have done it differently.

My problems did not come from the technology I used or my target platforms, even though I could have done more to leverage existing libraries and to learn from open source games. My problems were not a matter of not using Flash or Unity, or of insisting on using GNU/Linux as my base development platform. If any of these were problems, they were mere symptoms.

My real problems stemmed from:

  • a lack of experience.
  • a lack of collaboration.
  • being undisciplined in producing results.
  • ignoring cash flow.

That last one sinks more businesses than any other issue. And I KNEW this fact, yet I kept pushing forward to get my game out as soon as I could, figuring that I would stop then to figure out what I was going to do. Every month ending without a released game had me thinking that I just needed a few more days, and a few more days, and the next thing I knew, it was a year later without a released version of the game to show for it.

When my business plan fell apart, I shouldn’t have put off fixing/rewriting it until after the product was finished. It seems obvious as I write this, but I guess my head was buried in my work, and I wanted to have something to show for my efforts. Instead of running a business, I was only focused on trying to make a game. There’s a lot more to running a game development business than game development.

Sadly, the one piece of advice I took to heart was probably the worst. I stopped writing so I could focus more of my time on game development. My writing is one of my biggest strengths and providers of value, and the less I wrote, the less chance I had of gaining an audience, getting feedback, and interacting with other game developers in general. I used to be the orange juice-drinking indie game blogging guy. Now I’m just another obscure struggling indie.

To the future!

So what’s 2012 going to look like?

Honestly, I’m not sure yet. I’m still figuring out my game plan, but here are some major themes.

I’ll be married in a few months. Woo!

Of course, it means it is even more important for me to figure out how to pay the bills. My expenses are already very low, so it is a matter of getting more income, and right now I don’t see how my business is going to provide it. I’m going to be looking for contract work, but I am keeping an eye out for creative funding opportunities.

As a result, I’ll once again have less time than I like for my business, which means I’ll need to make sure that I spend that time wisely. I intend to focus on creating results more rapidly than I have. Perhaps it means collaborating with other developers or using other technologies, but it will mean holding myself to deadlines and focusing on providing value consistently.

And you can bet that I’ll be writing about my progress.

I hope 2012 is prosperous and full of opportunity for you. I’m figuring out my plan to try to make the most of mine. Happy new year!

Categories
Game Development Geek / Technical Linux Game Development Personal Development

Why It Is Important to Document Even the Smallest Decisions

A week or so ago, I was configuring the hero summoning queue for my villages in “Stop That Hero!” (still available for pre-order!), and I couldn’t figure out why I had a special “END_QUEUE” for the last item in my queues. None of my code handled it, so it got ignored, and removing it didn’t change anything adversely that I could see, so I removed it since I couldn’t remember why I put it there in the first place.

Today, while working on a new level layout, I created a village that summoned only one farmer. When play-testing, I found that right when the farmer appears, the game ends in victory for the player.

Premature Victory

That’s odd…why would that happen?

My victory monitoring code checks all entities to see if there are any that are not on the player’s team. If there aren’t, then it checks all structures that summon entities owned by non-player teams to see if they are currently summoning anything. The idea is that at the beginning of the level, when no heroes have been summoned, the game doesn’t end in victory since they’re still coming, and victory only occurs when there are no more heroes being summoned AND there no more heroes left in the level.

The issue I was seeing is that right when a village spawns a farmer, the farmer doesn’t exist yet. It’s simply a new command to create a farmer. But the village no longer has a farmer in its queue and is empty. So the victory condition goes off and creates the end-game-in-victory-for-player command. So that’s why I see the farmer when the victory screen comes up. The farmer gets created and the game ends because both commands are run in the same update step.

And that’s why I had an “END_QUEUE” summon that doesn’t do anything. It’s to prevent this situation from happening. Now I remember. I ran into this issue before. The END_QUEUE summon is ignored, but the victory condition monitor sees that there is still something in the queue. By the time the END_QUEUE is “summoned” and gone, the entity creation should have happened for the previous item in the queue.

It was a stupid abuse of the system that I should have handled better the first time, but I didn’t think much of it. I needed to get things done, so I did the quick solution and promptly forgot about it.

Since I didn’t document what “END_QUEUE” was supposed to do when I came up with it, I spent part of my day trying to figure it out.

So there you go. Document your decisions, no matter how small. In fact, maybe the small decisions are even more important to document than the bigger ones.

Categories
Game Development Games Marketing/Business Personal Development

Getting Used to Accepting Payments

According to my git repository, yesterday was the one-year anniversary of the start of my first major commerical game project, Stop That Hero!.

I’m not celebrating because it’s not a good milestone to hit. I didn’t know how long it would be to take the Ludum Dare #18 prototype and make it into a full commercial-quality game, but I did not expect it to take a year. In fact, when the 2010 Ludum Dare October Challenge was announced, I thought a month sounded like a good time period. If it took three days to prototype the game, surely four weeks would be plenty of time to polish it up and release it.

Tomorrow is October 1st and the 2011 Ludum Dare October Challenge (even though an announcement went out saying that it started already), and I was hoping to have the game released before then. In fact, I thought I would have something released by today, but there were some AI issues I tackled last week that I’m still working on.

But eventually I am going to release my game, and I realized that I have never accepted payments for a video game before. Until last month, I wasn’t even registered with a payment processor.

So last night, I posted a few pre-order forms on the Stop That Hero! website. If you want to get the game when it is released for Windows, Linux, or Mac, you can reserve your copy of the game now.

In posting the pre-order, I realized I made a big step. I had some nervousness, partly because I’m selling a game that isn’t released yet, and partly because I’m asking for payment. I’ve never done it before.

It’s possible that no one will care, that no one will even click on the links to buy, but that’s not the point. The point was that I decided to ask people to do so in the first place.

You can’t make money without asking for it, and I decided that until the game is released, the worst-case is that no one bothers to pay me for it. But if I don’t ask for pre-orders, then there is a 100% chance that I won’t get paid anyway.

I’ve taken a step to change that certainty into a possibility, and it’s one of those moments that makes you feel good to run your own business. I don’t have to accept circumstances. I can take action to change them.

In this case, my game is taking longer than expected to make, and I could decide that it means delaying the possibility of sales until the game is released, but I could also try something to see how it goes. The worst case is that it has no effect, that no one will reserve their copy of the game, but there’s a potential now for a lot of upside.

And now I’ll get back to work. Eventually any pre-orders have to get fulfilled with a real game, and I’d like that to be before the end of another month.

Categories
Game Design Game Development Geek / Technical Linux Game Development

Stop That Hero! Development Summary

The last time I wrote about Stop That Hero! development was in July. Here’s a quick summary of the work I’ve done since then:

Fixed memory bugs

I fixed a number of issues in July, specifically with weird corruption issues that seemed to result from the use of std::vector<bool> which is apparently not a real vector of boolean values. I was easily able to discover where memory leaks were occurring with Valgrind.

Recently, I ran into a bizarre unit test failure when adding code to a module that had nothing to do with the unit test, and I discovered that I had introduced a bunch of memory leaks that were finally manifesting in such issues. It wasn’t hard to fix since I once again was able to use Valgrind, but it was tedious work. A lot of it was fixing dumb mistakes, too. I have no idea why I thought I could get away with the code I wrote when I wrote it.

Unless there are corruption problems, memory bugs are not usually a big deal during development. Still, it would be nice if I used tools that made it easier to avoid the problems in the first place. I use UnitTest++, but these memory leak issues would have been caught had I used a tool such as CPPUTest which fails tests if memory leaks.

Added more minions, entities, and projectiles

Once I made combat revolve around projectiles, I added fireball-launching dragons and warlocks. Warlocks will eventually have a magic spell they cast, but they launch fireballs because that was the only projectile I had at the time.

Recently, I added new heroes. Archers shoot arrows, and wizards cast lightning bolts. I eventually want to add villagers and knights and get rid of the generic Hero character.

More Heroes Added

Optimized rendering

I’ve had the same update/rendering code for a long time, and on a whim, I added some logging to my game to find out why I wasn’t able to get 60 FPS even though I didn’t think I was doing much.

It turned out, I wasn’t doing much. All of my code ran within a millisecond, but the actual SDL call that blits to the window took between 30-50 ms to run! The good news is that my own code isn’t slowing me down, but mathematically it’s impossible that SDL MUST render this slow since so many other SDL games run much faster. So I looked to find out what other people did to make it work.

Here’s the code I was using to set the video mode:
m_screen = sdlInstance->SDL_SetVideoMode(m_x, m_y, m_bitDepth, SDL_DOUBLEBUF);

And here’s a much faster version based on a thead at Ubuntu Forums that I apparently did not bookmark:
m_screen = sdlInstance->SDL_SetVideoMode(m_x, m_y, m_bitDepth, SDL_SWSURFACE | SDL_ASYNCBLIT | SDL_DOUBLEBUF | SDL_ANYFORMAT | SDL_SRCALPHA);

So I went from 30-50 ms to 8 ms. The game runs so much more smoothly now, and it didn’t take a lot of work at all.

Switched away from pie menu

Pie menus are great for usability, but only if you can guarantee that the menu can be displayed in its entirety around the mouse cursor. Since one goal with “Stop That Hero!” was to make the interface as simple as possible, I didn’t want a scrolling world. The entire world fits on the screen at once. To use pie menus, I’d have to reduce the world size to provide a border all so that buttons could fit on the screen if a tower was selected near the edges.

So I removed the pie menu and went back to a traditional UI at the top of the screen.

Added resources and minion costs

Before, I was adding minions to the game whenever I wanted. Now there are resource costs, and it takes time to summon a minion from a tower. The player starts with a base set of resources, and the current system adds 1 resource every second. It’s simple, and it works. I can experiment with resource mechanics, such as adding rewards for killing heroes or if certain minions collect items and bring them back to the player’s castle, but the basic system is in place.

Made object creation more generic/data driven

I initially tried to make the game as quickly as possible, so instead of trying to genericize object creation, I created a bunch of separate commands: CreateHeroCommand, CreateDragonCommand, CreateOrcCommand, etc.

While it worked, it was also very limiting. Each time I added a new type of entity or in-game object, I had to create a new command. Maybe that’s fine if I know what entities and objects I want to create up front, but it limits the design. Maybe I want to make weak squires, regular soldiers, and strong knights as variations on each other. The effort to write the code for the separate creation commands would be tedious and slow.

So I replaced all of those CreateXYZCommands with CreateObjectFromTemplate. Instead of having coded commands to create an orc, I create a template called Orc, which defines components and data that an orc would have. CreateObjectFromTemplate(“Orc”) then creates the components with the correct data, and an orc appears in the game world.

Templates can be created and changed much more easily than hardcoded commands, which means adding and tweaking minions, heroes, and other in-game objects is easier, which means game design and balancing is easier. It also allows me to data-drive the game a lot more, which means more interesting entities and game situations.

Added timer-based summoning queues

Both heroes and minions take time to appear. Minions are summoned and there is a summoning bar that lets you know how finished the current summon is. By using the same summoning queue code, I now have a Village which pops out heroes over time.

Timers seemed like a special case of general triggers. It would be nice to have dwarves pop out of caves if any entities come near or have other similar scripting in the game, but my initial attempt at general triggers might have been trying to do too much. Maybe for another game.

What’s Next?

The game is still silent, so eventually I would like to add some sound effects and music. Animations and special effects would really punch up the visuals, which need a consistent art direction. It’s all functional programmer art and will get replaced.

But the biggest thing left to do is improve the AI. Dragons can attack from distance, yet they still try to run up to the heroes the way melee fighters do. Also, entities tend to bunch up. 10 orcs attacking a hero tend to look like a single orc attacking the hero, and it is hard to see what’s happening.

My initial attempt at solving these problems resulted in unacceptable slowness last week, but I’ve identified what’s going on and think I have a fix for it.

But hey, this is AI work. I already know I can’t expect that I’ll figure it out in a matter of hours or days. There’s going to be a lot of changes, tweaks, and fixes until it looks right.

And besides game development work, there’s the work of marketing and selling the game. There’s a “Stop That Hero!” Facebook page, and I just sent out a newsletter to my list announcing the upcoming release. I’m hoping to get a pre-alpha release out soon.

Categories
Game Development Games Geek / Technical

See Stop That Hero! in Chicago

Indie City Games is hosting the Open House Indie Games Expo in Chicago this Saturday.

Members of the general games-playing public are invited to show up, meet local indie developers, and play the games they’ve been hard at work creating. It’s fun, it’s free, and absolutely everyone is invited!

I’ll be demoing Stop That Hero! for the first time in public.

When? 1PM – 4PM, Saturday August 20th, 2011
Where? 243 S. Wabash Ave Room 924


View Larger Map

Do you plan on attending?

Categories
Game Design Game Development Geek / Technical

Meaningful Game Play Game Jam

Josh Larson of God At Play wrote about meaningful game play. Josh’s definition:

Meaningful game: a game that has significance or provides purpose for how one lives life.

He specifically argues that there seems to be a lack of games with deeper meaning, and that there are not enough of them to satisfy the people who want to play deeper, more meaningful games. He identified the difficulty a game designer has when setting out to make a meaningful game. Where does one begin? Have there been attempts before? It’s hard to know what works and what doesn’t without actually doing it yourself because body of work available to build on is scarce.

His suggestion is that there should be game jams dedicated to Meaningful Game Play, where such experiments can be prototyped and critically analyzed. The goal would be to create a resource for game designers who wish to develop deeper, more meaningful games.

The first Meaningful Game Play Game Jam starts today at the BitMethod offices in Des Moines, IA. Details can be found at the newly launched Meaningful Gameplay website.

I’ll be there. Do you plan on attending? Do you want to participate in a Meaningful Game Play Game Jam?

Categories
Game Design Game Development Marketing/Business

Should Indies Make Bigger Games?

I’ve been participating in the Indie Indie Conversation on YouTube with other full-time indie game developers. We upload 3 minute videos at a time (although some are a bit longer) and have a discussion about all sorts of topics related to being an indie, such as technical struggles, the need to explicitly make time for social interaction, and meaningful game play.

Recently, there has been some talk about financial concerns. Andy Moore of Steambirds fame has talked about his recent return to full-time indie status, but his lack of contract work was not his choice, and the lack of a safety net is made worse by the lack of a current project. Mike Hommel chimed in saying that his last project was a flop and lost him money, and he’s going to have to make some games for Flash Game Licensing to make a bit of cash. In the end, he got a new business deal, so good for him, but the turn this conversation took bothered me.

So I made this video:

Now, keep in mind, I write way better than I speak. To clarify, I don’t want to say that Flash games are necessarily dinky little things that get churned out with no soul. My impression of the attitudes of some indies, however, is that spending time on a game to make it great rather than merely good is spending too much time on a single project.

How much value can you really provide your customers if you spent only a few weeks on your game? Chris Hecker’s 2010 GDC rant Please Finish Your Game talks about the idea that a lot of games are prematurely “finished” by indies. That is, they are put out there, and there’s no follow-up or follow-through.

Yes, it is important to get feedback as your game iteratively develops, and releasing early and often is great for getting that feedback and helping you see what direction to take. But it’s not as if indies are putting together epic games and dropping development as soon as they see that there is no audience, or at least that’s not my impression. They just aren’t trying to make bigger games, and apparently they think they’re being rewarded enough for the smaller games.

So are big games inappropriate for developers who aren’t Mojang? Is it too financially risky to make something deeper for players to enjoy, or is it the exact right way that we should be making games? Did you quit your day job to be mediocre, or do you want to meet your potential, even if it is a bit riskier?

Categories
Game Design Game Development Geek / Technical

A Summary of Recent Stop That Hero! Developments

It’s been a long time since I blogged about anything, and any “Stop That Hero!” posts were sparse, so let me update you on what I’ve been doing over the last couple of months.

When I made the original Ludum Dare #18 entry, I had just finished reading through two AI books: AI for Game Developers and Artificial Intelligence for Games, Second Edition. My LD version of “Stop That Hero!” was the proving ground for what I learned. Three days of “why won’t this work?!” frustration concluded with everything coming together, and I was proud of it.

As I worked on the full version of the game, I found that one of the struggles I’ve had with STH! is with regards to software architecture. The entity AI was especially unintuitive to work with because I had written a bunch of disparate systems that weren’t aware of each other but depended on all of them working together.

The Movement system assumed that the MovementComponent had its direction set correctly and moved the entity’s position according to its speed. The Targeting system would find the nearest targetable object. And the Pathfinding system would find a path to that targetable object. Now, they sound like they work together fine, and for those three responsibilies (movement, targeting, and pathfinding), they were great.

But path following was the responsibility of the pathfinding system, which updated an entity’s MovementComponent’s direction based on where the next node in the path was. Targeting was a bit weird, too. For example, the Hero targets treasure chests, castles, and towers. In the above system, the Hero would go towards the nearest targetable object, which means he’d pick up health even if he didn’t need it simply because he was closer to it than anything else, and I had no way to change it easily.

Part of the problem is my inexperience with creating AI systems. Another part is my inexperience with component-based systems. And a third part was my inexperience with software architecture in general.

Months ago, someone suggested I read Programming Game AI by Example by Mat Buckland. What this book had over the other two books I mentioned was actual working code and examples to read through. If you’re new to game AI, I would highly recommend Buckland’s book.

After reading through it and the source code, I rearchitected the AI of my game. Now instead of having disparate systems that somehow work together, making tweaks and changes unintuitive and hard, I have goal-driven agents. Entities have a Brain component, and different Brains have different kinds of goal evaluations. A sword-wielding hero, for example, might decide between conquering the nearest tower, going for the nearest health, or fighting the target enemy, and those decisions will depend on the health of the hero, the distance to a tower, and how strong the enemy is. A slime might be a simpleton and will merely try to reach its target enemy. A warlock might try to keep some distance from his enemy while staying within range to fire magic bolts or do whatever else warlocks do. And so on.

As you can see, changing the AI of an entity is much easier and intuitive with Buckland’s goal-driven agents. I understand that it is not the state-of-the-art in game AI, but it is way better than what I had, it is good enough for this project, and it wasn’t that hard to implement. The hard part is writing the code for the different goals and goal evaluators, which is more tedious than difficult.

As for other updates, I added the concept of teams to make conquering and fighting easier to manage. I was very unhappy with how the Targeting component was being abused in figuring out if a hero was at a tower or if enemies were within range of each other. I had envisioned levels where the player isn’t fighting against heroes but other villains. Slimes should be able to target slimes from another team, but before I added a Team component, there was no way to know.

In May, I added combat mechanics and death. Granted, I already showed a video of combat mechanics in action, but still. Weapons are implemented as projectiles for simplicity. If I want melee attacks, I’ll just set the range to be a short distance.

And since I was having trouble telling if the attacks were doing anything unless the target died, I added little health bars to provide feedback. When an entity’s health drops to 0, it dies. As in the original prototype, the hero has 3 lives (after all, all video game heroes have 3 lives), but I’m rethinking that idea based on a lot of other ideas I have for the game.

Originally, I was thinking about having melee attacks only, but when I added slime trails, projectiles made sense, and at that point, I realized that melee attacks can be implemented as projectiles. Yay, simplicity!

Also, yay, feature creep? Every feature that gets added means more time is needed to make the game. Isn’t it a bit late to make such a fundamental change to the game? The project is already way, way behind the original schedule. Why make it harder to ship?

Here’s my take: I’m less interested in shipping as fast as I can and more interested in shipping a fun, compelling game. By adding projectiles and slime trails, I’ve made the game noticeably more interesting.

Frankly, the game needed more interesting things to do. Since starting the project in October, it is only recently that I’ve done so much work specifically on experimenting with the game design as opposed to putting in scaffolding. Yes, I’ll be the first to admit that I took way too long to get to this point, but I woefully underestimated the technical requirements and did not have a full understanding of the scope of the project when I started.

All that said, in preparation for the launch of the game, I created a website for it. Go to StopThatHero.com, subscribe to the free email newsletter, and Like the Stop That Hero! Facebook page.

The website is not polished yet, but then again, neither is the game. There is a development blog where I will talk about STH!-specific work, and I’ll use the main blog here to talk about my business or anything else as before.

And now, I’ll disappear into my work again. There’s more that I haven’t mentioned above, but I will say that I’ve been redoing a bit of the front-end work in my attempt to separate the GUI from the actual game logic. While it might sound like I’m trying to do things “right” instead of “good enough for game dev”, I found that the separation is already making it much easier to move forward. Like I said, I’ve been weak in software architecture. I think other game developers assume I know more about how to hack something out that works well enough, but the truth is, the more I try to slap something together in the interest of going fast, the more I end up painting myself into corners. So I’ve been reading up on GUI architectures and reading through code to see how others handle it, and it’s been eye-opening.

Categories
Game Design Game Development Geek / Technical Linux Game Development

Stop That Hero! Dev Video: Slimes Throw Chests??

It’s really exciting when I add a feature to Stop That Hero! that I can actually show to someone, and in the last week or so, I’ve added two.

First, slime monsters now leave behind a slime trail. If the Hero steps in the slime trail, he is slowed down temporarily. The slime trail and the slow effect both wear off eventually.

Second, to actually take advantage of the slime trail’s slowing effect, I added projectile weapons. The idea is that the player will strategically send out slimes ahead of stone-throwing orcs or fireball-launching dragons. Their weapons should be more effective against a slowed Hero since they have more time to attack more often.

Once I changed attacks in the combat system to be projectiles, a quick test was to take an existing entity in the game and change its weapon configuration. Since I only had Heroes and slimes, I gave slimes the ability to throw a projectile at the Hero. Instead of attacking from one tile away, they can now attack from 10 tiles away. And to give the projectile an image, I used an existing sprite rather than spend time making something that looks good.

So for this test, it is the Hero versus treasure chest-throwing slimes!

The development video below is a demonstration of the results. Please excuse the lame art. I’m focusing more on the game mechanics/dynamics and less on the aesthetics for now.

I’m pleased to say that it only takes a handful of slimes to defeat the Hero instead of requiring a small army. While it means that my test worked as expected, it also means I’ll need to make some of the Heroes more powerful once I create some orcs or dragons, who should be stronger than the slimes.