Open world open source game engine?

Lately, I have been dabbling in some programming. It was inspired by my enjoyment of Minecraft (yes, sorry, I’m another one of those…:spin:), but also by my frustration at how the modding community seems to be pretty much reset every time a new version comes out, causing many mods to never be updated. So I started programming, and got a really weak personal Minecraft derivative working. The point was to make an open source engine that departed from the rigid structure of FPS-minded engines, i.e. “edit a level and add weapons and enemies and such”, and instead was more openworld-minded, i.e. “set up algorithms for open world terrain generation, allow for crafting, building, mining for goodies and slaying various enemies and such”. More flexible, more open, less controlled, and open for anyone to tamper with and add to.

Alas, I have come to suck more and more at programming as time goes by.

So it dawned on me: I cannot possibly be the first to get this idea (I’m not that smart)! There must be an engine already out there doing enough of the same that I can simply join their work and add to it!

So my question is this: Do any of you know of an open source game engine out there, that allows for in-game terrain alteration (i.e. digging holes in the dirt, cutting down trees, etc.), crafting, building (like building a house the character can walk in) and other such features? Preferably one that does not use the Minecraft “block” style, since I feel that is a unique Minecraft-feel and should be respected as such.

Edit: I’d love to do it in the Blender Game Engine, but the terrain alteration alone seems to break its possibilities, not to mention the idea of true open worlds (i.e. generated on the fly). Although, come to think of it, scripting something of the sort into it might be an option, if no C++ engine exists… hmmm…

Sauerbratten’s engine (a.k.a. Cube2 )

It looks good, but it looks very much like it follows the regular formular, i.e. world size is fixed in the game (not open world) and the action does not allow for terrain alteration (mining, farming, digging). It might have crafting, I cannot see that, but the open world and terrain alteration are really what is missing from most engines.

I’m not so sure if this whole mining/farming/digging deal is gonna be a focus here, but you might be interested in

EDIT: Oh, I noticed you do not want the block style. Whatevers.

it’s hard to get around not using cubes, since game engines like minecraft uses voxels and voxeldata. a cube get’s deleted here and there. etc.

it’s really hard to do without voxels.

ogre3d and maybe some b/w texture where user can ‘dig’ and paint on. and that texture controls terrain height etc.

There was on OSS game called Wurm Online that claimed to have player alterable terrain and some of the features that you are talking about.

I got a bunch of hits just with a “Minecraft like games” google query. That could be a good place to start just to see what other devs are using. I’m guessing your looking for an engine that has at least these things:

  • A terrain API accessible via scripting
  • A robust scripting lang (with a script powered MVC style GUI?)
  • Clandistine level streaming (to simulate the infinite landscape)

Do you know of the UDK? I want to say that in the Unreal Development Kit, which is the SDK for the Unreal Engine ( Alpha Protocol, Batman: Arkham City, BioShock, Borderlands, Gears of War 3, Mass Effect 3,Silent Hill: Downpour) you can use UnrealScript to make an interface between the terrain editor and an ingame GUI, ie your PC can edit terrain/landscape. UnrealScript has some powerful features features (though its still a scripting lang), but honestly I don’t know if you can interface with the terrain functions, all I’m saying is that it might (I’m not that deep into UScript yet), but would that not be close to what your looking for? I’m pretty sure half the engine is just C++ classes extended with UScript.

Of course something like the UDK is not open source (just free to use for noncommercial stuff), but it gives you a whole lot of programming freedom (prolly more than I know of). If you do use the UDK (or something like it, like Source SDK, or CryEngine, or Unity) your focus would be on the high level stuff, like the game logic engine, AI algorithms, and writing all those function calls to the terrain API (that sounds too hard for me). As opposed to extending a monolithic C++ library yourself by using C++ even for the scripting tasks. So, maybe it just comes down to whether you want to make a game or the software that makes games. I dunno, I’m still green with this stuff, but maybe the UDK is worth considering, or maybe not. Maybe the world will end soon, but maybe not.

But I would think that in-game terrain editing functionality is best relegated to an intermediate scripting layer, so that you can make a solid debugged engine, write your scripting module and utilize that, and then stop tampering with the engine code.

