Archive for January, 2010
Name That Game 68!
This one is dirt simple. I’m expecting a successful response in under five minutes. But I love this game and I love this screenshot, so I’m gonna do it anyway.
Name and developer, please!
5 commentsDaisyMoon
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.
2 commentsTechnical Difficulties
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.
6 commentsName That Game: The Triumphant Return!
You know what? I’m not going to let the internet spoil our fun. That would just be stupid. So once again, Name That Game!
This one had a lot in common with Crusader: No Remorse, except it had an even darker storyline.
Name and developer, please! If you win, I promise not to implant a bomb in your head and send you out on suicide missions.
Edit: The game was Meat Puppet, by Kronos Digital Entertainment.
3 comments

