Project: Goblinson Crusoe

[JTippetts]

Hi, everyone. Thank you to everyone working on Urho3D for making a fantastic library. I've spent several years tinkering with other libraries, and I can honestly say that I have never found one that fits me so well as Urho3D does. Awesome engine, awesome people working on it.

My name is Joshua Tippetts, and I'm working on a game called Goblinson Crusoe. It's a turn-based, hex-based tactics RPG based around the adventures of an apprentice goblin wizard exiled by his master to a distant island in a lost sea. It includes strong aspects of crafting, resource gathering, survival, tech-tree progression, and so forth. It is still in very early prototype stages, but it is going very well. Here are a few recent screenshots:

The game is being written in Lua, against the Urho3D Lua script framework. All art and programming are being done by myself in my spare time. The game is still very much in development, and things change seemingly every day. That is one of the beautiful things about the partnership between Urho3D and Lua: rapid iteration and prototyping on a strong functional foundation. I keep a developer's blog about the game at http://www.gamedev.net/blog/33-why-you-crying/ if you are interested in seeing what's going on. Once again, thanks to all of you guys for your hard work.

JT

[Chris Friesen]

Nice screenshots :D Looks like you are pretty far along!  How much longer do you have to go?  Are you past the evil hump where you know if you have a game or not?  Did you have to modify anything in Urho for your game?

[JTippetts]

I still have quite a ways to go, I'm afraid. I'm working on a vertical slice right now, with a little base-assault sample scenario, but as far as an actual "game", it's still a ways off. But I do feel like there's a game here. Everything is vanilla Urho3D with no modifications, though I did encounter a few bugs along the way, which they were very quick about fixing. My largest issue has been with UI, but that's mostly because I detest UI development, not for any shortcomings on Urho3D's part. Everything beyond the UI slots together nice and neat, bam bam bam. I've been developing the prototype with an eye toward converting everything over to straight C++ in the end, but given the decent performance I'm getting even when I do stress tests of hundreds of enemies, I'm wondering if that'll even be necessary. Even on my low-end machine, it's nice and snappy; and I haven't even done any kind of optimization. Not even using lod meshes, and some of them are fairly heavy-weight and need to be trimmed down a bit. Not using lod materials, either, so everything is normal-mapped using full res textures all the way out to fog. And it's still performant. (For the record, I was not able to achieve nearly the same kind of performance using either Irrlicht or Ogre; possibly, I was Doing It Wrong, but I think it says something that out of the box, with no attempt at tricky optimization whatsoever, Urho is so far the most performant for me.)

I have the advantage that the structure of the Urho3D framework is very, very close to the structure I was using on a previous iteration when the game was 2D, so switching to Urho3D (outside of waiting for the Lua subsystem to mature) has been very easy. In a lot of cases, it's been a simple matter of doing minor edits on a component to make it inherit from ScriptObject and to change the mechanism of event passing. 

[Raster Ron]

Looks great Joshua. I've seen this project and your updates in GameDev forums. Keep it up!

[Lasse Öörni]

Nice to see you posting here, Joshua!

About the performance difference to Ogre: when starting out on Urho3D, I had been working on several Ogre-based projects (one of them for years in my day job) and the efficiency problem was very apparent. So as cruel as it may sound, Ogre would act as a benchmark of what not to do. The upcoming Ogre 2.0 will bring heavy optimizations to the scene graph side, but then they still have the render systems' graphics API call sequences to optimize, which will be some work. Basically, the problem is that with every draw call, Ogre does a very heavy setup of the whole graphics device state (including settings such as point sprites, which may not even be in use). About Irrlicht I can't comment.

[JTippetts]

Ogre was pretty good to me when I was starting out, and I'm glad that it's getting some TLC. Hopefully, they can trim down some of the bootstrap complexity also. Irrlicht could use some reorganization as well. Their shader framework is particularly aggravating. Still, it was good to me for awhile just as Ogre was, and I used its underlying render system for the 2D basis of Goblinson Crusoe. But working with Urho3D is nice; I just don't think I'd ever switch back to either one, even if they do update.

Outside of the tidy structure, one of the nice things is having the scripting so well-integrated into the framework. Many bindings to 3D libraries consist only of a straight API binding, with no effort whatsoever to integrate framework and script as a tight and consistent structure. But Urho3D's functionality, with the flexibility it offers, is neat, and I do appreciate the extra effort you guys have made to make it so with both AngelScript and Lua. I like the idea that if I need to convert a component to C++ for performance reasons, I can do so without having to change its structure to fit the framework. Essentially, the game doesn't care whether a component is implemented in Lua or C++, and that makes me happy.

I feel like I need to clarify something, though. Earlier I said I was using vanilla Urho3D with no modifications, which is technically true. I do link against an unmodified static library. However, I modified the executable a little bit to include some of my own thingamajigs. Mostly, I just import my noise generation stuff, some hexmap handling and pathing stuff from the earlier prototypes, and a few other useful odds and ends. Since I was already using tolua++ for generating my bindings, incorporating this stuff required no effort whatsoever on my part. I know it might sound like excessive cheerleading on my part, but it really is almost like Lasse read my mind on what I wanted out of a 3D framework when he started making this thing. :D

As this game progresses, I'll drop some updates here in this thread.

[JTippetts]

Lately I've been working on the armor/equipment/weapon system. I've implemented Stances which are sets of animations created for a specific weapon type. So far, I have animations for 1-hand weapons, 2-hand weapons and staff. I've also been experimenting with applying particle effects to bones, as with the fiery sword in the above screenshot. So far it's been pretty straight forward implementing this stuff.

[JTippetts]

I've been fleshing out the equipment system, implementing an equipment switcher to equip any weapon. The weapon is specified as a description of a hierarchy of nodes which are instanced and parented to the weapon bone in the skeleton. Equipment is done through a new type of workbench, the Wardrobe.

The functionality is there to do other pieces of equipment; however, I haven't modeled any kind of armor or cloth pieces yet so really nothing shows. The other equipment slots are implemented differently from the weapon, in that the models are created as AnimatedModels that share the base skeleton, whereas the weapon is a static model parented to the weapon bone. As you can see from the above shot, you can get creative with the node descriptor passed to the weapon switcher. In this case, the descriptor specifies a static model for the staff, a light to emulate the staff tip glowing, and a simple particle effect around the staff head to make it all mystical and whatnot.

[Chris Friesen]

I like the 'mystical effect' on the orb.  Looks like you are getting some nice visual variety. It looks like the environments have hit that complexity where the player can experience some immersion.