What do you mean by open world? Do mean faraway clipping planes with the absence of loading screens and blocking volumes, but you have to enter dungeons, and without eventual level boundaries? I’ve messed around in Fallout3’s level editor and made some landscapes simulating those kinds of characteristics. The Fallout’s engine (Gamebyro) uses " distant fog" as a clipping instrument which you can adjust, but also statics like mountains and hills to occlude. Once you fixed the fog properties, then you would place a level streaming volume (used mostly as an optimization for interiors), placed according to your fog distance. Then at the boundary of one terrain cell when you want to transition seamlessly into the next terrain cell, copy everything visible inside the level streaming volume, paste this into a new terrain cell project (must have same fog properties) and portal the cells together using volumetric portals. Just make sure the two portals are aligned relative to the two identical terrains. There’s an incredible amount of redundancy here, but no rendering redundancy, because after the portaling you’ve taken the previous terrain cell out of memory. And the dynamic terrain generation will build off of that copied&pasted bit of your cell. But you will only have to do this once per cell, since after the PC discovers the cell you don’t want to change it. Then the cell should become amenable to the PC’s terrain tools.

To be honest I don’t know how else to simulate infinite landscape beyond variations of what I described above (alternatives like just overlapping level streaming volumes instead of copy&paste seam terrain) Its obviously impossible to prebake an infinite landscape. So you will have to do terrain cell streaming of some sort, and the cell will have to be baked before the streaming. Landscape/terrain is pretty damn computationally expensive, I wouldn’t be surpirsed if you had to do some clever thread management to optimize the generation of the terrain. The bigger your level streaming volume, the more time you have to generate the upcomming terrain and the farther the clipping plane, but more terrain to generate per cell. And if your cells are rectangular you might have to generate two cells simlutaneoulsy. Hhmmm…

Thanks for the responses, and please, keep 'em coming :slight_smile: It really does need to be Open Source, because I want to tamper with the features (unless the scripting allows insane control over things, but I have never seen that level of script influence, not even in Blender itself!). Worldforge looks interesting, I am trying to find a For Dummies kind of introduction to the coding of it already… CraftStudio does keep the block style, so is not quite what I’m looking for, but might be fun for other uses! I know of Wurm (which, btw, Notch actually seems to have worked on pre-Minecraft, and it shows, a lot!), but I have never seen signs it was open source??

I am actually thinking this might make an interesting kickstarter, if there is nothing out there :smiley:

I believe the only way to do what you want purely by scripting is an engine that is basically an API containing functions needed for game development.

Panda3D comes to mind (contains an API based on Python), there’s also the old DarkBasic pro engine (also an API, but not Open Source or cross-platform).

Other than that, it may be that the only way to create a terrain generator within an Open Source engine would be to code the features yourself, if it came it to that though we’d love to see it being the BGE python API that gets the type of functions needed for true mesh generation. :slight_smile:

Try Voxlap it seems like a great engine for what you want to do, but be prepared to code a lot. This is a pure voxel engine so that means digging and all that jazz. I have seen attempts to do the same (such as voxels not the game idea) in unity and ogre but I don’t think they released the source. But to answer you yes you are not only one who was thinking of a game like that, I have also been thinking about it but cannot program as of yet.

