Like I said, I'm not too familiar with game development but I do have a basic understanding of software development.
I was just saying that I was expecting the process to be more along the lines of building the basic game and then adding things to it in order of priority as those things are finished. So after building the bare bones game you add a GUI, which opens the door to conversations (Which opens up quests), and inventory (Which opens up crafting and trading). You add features that are the most important and have the greatest number of important features dependent on them, focusing on one thing at a time per person.
What you are describing there is a programming process known as Procedural Programming, also called Imperative, where the program is going through the steps one by one basically. So everything basically requires everything else to run. This is a fine method of programming if you are careful, slow and methodical, if you want fast development, you go more object oriented.
What they are doing is basically this. From low level to high level.
Code the renderer class
--Includes standard functions like printing to the screen, refreshing it, etc, etc.
Code the "object" class
--Everything is an object, in the most likely case, in Minecraft air tiles are an object, but that's because minecraft is a voxel state machine, I'm betting that Starbound is as well. So in essence what they are doing here is laying the groundwork for the things that are rendered, but not relying on the renderer class for them to exist. Printing an object into the render stream is an example of functions here. Making sure an object is passable or impassable is also a function here.
Bunch more subclasses here things like physics and animation
Code the Item Class
--Includes the metadata of an item, things like generating metadata like, "This is an item of type gun, and ID 000f12bc. With background text, "I have had it with these motherfucking snakes in my motherfucking gun"" would be here. This doesn't include things like passing the item to the renderer, but instead the metadata is generally checked by the object class and then sent to the Renderer for rendering with proper gameplay data applied.
And so on. What this set up does is prevent conflicts where items have the same ID, or where item code relies on Object code which relies on render code, and then you change something in the renderer class and it causing everything to go tits up. Instead just the renderer goes tits up and you fix that and your code works. It also enables the use of multiple developers on a single project, before you'd basically have to sit down and read all of the changes to all the files, which may or may not have been written down, and required a flowchart to understand. Now you just split files off of each other, Oh, we have a file dedicated to each gui window, a file dedicated to the object class, a file dedicated to the renderer class, a file dedicated to the item class. So you just have people work on different files and it's basically fine. This is why in the earlier stages of something like a pre-rage ID engine demo, you literally just have John Carmack and maybe one other programmer Carmack trusts implicitly, working on it. Because it's faster and easier than having 20, in terms of the early stages.
I FIGURED OUT A BETTER WAY TO SAY THAT/NINJA EDIT: Object oriented programming basically helps prevent your code from tantrum spiraling.
What I understood from the conversation they just ran through and made everything, and now they have to glue it all together. If all they're doing is fine tuning, adding extra features, and making sure it doesn't explode, that's cool and I just misunderstood.
As for the x64 thing - It's nice for any game to be able to use x64, even if it's not strictly necessary by the scope of the game. I doubt Starbound will take up a massive amount of memory since you'll only be loading up one area at a time. Multiplayer may be different, and may be the entire reason they're building for x64. Even if that's not the case, just having the capability can avoid a lot of issues if they decide to expand on memory hungry features.
x64 is always good to have, especially in cases like Starbound where I hope at very least you will be able to set up some sort of auto miner on a planet and leave to explore another one.
Also road map was updated once from what I recall, then was basically abandoned as too hard to maintain. Can't find a source on that though, may have been an IRC chat.
Author
Topic: Starbound - We have lift off. (Read 943923 times)