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).
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??
it’s hard to get around not using cubes, since game engines like minecraft uses voxels and voxeldata.