After making Minerbot, I started thinking of improvements for Minerbot as it was, but those never got anywhere.

Then I made Secretnet for another Mini Ludum Dare compo. Did great (by my standards), also deserving a sequel. But I started my summer internship and didn’t get much done.

Now, much later, I’m in college. Right now Minerbot 2 is slightly ahead, and I’m focusing what little effort I have on it. It took me a while to decide on this–my few fans on Kongregate push for both sequels just about equally, it seems. Finally I decided on Minerbot 2 because it would (hopefully) not require as much polished content as Secretnet 2.

A screenshot of the current version, just for kicks.

Heading into finals week soon, so I don’t expect to get any work done in the immediate future. However, I do think I’ll get some stuff done during winter break.

I also might post a little feature addition list for Minerbot 2 before then.

And congratulations to everyone else who participated, too! Fun times.

Now I plan on re-releasing Secretnet onto Kongregate, after a few tweaks. Instead of being all secretive about it though, here’s a list of what I plan on adding:

• Log-viewing upon a loss. Someone requested this, so I asked myself “why not?” and started implementing it. Now I can answer “because programming a proper scroll bar isn’t as trivial as I thought.”
• A little ambient music in the background. I might not actually do this, but it’s a goal.
• Integrate the Kong API. Doesn’t really affect the game, but lets the Kong people add badges if they like the game enough. That would be nice.

(This list also an attempt to make you less angry at me for being secretive about my next non-Minerbot 2 game.)

If you have been unfortunate enough to have not played Secretnet yet, you can find it here.

This one, the Mini Ludum Dare #27, had the theme of all talk, as well as a phrase that was suggested be included in each game: “I think we can work something out…”

So, I made Secretnet. It’s an adventure game that takes place inside a fake IRC client. It’s short, so instead of writing a description that would likely take longer for you to read than to play the game, I’ll just give you a link to the competition entry page:

(Click on the image. Or here. I made the text a link because people usually look for text links and assume image links go to bigger versions of images. Anyway, just click one or the other, and you’ll be fine.)

Now I’ll get back to work on Minerbot 2.

First off, Minerbot was a bigger success than I thought it would be. It’s a shame nobody took the chance to sponsor it–too bad. Thanks to this game, I was able to earn enough money on Kongregate to finally receive it a month after the end of this month.

After the break, information about the sequel.

Now I thought I’d list a few things that I (and others, thanks commenters) thought Minerbot did well:

• Offer a sense of exploration when digging through the world.
• Let the player make bets, and reveal the reward effectively.
• Use simplistic graphics to display the world.
• Allow the player to dig through and modify the environment.

The easier part is pointing out areas where Minerbot faltered:

• Gameplay is very repetitive.
• There it little to no challenge when playing the game.
• If you play well, the map is clear of ore by the end, making it solely up to chance.
• Graphics are impossible to interpret if colorblind.
• There is no reason to play the game other than high scores.
• Progression and advancement aren’t present in any form except player skill, which increases very rapidly to a shallow peak.
• The world is somewhat small.

When making the sequel, first of all I thought of upgrades. I knew I wanted to put these in even before I released Minerbot originally, but I knew it would take too much time to massage the Minerbot code to let me do that.

Upgrades are a staple of Flash gaming, in my mind. Here, just four examples of games I’ve played recently that use this tactic:

A few screenshots of games that have upgrades. These are just the first four I found--there are many, many more.

• Short play sessions, where you only go through the cycle a few times.
• Intuitive save points. If you quit before a “play” stage is completed, you can expect to lose your progress, although because play stages can be short saving still happens comfortably often.
• A simple way to implement progression in the game.
• Retain players. They have something to come back for to keep working on.

This is perfect for Minerbot. The worlds can be short, and upgrades are natural to the genre. Upgrades are a perfect fit.

I’ll also add in some new upgradeable items, of course, to add more to the mix. More about that later.

• A change in setting
• New character art and capabilities
• A storyline

