• entries
  • comments
  • views


Sign in to follow this  


So now that i've got the previous engine all smoothed out nice and pruned of any old uneeded functionality, it's time to start integrating the new systems.

First off it should be known that in general, I've got no clue how to make a full 3D game so, like always I'll be making stuff up as I go along. When doing somthing new you need a good mix of learning and braveness; take the time to read up and understand how things should be done, but don't be afraid to write some not-so-perfect code.

I've got a couple of major systems that I need to implement, I'm trying to leverage as much turn-key free middleware as possible:

3D Graphics:

This is a big one, thankfully I already have an engine which is using Direct3D9 and shaders, so that is a bit of work already done. The bigger challenges will be dealing with map format, model format, materials, and rendering.

I've tentatively decided to go with COLLADA for models after some talks with people. For 'Actors' in this engine we'll be using skinned meshes, first by directly importing the collada format, and later perhaps a converted binary format.

I'll probably be using the D3DXMesh object and it's Animation Controllers, since i've heard they're implemented very well.

For terrains I'll probably be using a heightmap again, but I am not positive yet, there will also be a need for general static geometry such as walls and non-important furniture.


I want physics to play a huge role in the gameplay of my adventure games, being able to manually knock down a brick wall with a sledge hammer instead of a simple (use hammer on wall) is what will help to make my game shine; I'm still evaluating which library to go with. I looked at the ODE documentation and it seemed straight forward, but it definetly had a 'dated' feel, must have been the C interface *shrug* I've been told that PhysX (previously novodex) is the best out there, however the pesky need to install a software driver is going to keep me away from that for now, plus I don't need crazy physics. I've been told tokamak is a much better choice than ODE due to simulation quality at an expense of performance, due to small scenes that adventure games have I would probably have no problem, and higher accuracy physics would be a plus.


I've battled with audio systems for a long time now, they're just a pain to implement. I'm currently using a 2D/3D DSound system for streaming ogg files, and it works 'okay', I had planned to use XACT instead, however the use of ADPCM only rained on my parade, 25MB a song instead of 4MB? I don't think so, we do a huge business from downloaded copies of our games, so keeping in the 200-600 MB range would be nice. I was informed by Saruman that FMOD recently changed their licence for indies, to 100 bucks a title, this is quite palettable for me, so I will have to check out what FMOD can do, it might just save the day.

Control Scheme:

For now we'll be keeping to a radial menu verb system, with the addition of using items with physical properties on other physics elements. Unlike in the current version of Malathedra we won't be using node-network based movement, instead you'll be able to move anywhere that you don't collide with somthing. I've tentatively decided to use a point-to-point linear seeking scheme with obstacle avoidance using the OpenSteer library, this should give a fairly natural apperence, and shouldn't be an issue due to small scenes, but worst case scenario I could snap a grid over the scene and use A* to return a point path which opensteer could then follow; but i'll try to keep to simplicity.

In summary, things are going good, I see some good staying power forming again, and I'm keeping my journal generally up to date. I'm sure most of you are bored to tears with it so far due to no pictures, but I'll get some up as soon as there is anything worth seeing.
Sign in to follow this  


Recommended Comments

Awright, lemme get this straight. You dropped Malathedra because it was getting too large and unruly to get out a release in the near-term. You wanted to focus more on stuff that you could get together on a shorter time-frame. And the way you're going about this is to put together a system that's even MORE complex and unruly than the one you originally used?

Take a breath boy. Step back a bit. Assess your situation and your plans. Make sure you're not doing things for their own sake.

Share this comment

Link to comment
The reason I dropped Malathedra (or rather, am redesigning malathedra from a mainly tech standpoint), is because of two main reasons.


The art time required to do a decent 2D adventure game is phenominal;
and the end result of very inflexible art assets that take forever to create.


I'm not doing this for fun alone; I can't do this for fun alone. To create games of this size (which is what I want to do) there needs to be a signifigant income generated by it so that I can validate the time I'm spending on them.