Okay, so I definitely see multiple ways in which an open source project is something you would want in these circumstances. Opensource software is badass. But UDK is also pretty damn badass. I’m guessing you’re planing on learning the architecture, and to go deeper then just some accompanying API or some wrapper classes. To boldly go where no man has boldly gone before. But whats your focus here: to make a terrain generator or to make a game with a terrain generator made by you? I mean, you sound alot more experienced then I do. I’m still covering theory and math shit in this field, and haven’t even reached the stage where I actually involve myself in a project. So, your rejection of the UDK as your software of choice makes me feel like I’m just wrong about something. So I just want to give you a nickle for your thoughts here to know why UDK is less desirable then an opensource package for your terrain endeavor. (But I suppose I would accept that opensource is opensource and all its wonderful freedoms and 'nuff said)

I’ll tell you why I think UDK is open enough to afford you the power you require (but ultimately I cant say with 100% just bcuz I haven’t tried this myself, nor do I plan on it. I’m just here to officiously throw unfounded advice bcuz forum posting keeps me awake and I need to stay awake. Otherwise they’ll find me!) Sorry, anyways, the textbook UDK Game Development from which I’ll paraphrasingly pull some excerpts here for ya. As you will see UnrealScript is pretty hardcore. I know that from working in various level editors that the average scripting functionality is paltry. Some game scripting languages don’t even provide looping structures. But just give me a second here to convince you how powerful this scripting lang is inside the UDK.

  • UScript is based on C++ and java in that it shares most of their keywords, structure and syntax including an OOP paradigm. It is a compiled language. It is similar to Java in that everything must be inside a class. In short UScript supports only object orientation; including classes, inheritance, and polymorphism.
  • UScript implements the following constructs:
if, else, switch, for, while, break, continue, int, float, char

Furthermore UScript has block level variable contexts that are delimited with the usual curly brace syntax:

//create reference variables that point to terrain assets
//manipulate those assets with some nice functions
//put those assets back into the world context according to your OOP classes
//polish textures and materials by calling the shading langauge API (GLSL)
  • UScript is based off a finite state machine model (FSM) where the state-space is the game’s state space and allows developers to effectively define multiple versions of a single class, each class version called a state, and to have UScript switch back and forth between the different states depending on specific conditions. (I’m guessing this is where polymorphism comes in) A real programming language like Java or C++ obviously doesn’t need explicit state-space functionality (beyond System info), so UScript is more customized to the task in this sense.
  • Scripts are compiled all within the UDK
  • The UDK ships with a range of pre-defined UScript classes in both the sorce-code and a compiled API-like form, all of which are essential to the workings of the UDK and the Unreal Engine. (cough cough half the engine is just UScript extensions to C++ classes) The UScript classes that ship with the UDK define many of the common features available in the Unreal Engine and in the UDK editor including the camera actor, spot lights, point lights, static meshes, materials, Kismet nodes, sound actors and many more.

That last point here, though he actually says it explicitly somewhere else in the book. The engine-compliant file formats for assets (and terrain is an asset) are defined with UScript. Not only can you manipulate static meshes, but you can manipulate the vertices of a static mesh, or create brand new ones, and then call GLSL to dynamically define the material and texture assets of the mesh. Surprised yet? How many scripting languages in level editors can call the shading API? Probably the only reason that the whole engine and editor isn’t written entirely in UScript is because writing a whole new language just to support all of one software package would not be a good software engineering practice nor a good business decision.
However, here’s what you can’t do with UnrealScript:

  • UScript supports two types of classes:

  • Native: Native classes are either wholly or partially coded in C++ and are built into the Unreal Engine, either by being compiled into the engine executable or integrated as a compiled binary

  • Non-native: Entirely within UScript

Developers only have the power to create non-native classes, but the source code can be purchased. For three million-billion dollars.

So, the core algorithms are hidden from you, unless you pay for them. But, the whole damn point here is that UScript is powerful enough to handle any computationally intensive algorithm you want to utilize. I’m pretty sure that there is already a shipped RanNum class too.
So, I mean, if you’re not rejecting the UDK just because its not opensource, but it lacks some functionality, then what specifically is UScript or the UDK itself lacking? I just think you’re gunna be that much closer to an amazing looking game instead of a minecraft clone where the game was more fun to make then to play bcuz it looks ugly as fuck. Anyways, you don’t deserve to be told what to do. But I will tell you that UDK is capable of making a minecraft like game, but with infinitely better graphics, and probably has more functionality then you would ever care to utilize.

So, you see this is an insane amount of control. Probably the most robust flexible scripting langauge for a level editor in the market. And consider the million dollar games that were made with the UDK. All the development companies that “customized” the Unreal engine to suit their particular game, that customization was done through UScript (well, mostly).

EDIT: Oh and also, GUIs can be written in Flash and ScaleForm. I’m assuming that there will at least be some type of GUI the PC uses to select his/her tools (or whatever is used ingme) that will event fire into event listeners in your terrain classes (or something like that).

I’ll try to get a bit into the details of what I am trying to accomplish, as people actually seem interested (I’m a geek, really old school. I’m not used to people paying honest interest to my weird ideas, so bear over with me :slight_smile: ).

Firstly, though, the UDK. While there is no doubt in my mind it could do the things I need, “not open source” means “probably not what I seek”. It’s not a technical thing, it’s a control thing, as in I want the people tampering with this stuff to also contrl it, no commercial interests in control anywhere. You know, freedom of creativity and all that jazz. There’s more to it than that, but that is the core: I want something 100% free and independent, so that everybody can feel a kind of ownership.

Which brings me to the Blender Game Engine. I want so bad to make this my platform. But I have doubts about runtime efficiency; the BGE slows massively if there is a lot on screen. I actually have the math (I think) for making the non-block alterable/destructible terrain in BGE, and I do program Python (in addition to C++, Java and the like), but it’s still a lot of work, and I fear BGE will break under the stress. It’s been a while since I used the BGE, so I do not know of significant advances of late. One cool thing would be if there was an easy way to transfer a succesful project to C++…?

In essence, what I want is the game programming equivalent of Blender (if not in size, but at least in function): A game that can be grown by participation. Open Source engines do this already, but they are very narrow in scope (typically, FPS), and not built to stray from this. I want something built to stray. I am an avid fan of the modding community, especially Minecraft’s, but feel it does not have the open playground it deserves (every MC update, all mods must be rewritten. Many great ones are not…). I have the math and/or concept structure for on-the-fly generated open worlds, complex crafting, dynamic mob growth, AI decisioning and path finding, techtrees, and funny stuff like parkour/martial arts in non parkour/martial arts games, and more. But I am a dunce with syntax, and thus very slow to get it done. I lack “the perfect tool”, in a word.

Maybe I should look at the BGE again. At least I can find help in here for that :slight_smile:

EDIT: Okay, I fiddled with the BGE a little. I think it would require major work to do it with the BGE, simply because it lacks some prime functions. They could be created, but that would probably be close to writing the entire thing in raw Python anyway… tempting though that is…

Yes! So I managed to convince you that the UDK will provide! The UDK is a total slut like that, she’ll do anything you want (expect be open source). But you don’t want to devote yourself to it because its not opensource? Totally understand. Don’t even have to explain that. I run Ubuntu on my machine alongside windows, just so I can boot up Linux and feel badass. My mission is done here. And I have learned something in my attempt to teach. BGE may be different from UDK in a very fundamental way, but to me it seems that they compete for usage in pretty much the same demographic. Plus, although your aims are admirable, I just don’t think there are enough people with similar desire and commitment to form a strong enough demand for software with these specifications. And we’re talking a pretty specialized piece of software that takes a lot of skill and education just to use properly let alone write it, maintain it, or contribute to it. This ain’t no word processor.

Well, you know of the The Blender Game kit book, published 2009? Well its on shelves of some common bookstores, and I bet my bionic implants this book helped a little bit to popularize the BGE, to say the least. And when a piece of opensoft gets attention in whatever media, its way more likely to receive some contributions, isn’t it? I don’t use the BGE so I really wouldn’t know (I may possibly seem like an informative person to you, but the more you talk to me the more you will realize I truly don’t know what I’m talking about). But I would say conclusively test the BGE before you go on a million year journey for an alternative.

Why don’t you just create a terrain viewer/editor and focus on all things terrain first, then integrate a physics module into it to turn it into a game engine? You wouldn’t even have to code a physics module, I’m sure there’s several opensource packages that won’t take long to learn.

I’m not saying it’s a blockbuster, but all it really needs is some creative interest from a handful of people to grow, perhaps not even that. Most of all, though, I just like the open source philosophy, and I want to make this. What I really need is just the best way for me to get a tool that I can squeeze into my all-to-busy schedule to create it with. If I can get those things together, I’m okay not ruling the world or anything, I just want to build bridges, swing on vines, invent laser weapons and maybe chase some villains in an open game world, that can keep on growing as long as anyone has new ideas for it :slight_smile:

i guess no one saw when i posted voxlap. I guess I’ll clear up a couple of questions you may have about it. first the engine is a voxel engine however unlike minecraft it has a much higher resolution to you can get well detailed models on it. second because it uses voxels everything can be destructible. And three it is also open source hasn’t been updated in a while but could be upgraded if you need something it currently doesn’t have. Quick tip it was made by the same guy that made the build engine(the engine they used for the original Doom game), before anyone says anything no john Carmack did not make the engine he however did improve on it a bit from Ken Silverman’s original design.

I actually checked voxlap, sorry for not commenting on that. It is, as you state, voxel based, and quite visibly so. I am not sure if I will end up using a voxel engine if nothing presents itself, or simply continue on the non-voxel engine I have already been sloooowly working on, but I am still really hoping to find something non-block to deal with. Hope is waning, though, since it seems nobody has carried out the idea yet, even if they had it. To get some perspective of what little I have gotten done myself, this is a screenshot. It allows ingame world generation and crafting and all, but the pic clearly shows how much work remains, and why I would really like to find something pre-existing to build on instead. I really wish I could see a way to do it with the BGE, but dangit, open worlds still seem to be an infant game idea… :frowning:

Okay I can understand that, not every body likes the look of voxels at a relatively low resolution.’s hard to get around not using cubes, since game engines like minecraft uses voxels and voxeldata.

Perhaps one idea is to have a procedurally generated voxel grid, convert the voxels to mesh data using the marching cubes algorithm, and finalize everything by using procedural noise, vector displacement, and other mesh generation techniques to create the high resolution details.

You could then have an adaptive system for the voxels that allows high resolution subdivision to allow for things like realistic digging, something which could be used in the initial voxelization stages to create very large voxels for areas that can be described with much less detail.

Now it may be that such a solution would currently be something not supported by the vast majority of engines currently available, you may end up having to continue the path of writing your own in that regard.