Here’s hoping that the sequel will be of much higher quality than the original!

(Hehe, bulleted lists are fun.)

Have fun!

It’s finally back up on FlashGameLicense, up for bidding. Unless you have a game on FGL yourself, you won’t be able to use this link, but here it is just in case: Minerbot.

It has been a long time in development, but it’s finally finished. I can’t think of anything I didn’t improve since the last time I posted a link to the game publicly.

Let’s see, what have I done…. Tutorial’s improved, graphics are improved in all modes, Minerbots have a radar and dig faster, the high score table uses an actual database, and a few submission bugs were fixed. More, too, I’m sure, but these are the things that come to mind.

Minerbot single-player

Now I can think about the future of this game. Many suggestions have been made. What I’m leaning towards is a huge-world campaign mode that uses the popular “level -> upgrade screen -> level” gameplay pattern. I’ll need to implement more challenge, too–there’s hardly any of that in the current game.

It amazes me what the Ludum Dare can do. I never would have began this game without it.

Title screen of 0xC0A57ED's old Flash version, back from the minild.

First thing I did was rename it Coaster. It seemed that few people understood that 0xC0A57ED was “Coasted”, so it was easiest for me just to change it. I downloaded a bunch of stuff, did a bit of reading, and suddenly, it was working!

This is Coaster, running on the emulator!

Then I worked in a few new features, such as local high scores for each difficulty and a timer.

When I was done, I signed it (a very simply process, following a tutorial) and submitted it. Coaster was accepted without a hitch, and now I’m just waiting to hear about the free PlayBook offer from RIM.

Even though there was a lot of fuss over PlayBook development, it worked out really well for me, at least.

(Coaster is a free action game for the PlayBook, and will be available through App World.)

AGP, now Minerbot: In the very last stage of development. My tutorial has been long overdue for a redo, and that redo is exactly what I’m trying to effect right now. It’s going to go back up for sponsorship on FlashGameLicense.com (as I was unable to get a response from Kongregate’s sponsorship email address). After that, it all depends on the sponsor(s).

Mystery of Yrevoc Sid: I immediately dove for a graphical overhaul, but the matrix math became frustrating. The way to fix it all is somewhat obvious, but it’s hard to tell how efficient my solution is. Thinking about jumping for opengl at this point for the guaranteed graphical acceleration and workable matrix stack.

0xC0A57ED: Finished in a plane-flight-infused weekend, alongside an EVPI. A simple arcade game made for MiniLD 23.

Danger Love (working title): I really just refer to this as “the game I made for the last minild” as it is very unfinished. Currently features some strange dialog and buggy levels past number 2. Made for MiniLD 24, but I didn’t have enough time to finish it (more EVPIs).

If I forgot any other projects I was working on, chances are I’m not actively working on them anymore. (Not that I’m able to work on these very actively, EVPIs and all.)

However, I have an idea for a new project I’d like to add.

I have no name for this project yet, but the idea has been brewing in my mind for a while. Before I get into the technical details, a brief overview of the game: Space Station 13 plus Minecraft plus more beneficial player interaction. If you haven’t played Minecraft… I suggest you go do so. If you haven’t played Space Station 13, I don’t really suggest it. Instead, I’ll explain what I find so compelling about it.

If you have played Space Station 13 before, you can probably skip this paragraph. Space Station 13 (SS13) is unique for many reasons. First is sheer possibility. A good example is the range of the toolset. Screwdrivers, crowbars, wire cutters, fire hydrants, flashlights, welding torches, and wrenches–these are just a fraction of the devices available. Every tool has one or more purposes; so many things can be accomplished. Whole new rooms can even be added to the station. On top of that, SS13 offers many professions, from detective to the station’s AI. Even the seemingly trivial job of gardener holds deep secrets. Now, to round it out and top it off, SS13 has a round system. This helps players experience a range of jobs, and introduces the most important element of SS13: chaos and general silliness. Frequent station destruction translates to less inhibition of destructive influences, meaning bombs, murders, and weirdness becomes the norm.

