Searching for the right engine... maybe

Started by
6 comments, last by kiwibonga 12 years, 10 months ago
Hello everyone. A couple of weeks ago I posted a topic asking for suggestions for a project I'm planning on working on this summer.

I've since fleshed out what I'm doing and generally know what it is I'm going to attempt to make. My task is now to determine what I'm going to do this project "in." There are a number of options for engines which seem to do different ranges of things, and I'm not really sure which of them will suit my needs (I'm pretty darn sure that some of them won't let me get as low into the level code as I'd like to). I'm wondering if anyone has engine suggestions, or comments on some of the engines I'm about to list... but first my project idea.

This idea stems from the fact that I am a programmer, not an artist, and I've always been a fan of procedurally generated stuff in games (Dwarf Fortress, Minecraft, and NetHack come to mind). My idea is to randomly generate a dungeon/maze/cavern/whatever you want to call it, which will consist of tunnels and rooms in a maze-like fashion. Preferably fairly large (possibly 20-50 layers). These tunnels/rooms/caverns are going to be 3D, and hopefully by the end of the project you'll be able to walk through them and traverse the caves like you would a cave in a game.

That is as much as I think I can even reasonably hope to get done. But if I do manage that (and who knows if I can even pull that off), I'd like to continue on implementing a psuedo NetHack clone, in 3D. I doubt I'll get that far but hey, it's something to shoot for. That or possibly implement biomes or something in the caves themselves, where different layers might look different ways (some man-made textures, some natural textures or shapes, etc - stalagmites/stalactites/other cave features could be cool if I don't want to get into making a full fledged game but I have time left)

With that said, I've looked at some Unreal Development Kit tutorials, and some Unity3D tutorials, and all of the level editing and generation seems to be done by hand in their graphical tool - which is great and all if I want to make the levels by hand... but I don't. I want to do this all on the fly, randomly (and it doesn't have to look that nice, probably won't since I'm doing it all randomly). Is there any easy way to access the data which describes the verts in the UDK or Unity? Or am I better off not even attempting to look at how their files are formatted, etc?

Is there another engine which provides "less" in terms of stuff that's done for me which would be better to work with? I've looked briefly at the following engines:
Unity3D
UDK/Unreal Engine
Irrlicht
Ogre3D

The first two of those really don't seem to easily accomplish what I want them to, but I could be wrong - the tutorials I found and the descriptions I found online all seem to say that it's not something people do very often to not use the graphical editor. I'm not sure about the second two yet (Ogre looks promising possibly).

Does anyone have any engine suggestions? I could also do this all by hand in OpenGL, (which I know a decent amount of), but while the graphics of it won't actually be too hard, the physics of allowing someone to walk around might be a struggle to implement in any reasonable way, and the possible expansion to be a NetHack 3D clone seems significantly more work without some sort of engine backing me up and sparing me some of the physics and other work.

Does anyone have any suggestions?
Advertisement

Is there any easy way to access the data which describes the verts in the UDK or Unity?

In Unity, yes (not sure about UDK). With Unity, the editor is essentially just a convenience, more or less; pretty much anything that can be done in the editor (and some things that can't) can be done in code instead. (As for procedurally generated stuff, several people have created Minecraft-like demos in Unity.)

That's not to say Unity would necessarily be the most appropriate choice for your project, but technically speaking, it's capable of doing what you describe.
Yeah I would recommend Unity as well. Once you start making non-platform games in it, you wont use the editor for actual level design. Unity just gives you a nice environment to manage all your resources in, plus it takes care of the game loop and switches between levels :)
Alright, thanks guys. I think the next step for me then is to go get Unity and play with it some, and see if I can do some stuff by hand.

Do you know if there are any tutorials out there for doing things in Unity without using the editor? Or do you recommend I start with the editor? (I have a pretty decent programming background, so I can handle the programming, but if there are ideas/concepts that Unity uses and the GUI is the best way to learn about those maybe I should start there?)

Thanks for the advice.
I can't tell you how much rage UDK has caused me. If you're not making a UT3 mod with completely static level geometry, don't even bother for one second.
Unity3d would definitely be a good one.

I can't speak for the UDK, nor irrlicht, but I've been using Ogre3D a couple of years back.

I'm pretty sure you can get all the work done in Ogre3D as well.
However, out of the box it isn't as intuitive as Unity, nor does it feature such an easy resource-management.
On the other side, if you're a really die-hard coder, it would be worth to check it out since you'll be feeling like having a lot more control.

That said, if you develop on Windows, and like to do all coding the hard way, XNA could be interesting as well.
It's not really an engine, but as a framework, it gets as close as you would want it to.

I can't tell you how much rage UDK has caused me. If you're not making a UT3 mod with completely static level geometry, don't even bother for one second.


When you say static level geometry are you saying that it's hard to make levels with moving parts (that's a non-static level geometry) or are you trying to say it's hard to make levels that have a static level geometry, but are generated at runtime.

That might be a poor way to phrase that question... are you referring to procedural generation of a static level (ie, the level doesn't change once it's made, but it's made randomly and not by their tool) as a level with non static geometry?

Because what I'm doing I'm okay with static levels *once they are generated* - I want the ability to generate a level, then drop a person into it and let them walk around. The level is static once the player is in it, and would act like any other map or level file would. It's just that first step of making the level which isn't really static.

[quote name='kiwibonga' timestamp='1306482159' post='4816342']
I can't tell you how much rage UDK has caused me. If you're not making a UT3 mod with completely static level geometry, don't even bother for one second.


When you say static level geometry are you saying that it's hard to make levels with moving parts (that's a non-static level geometry) or are you trying to say it's hard to make levels that have a static level geometry, but are generated at runtime.

That might be a poor way to phrase that question... are you referring to procedural generation of a static level (ie, the level doesn't change once it's made, but it's made randomly and not by their tool) as a level with non static geometry?

Because what I'm doing I'm okay with static levels *once they are generated* - I want the ability to generate a level, then drop a person into it and let them walk around. The level is static once the player is in it, and would act like any other map or level file would. It's just that first step of making the level which isn't really static.
[/quote]


It should certainly be possible, technically, if you can figure it out... Although the EULA forbids you from reverse engineering "the UDK" -- I'm not sure if the proprietary map format is included...

One thing you can do is import terrain from heightmap images created with external tools, as well as models for static geometry; I don't know if that would fit your requirements. You may find, like me, that the static geometry you import tends to have very glitchy collision detection. I don't know if that was improved since I last used it, but the models you import should be small props with simple bounding volumes, not floors, walls or rooms.

This topic is closed to new replies.

Advertisement