Originally Malathedra was put on hold due to my personal life; but at a point where I decided to re-open it I decided that if I really really wanted to sell this game it needed a make-over; it just can't compete and expect to do well as it was. Also, don't get me wrong, I imagine I could sell at least as many copies as I sold of Morning's Wrath, and maybe get another large publisher deal, but the sum total of 'maybe' 4k gross to my personal income is not worth 12 to 18 months of work; this is time I could be spending on other hobbies or doing game development to a lesser extent, don't get me wrong I want to develop comercial quality games, but the point is, after you've done one large game; to do that again you either need to be in or out, you're either a weekend hobbiest, or someone planning to turn a profit.

So my main concerns require me to be both artist and businessman; how to create somthing I'll love and consider art AND be able to sell; and the current version of Malathedra just wasn't going to cut it.

The story is wonderful, the music is wonderful, the graphics needed major work and the gameplay needed major work.

The Graphics:

I like sprite based 2D, I think it's got a lot of character and it still has it's place; but not in the current generation of immersive games; it's not dynamic enough in a naive approach and to make it dynamic requires a huge amount of art; more art means more skill, more time, more memory, etc.

Malathedra needs to be 3D, why? Because 3D is dynamic and to a larger degree can be manipulated by programmatic forces instead of pre-defined choices; and while this ties into gameplay, I've finally realized that what I love most about games is choice, the ability to try somthing and see what happens; tie that in with a lot of flashy/funny/dramatic results and you've got an enjoyable interactive experience.

So, to be 3D that means an engine overhaul.

The Gameplay:

Malathedra's existing gameplay was fine, the problem is it had really _no_ innovation; The radial menu verb system has been around since afaik Return to Zork circa. 1993, however it's good and it will be used in some places; but if I plan to make my time worthwhile I need to push the envelope a bit for adventure games. And that is where physics comes in; while it's not a magic bullet, the concept of physics opens a whole new world to what is possible in an adventure game, many of the tired 'use x on y' puzzles can be replaced by complex interactive 'mini-game' like scenarios; I've got some ideas for a new control scheme that will make the player feel a lot more in-game that most other adventure games.

So, malathedra needed more interactivity and some fresh new gameplay to make it stand out.

All of this boils down to the fact that I had made a really great adventure game engine; but it didin't push any envelopes of the genre and if I hope to succeed I need to stand out, that is why I'm doing engine development at the moment lol :)

Share this comment

Link to comment
God, EDI, that was like a whole 'nother journal entry, stuck in a comment. Personally, I'm sad to hear that the 2D graphics will be going - I really liked how it all looked for one, and 3D graphics seems quite a difficult step up from 2D isometric. I've seen a lot of games that have very ugly 3D models - RuneScape, although it's getting some models redesigned, is one - and pulls down the overall "score". =|

I really hope this works out for the best. =)

Share this comment

Link to comment
Again, make sure you're not doing things for their own sake.

A great example is chess, and for two reasons. . .

Example one: Remember that 3D chess game they played on Star Trek? It had several levels and was clearly superior to that cheesy 2D chess we play now. Well, some chess-types put their heads together and actually implemented rules for 3D chess. And it wasn't fun, so they re-implemented it as a 3-level chess. And it still wasn't any good. So they re-implemented it a couple more times but never managed to improve on the original. There's a 3D chess on the market now, but it's basically just 2D chess separated to different levels (if you look at it from the top, it's the old 8x8 board). In this case, a new paradigm, while considered to be an improvement by its own nature, turned out not to be.

Example two: Ever play computer chess? Especially those ones where you can tilt and rotate the board in 3D? It's a gimmick. Everyone who plays computer chess for any length of time does the same thing. They play the 3D version for the cool-factor, but once the cool factor wears off they switch the board to 2D because it's easier to visualize.

I'm not trying to dissuade you from anything, but it does appear that you're doing 3D for its own sake. If you have a game that's playable just fine in 2D and you're implementing it in 3D anyway, make damn sure that you're not making 3D chess.

And yes, this is speaking as someone who took a long hard look at implementing Bulldozer in 3D.

Share this comment

Link to comment
Speaking of magic bullets, have you checked out the Bullet physics library? I haven't tested it myself yet, but it seems more promising than ODE to me, and is one of the few physics libs with swept-volume collision detection.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now