Viridian Games

So what exactly is DaisyMoon?

DaisyMoon is a fairly complete black-box game engine produced by Oxeye Games as their internal engine. It’s a Lua-based extension of Daisy, which was their previous engine. All of Oxeye’s game-specific code for a DaisyMoon game is written in Lua.

You can view the official wiki for DaisyMoon here, and even download the latest version here. Unfortunately, the docs in the wiki are incomplete – most pages have lots of red entries, signifying that there’s no associated explanation for the at function.

Fortunately, you have four very different games with the full Lua source code avaiable: HouseGlobe, FillAuth, Because It’s Fun, Fay, and Horror Tactics.

About the only thing DaisyMoon doesn’t do is 3D, but I don’t really need that for Zeta. Hopefully between the solid engine and copious code swiping I can get Zeta up and running quickly.

And now for another twist – I’m not going to just blog this, I’m going to video blog it. Every Friday I’ll have a video up on YouTube talking about what I got done on Zeta and what I learned about DaisyMoon.

Should be fun.

So why haven’t I started on Zeta?

I could hem and haw, but the truth is that I haven’t started because of the Oxeye guys. It’s all their fault. Since encountering the amazing stuff they did in a short period of time for a competition, I have become thoroughly dissatisfied with my own game framework. It’s time for a revamp…if I can make myself feel up to it.

So what does it need?

Cleaner layout. The display code in particular is pretty awful. Not only do I not have a scene graph, but things don’t even draw in the order they are passed in because I haven’t implemented an IDrawable interface class. Right now polys draw first, particles draw second, sprites draw third and lines draw last. That’s sufficient for Planitia, but it’s just not going to cut it for anything more complex. I also need to abstract a lot about the drawing code to make it easier to throw objects at the renderer.

Second thing, UI code. Ugh. Not only am I missing lots of necessary UI widgets (like text input boxes), but my UIs are laid out using a custom text format when they should obviously be using XML.

Third, scripting. Again, a custom language. Here I’m torn. Lua is so popular these days (the Oxeye guys use it and all World of Warcraft mods are written in it), but we’re actually using Python at work. In the end, I’ve used both and they aren’t that different (they are both scripting languages in the end) so it probably wouldn’t be hard to convert between them. So I think I’ll integrate Python, since it’s more directly related to my job.

Fourth, performance information. I have a very basic profiler that I stole out of Game Programming Gems 1, it needs to be seriously revamped. I like the colored bars I’ve seen on a lot of games in development where the length of the bar denotes how long it took the last frame to render and the colors on the bar tell you which subsystems took the most time.

Plus, we need smart pointers. Yes, I know, I should already have smart pointer integration. All I can say is that it wasn’t a priority when I started coding up my little 3D terrain demo three years ago. I’ll probably use boost:shared_ptr, although the last time I tried to download and integrate boost it was a complete pain in the butt.

But that’s not all, of course, because we haven’t even talked about tools yet.

The two biggest tools that I absolutely must have are a GUI editor and a 2D map editor. These will both probably be written in C#. A 3D map editor would be fantastic but it’ll go on the back burner.

So what do I like in my code?

States and events. I think I handled this pretty well. States are black boxes, and they have OnEnter() and OnExit() methods so that I can do things like animate GUIs for a state. I can also have multiple states running at once, or “pushed” states that run exclusively until they are “popped” (think about pressing ESC to get the main menu of a game – usually this causes all other activity in the program to stop until the main menu is cleared).

The event system is abstracted and works well, though it needs more event types and the types it does have could probably use some cleaning.

Networking. Works okay but way too much “raw” code. Need to wrap that up into easier-to-use functions and debug some stuff. But networking works with the events to create a system that stays in sync well, at least on a LAN.

Text handling. This may seem silly but I think text and fonts are a really low priority for most game programmers. My system can return metrics for a string, thus allowing things like centering the text and word-wrapping that works correctly even if the text in the string changes later. It also supports drop shadows, transparency and colored text. I use bitmap fonts because I don’t want to depend on system fonts since I’ll eventually want to go cross-platform.