What I hope to do is blend the sheer possibility (frequent updates, much content) with professions and a round system. Then, I inject the Minecraft, making it 3d and possibly inviting more constructive work than the usual SS13 mentality.

For this project I think an entity system would be a great fit. I would need to create a bunch of potentially very strange objects, something entity systems are very good at.

Now I’ve just got to get past these EVPIs.

First of all, I renamed it Minerbot. After someone on the #ludumdare IRC channel pointed out that “A Greedy Profession” was unwieldy, I had to agree. I’ve been shortening it to AGP forever, and in my opinion, my game isn’t cool enough to be called by an acronym. WoW, CoD, etc. are able to get away with it because they’re really well-known. If I say “AGP” to anyone, it either means nothing or (to the technologically-inclined) a type of motherboard expansion slot. Therefore, Minerbot.

Secondly, I gave up on the big graphics overhaul, but I still made some neat additions in this area. A little more glow, a lot more font, and an overlaid pattern to give it some texture. I think it helps.

What I was first trying to do was add graphics everywhere–on the tiles, on the miner, on everything. It didn’t work, for technical and gameplay reasons. (I had to zoom in to make the textures possible, yet this made the game difficult for those who were used to it as a full-view game.) This brief foray caused frustration and anger, and delayed the game until recently. Next time, I’m adding graphical capability first.

I also started to use Kongregate’s API for high scores and statistics. Obviously, this means I plan on putting it there. And hopefully soon.

(In the Ludum Dare competition you are allowed to have some code ready, as long as you release it to the other competitors, ideally so that they can use it for the competition themselves if they want to.)

It’s not that an entity system wasn’t the way to go for Yrevoc Sid (I actually picked this game idea out of a couple I had because it seemed like a good fit), but that my basecode just wasn’t done. I had finals the week leading up to the LD, and a generous estimate is that 50% of the framework was in place. I was able to create entities, components, and systems, but the ability to delete any of these things was eerily not present.

I only realized this halfway through Saturday, when I was making bullets. First I tried working around the problem (wasting time in the process) but I eventually just temporarily fixed the ES by just setting deleted entities to null.

Regarding basecode, I have learned that if you’re ever working on the basecode 3 minutes before the competition starts, you should abandon the code. It’s not worth it to use half-finished ES basecode when you could code a traditional OO game much more easily.

To see my code for the ES, you can go to the page linked to at the start of the article and download the source. Although I wouldn’t recommend using it or trying to gain any useful information by looking at it–I don’t think it’s a very good ES.

So, how would I make my next entity system more useful? Here are some criteria I thought about during the compo:

• Entity systems should be used in an uncoupled fashion. This one is fairly obvious, and I think is a strength of entity systems.
• There are Systems and Components, although this relationship does not need to be 1:1.
• Any code that uses components or entities should be a System.
• When in doubt, create a new component. Don’t assume the existence of a property on all entities with this component.
• Similar to the last point, check components before using them. If an Entity is created with position but no mass, the ES should not break by thinking position necessitates mass.

While implementations maywill vary, a few more technical details about what I personally plan to do:

• Make pointers to all components before using them. I started doing this later in my project and it all got so much easier. p.x or p->x for x position is much easier than e.getComponent(Position.class).x or equivalent.
• After making these pointers, make sure the components really exist! I had my getComponent method return null if the entity doesn’t have it, so if I was iterating through an array I just checked for null and continue;’d if it wasn’t there.
• Avoid duplication of code. While my project still compiled and ran when the “Health” component doesn’t exist, it took me a while to find out (without any debugging tools) that while I had defined the class, I didn’t actually create the table to hold these components.

In all, even though my project using an ES dramatically failed in terms of completion, I think it’s a good idea to continue in this methodology.

I’m planning on continuing Mystery of Yrevoc Sid, using what I have learned. I have hopes that after I refactor everything to fit what I have discussed earlier, I can more easily make it networked.

More to come.