Jump to content
  • Advertisement
Sign in to follow this  
aviosity

The Two Week Game Engine - How would you do it?

This topic is 4456 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Howdy all, I'm working on a game engine for a class (this is a 3D modelling class, so the game engine is something to show off my work...NOT A REQUIRED CLASS COMPONENT). The funny thing is, I discovered my presentation is in 2 weeks. It has to be full 3D, meaning model loading and texturing with some form of animation. The models have to be able to move around, there has to be a terrain, and the models have to be attached to the terrain. That's all it really needs, but how would you do this efficiently, without adding unnecessary features or working into a corner? Note: I'm not really asking for advice here, just wondering how everyone else would handle it if they were in the same situation. If someone notes something that sounds like a good idea, I'll probably use it though :-P. Looking forward to hearing your ideas, Aviosity

Share this post


Link to post
Share on other sites
Advertisement
Since it looks like you need a fairly specific thing, a full fledged game engine would definately be overkill. All you would really need are a few classes for the different parts. Maybe a terain class, and a model class. Each could handle loading/animating themselves.

Definately get it done ASAP. Unforeseeable things always happen, and things that *should* take an hour can take days. Good luck!

Share this post


Link to post
Share on other sites
Definitely keep it simple. You need a camera, terrain, and model (just one to start; you can add more if you have time). Each of those should get a class. You'll also need a main loop to make everything draw and to update the model's position. For the time being just hardcode in the texturing information; again, if you have time, you can subclass that stuff out and clean up your code a bit.

Oh, and get started soon. Like, by tomorrow you should have the basic framework of your code worked out and the main loop written.

Share this post


Link to post
Share on other sites
I would use some existing technology -- D3DX has both mesh loading and animation, and comes with a MultiAnimation sample you could adapt. Writing an exporter with animation, plus the loader and renderer, in 2 weeks would be highly aggressive...

Throw in a simple heightmap terrain, and set the Y coordinate of the animated meshes to the heightmap interpolated value, and the meshes follow the terrain.

Share this post


Link to post
Share on other sites
If you just need to show off your models, and you can get it to compile easily, Ogre is an amazing graphics set up that's not too hard to just get to show a couple models.

Share this post


Link to post
Share on other sites
I'd just use Ogre because I don't believe in giving myself even more pain on such a tight deadline.

Share this post


Link to post
Share on other sites
Quick and dirty I think 2 weeks is plenty. I'd just copy some model format code, project can't expect you to do your own model format. A terrain can be implemented barebones brute force in under 100 lines of code. Some crummy physics collision won't be more than 2000 lines of code probably. Use glut and its portable for grading plus its only another 100 lines of code. Now if you want it to look good thats another story!

Share this post


Link to post
Share on other sites
Thanks for all the replies, guys (and/or gals). I've already got a (sketchy) windowing system I built for Win32, so windowing isn't really an issue, and I've implemented a dynamic array system (again, sketchy and more than likely horribly inefficient). I have a lot of other code, but it's so poor that I wouldn't even dare trying to throw it in here. I'm using Red Ghost's excellent tutorial on parsing DirectX files and will use that as my model format (the class is taught with Cinema4D and that can export to .X). Other than that, I guess my goal over the next week is to get terrain, model loading, and rendering both to the screen done. After that I suppose I'll handle movement (1 day), a camera system (1 day), font system (1 day), terrain collisions/object collisions (2 or 3 days, I'm very new to the whole collision scene), and maybe if I've got some time, throw in some OpenAL support to get some rudimentary sounds in there.

If anybody has any suggestions on resources they have on implementing such basic collision or model loading, I'd love to hear it; however, I do know how to use google :-P...but I'd love to keep hearing ideas :)

Note: I appreciate the advice of some people to use OGRE...however, the reason I'm not is because I want the "engine" to really be the crowning achievement of the presentation, not the models (since my artistic skills aren't really that great :-P)...plus, since I'm a Computer Science major, the programming is fun :). I want to build a fully extensible engine at some point, so I see this as something of a starting point.

Thanks so much,
Aviosity

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If I were you I would build some nice scene graph und using d3dx and the dx sample framework heavily.

And then OGRE is a very complex system I really don't know if you're capable of working yourself into it and be done with your project in two weeks.

Share this post


Link to post
Share on other sites
I don´t know whether it´s a good idea to use something of a "dirty hack" you made in 2 weeks (no offense intended) as a starting point for a "fully extensible engine". I´d rather see that project as an opportunity to learn. The reason I´m saying this is that you would have to take loads of things into consideration when coding for an extensible engine which you don´t need right now for your project.
For your project right now I´d "just" implement the directly needed features without thinking about extensibility too much, as this would tend to slow you down quite a bit.

For the terrain:
I´d suggest using a simple heightmap terrain (without any LOD most likely, to get it done quickly), as suggested. You could use any paint program to make a grayscale heightmap picture and load that. Seems to be the easiest and fastest way to get terrain done.

For the meshes:
You said you´re using C4D and that it can export .X files: Make sure the exported files are really usable. The easiest way to do this would be to load them in the MeshViewer that comes with the DirectX SDK. I´ve once exported an x-file from C4D and it was fine while I didn´t use textures / materials in C4D. As soon as I used those the x-file wouldn´t load anymore. Seemingly something with the material / texture export was wrong, so check whether this still applies. I had found a exporter plugin for C4D though that did the job back then (was called something like XPort IIRC).
When you´re sure that the exported files are correct, you can use the D3DX helper functions to load the meshes into your engine in one call, normally complete with animation / bones AFAIK, though I never did that. This would save you the time you would spend implementing the mesh import, but would require you to use DirectX.
Since I´ve never done anything with OGL, I won´t say anything about that, but the DirectX SDK comes with most of what you need to implement for the meshes: x-file import and a mesh complete with animation control.
If you´re used to OGL though you might well be faster using that.

Furthermore I guess you´re not going to load hundreds of meshes to build a really large scene. If you keep things small you won´t have to bother too much with things like culling and/or scenegraphs and the like, which would save you time again, so I´d suggest doing so.
In the end I´d try keep things as simple as possible, which means, if I´m correct, you only need the most simple terrain you can stitch together, a container for all the meshes you want to load, a camera, a simple collision detection and some movement. I´d rather use the remaining time to polish your artwork than implementing something fancy in your engine, as you are doing this for a modelling class. A crappy engine with good artwork can still look nice, while a good engine with crappy artwork will still look ugly.

Hope that helped and good luck

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!