Now do you see why I haven’t started on Zeta yet? I basically need to write a new framework to replace my existing one before I can write any more games. Yes, that framework will make making games so much eaiser, but…

Ah, well. Now that I’ve made the list, I don’t think I can help but follow it.

The more I look at that Wizard code I wrote the less appealing it is. Once again, it’s very one-offish and will require a fair bit of work to get up to snuff.

Once again, I will try my best to split my time evenly between engine construction and content creation. So here’s how I plan to spend the “engine construction” half of my time.

* Fix various bugs in the current platforming mechanics of Wizard. Right now you can fall right through platforms if you’re going fast enough, the character only has one hit detection point (middle of the feet) and for some reason climbing up ladders and ropes is slow. All this needs to be fixed, and there are lots of resources out there to help me, one of which is JNRDev.

* Hack the world editor for Inaria to become a level editor for Zeta. Get Zeta’s code loading those levels.

* Put in combat code so things can shoot at each other.

* Add a conversation system so we can do plot. (This will be stolen wholesale from Planitia.)

Seems doable in 20 hours.

On the content side:

* Make at least one 64×64 map. Since the tiles will be 8×8 in Zeta that means more of the map will be visible at once in Zeta, thus leading to the feeling of a smaller space. Thus, more than one map would be a good idea, but we must get one in; and it must have obstacles that require new powers to overcome (again, without this it’s not a Metroidvania).

* Create several enemies with different forms of attacks.

* Create the powerups that give Zeta new powers (I think the absolute minimum would be a double-jump to reach high areas and a super-shot to knock down locked doors or weak walls.)

* Create all the conversations to dole out the plot.

* Create at least one boss character.

* Find appropriate sound effects and music (Zeta will not be a silent game).

That also seems doable in 20 hours. I think it’s possible for this game to be a success and I can’t wait to see how it comes out

Well, the comments were overwhelmingly in favor of my continuing Zeta. Now, I was going to make a Metroidvania either way, but if I could have found some art assets to help me I would have been willing to submit Zeta for the competition.

But sadly, there was a dearth of platforming shoot-em-up graphics in the competition.

You can see all the art assets submitted for the competition here. Warning, that link will take forever to load, not just because it’s every piece of art submitted, but because it’s every version of every piece of art submitted. Twice, for some reason. Also, believe me, some of the stuff on there is just plain weird.

Now, some of the artists just went off and did their own thing. Some of the stuff doesn’t look like anything more than a concept sketch – and since we’re not allowed to alter anything in the programming portion, they’re nigh-unusable.

But some of the artists had done this sort of thing before and provided very complete sets of graphics. For instance, if you’re looking to make a Roguelike, you’re covered. If you’re looking to make a top-down eight-way game (like the original Legend of Zelda), you’re covered. If you’re looking to make a Mario-style platformer where the character just runs and jumps (and perhaps has a short melee attack), you’re covered.

But if you’re looking for a run-jump-shoot platformer, there’s really only one sheet for that. And it’s a doozy…

Notice that the top and bottom halves of her body are split so that she can run in one direction while firing in any other direction. Also notice that she can…apparently turn into a red-eyed cyclops for some reason. Good, good stuff.

But it’s not exactly what I’m looking for. Zeta lives on a space station, and isn’t a cowgirl. Although a space cowgirl like a female Malcolm Reynolds would be awesome…

But no. I’m going to steal the hell out of that sprite sheet, but I’m going to turn her into Zeta, which means my game can’t go into the Assemblee.

Still, if you’re looking to make a game (or trying to come up with an idea for a game) definitely check that page out while it lasts.

So last night I started on Zeta. In about a half-hour I was able to get graphics integrated, create a scrolling tiled world, and get basic runing and jumping physics in, collecting objects and climbable ladders and ropes. I even posted a Youtube video of my progress!

Okay, okay, ya got me. I didn’t really do all that work in a half-hour last night. Instead, I’m going to cheat like The Cheat and start with an existing project I did a while back. I know that technically this means this won’t be a 40-hour game. Don’t care.

Just like with Inaria, I’m going to make a basic list of features that MUST be in the game, features that would be nice to have, and then features that would make me really happy if they make it in.

MUST HAVE:

A main character that can run, jump and shoot.
A tile-based world for the character to traverse. This world can be made up of “zones” that can scroll in all directions. Zones can (and should) link to each other.
At least one enemy type to fight. (Just one would be boring, but we must have at least one).
At least one “powerup” that allows the player to access areas they couldn’t before (without this, the game isn’t a Metroidvania).

WOULD LIKE TO HAVE:

Multiple movement upgrades (slide, double-jump, glide, etc).
Multiple weapon upgrades.
Multiple enemy types, with some with weapons and some without, with unique looks and attacks.
An overall storyline.
A big boss to fight at the end.
A resolution to both the game and the story.
At least one “chiptune” music and sound effects.

WOULD LOVE TO HAVE:

Lots of dialog at various points in the game, detailing the story.
Lots of specialized animations for various things like the double-jump.
Multiple minibosses.
A way to lengthen gameplay by recycling or reinterpreting the level data, just like most Castlevanias do.
Multiple chiptunes for different parts of the game, including boss themes.

The game’s native resolution will be 320×240. It will play in a 320×240 window, a 640×480 window, or fullscreen at 640×480.

Again, my plan is to spend half of my time working on the engine and tools and the other half of my time working on the game’s content. I intend to steal almost all the graphics, but I’d really like to do the music myself, almost certainly using a tracker of some kind.

Seriously. I’ve been wondering what the hell I’m going to do with this blog for the last two months.

This blog was basically always about what I was working on and learning outside my job. Well, currently I have no side projects (I need a Mac to continue Inaria iPhone development, and I just can’t face the code mess that is Planitia any longer).

And I haven’t learned anything recently to merit a technical article.

And, sadly, I’m giving up on Name That Game. Stupid TinEye.com.

But then I had an idea, once that should have occurred to me before.

I was going to write an article called “Amuse-Bouche“, about the rather large number of short indie games that attempt to get a point across or create a mood in a small amount of gameplay. One of the defining aspects of the amuse-bouche is that it ends; there’s no infinite number of levels that provide no resolution. In fact, providing a resolution is a big part of what an amuse-bouche game is about.

An excellent (indeed, near-perfect) example of an amuse-bouche game is Small Worlds. If you’ve got ten minutes, play it right now.

Other amuse-bouche games would be You Have To Burn The Rope, Achievement Unlocked and ROM Check Fail.

So to sum up, an amuse-bouche game is one that a) can be played typically in an hour or less, b) has a definite ending, and c) deliberately evokes a reaction beyond “having fun gaming”.

And then I realized that this is exactly what I should be doing.

Planitia was too big. Star Revolution was too big. Inaria and Sandworm were pretty much just right.

And what was I going to do next? A 3D RPG. A Neverwinter Nights. All on my own. Yeah, right.

So…all hail the return of the forty-hour game! And it will be my personal goal to create at least one of these every month for the next year.

I already know what my first one is going to be. It’s going to be a short Metroidvania called “Zeta”, and it’ll be directly inspired by Iji (which isn’t exactly an amuse-bouche game but everybody should play it anyway).

Okay, Planitia. Here’s the basic design I am visualizing.

You’re a god. Your people worship you. You gain mana from their worship, and how quickly you gain mana is dependent on how many of them there are. There are three things you can do with your mana:

• Raise and lower the land. This will give your villagers more space to expand.
• Spend it to teach your villagers new things, like how to build new buildings or how to do certain tasks better.
• Cast spells that either help your villagers or impede your enemy’s villagers.

I was not planning on including direct control of your villagers (though this could change). This would result in a very Populous-style game.

The only problem is that if the base game is growing your civilization with no direct control over your villagers, that’s not really a game. it’s a software toy. To make it a game, there are two options.

The first is to give the player external, computer-enforced goals, like “create 50 villagers” or “generate 1000 mana” or “expand your village to this size”. Since the actual game play will be pretty simple, this may not make for a very fun game.

So we get to the second option. The one where you build up your village so that you can destroy all who oppose you, burn the bodies, salt the earth, collect their souls to offer to your dark god, etc, etc. Option two would probably be more fun. Option two requires either multiplayer or a half-decent AI. Both would be hard to do in 40 hours. So we’d end up with a game with very simple gameplay, but you can play skirmish against the computer and/or multiplayer with someone else over the net.

Thoughts?

When you know more about what it is you like about these games specifically, then a design will start to form.
– Dave Shramek, in a previous comment

Actually, what I liked about those games were the little coherent computerized worlds that they presented. Just about all of these games had wonderful little touches that made them feel more real. Powermonger had the birds that would fly around – useless from a game perspective, but a wonderful little detail. In Syndicate Wars, you can have your agents jump in a car, which you can then drive around the street. You can even have them take the monorail if the city you’re in has one. And of course, there’s the fact that you can blow up every building in the city if you try hard enough.

And now that I’m thinking about this, I remember a short story I wrote in high school about a king who rules a fantasy world where everthing anyone ever roleplays in this world actually happens. The king has a magical miniature diorama of the entire world that he can use to watch as the various adventures unfold, and doing so is his favorite pastime. I think I might identify with the king just a bit

But that sounds more like a tech demo than a game, so I’m still thinking.

One thing I have come up with, though, is a title for…whatever it is. I’m calling it Planitia, which is the Latin word for “plain” (as in”grassland”, not “unattractive”).

So I need a game design based around a heightfield/billboard engine.

First, let’s be explicit. What do I mean by a heightfield/billboard engine?

I mean a base world defined by terrain, and that terrain defined by a heightfield. Other models may sit on top of this heightfield, but the heightfield is the “ground” of the world.

Units in this world will be done with billboarded sprites. A “billboarded” sprite is one that is actually rendered as a 3D object, but is always rotated so that it faces the player.

Lots and lots and lots of games have been made with this system, and some of them have been truly great, like…

Populous (It counts, although you couldn’t rotate the map):

Powermonger

Dungeon Keeper

Syndicate Wars

Myth: The Fallen Lords and Myth II: Soulblighter

You can see that this engine style lends itself to real-time games with strategic elements (although none of the above are “real-time strategy” games as that phrase is defined today).

I definitely want my game to be real-time. I want the player to have buildings and units. I want the game to be fantasy-themed or mythology-themed. I also want the player to be able to raise and lower terrain, and I want that to be an actual game mechanic. But I’m not sure if I want the player to be able to directly control units. And I’m not sure if I want resource gathering.

Standard real-time-strategy: The player has direct control over resource gathering, building creation, unit creation and unit direction.

Populous: There are no resources. The player has indirect control over building creation and unit creation, and unit direction.

Powermonger: Some resources can be gathered directly. Others simply control what you can build in each city. The player has indirect control over building and unit creation, direct control over special item creation, and direct control over his army (but not villagers).

Dungeon Keeper: The player has direct control over buildings, resource gathering and resource collecting units, but only indirect control over fighting unit creation and direction.

Syndicate: Syndicate is more of an action game than a real-time strategy game.

Myth: There are no resources. There are no buildings. The player has direct control over his units.

Notice that Powermonger and Dungeon Keeper are practically mirrors – in Powermonger, the player indirectly controls the creation of his army, but directly controls the army itself. In Dungeon Keeper, the player has more direct control over the creation of his army (though not total control) but has little control over the army itself (he can drop his monsters directly over the enemy, but if they don’t want to fight they’ll just walk away).

Hmmm…this is going to take some pondering.

I posted a link to my last blogpost on the Gibbage Forums.

I have since learned not to ask Brit gamers if they want someone to make a Dungeon Keeper clone. Just assume that the answer is ‘yes’.

I think a Dungeon Keeper-style game will be a good way to break into 3D, and once its done the engine will be easily adaptable to more complex 3D games like Inaria 3D, so Dungeon Keeper in 40 hours is the winner!