Collaborative Project: MARS MINER - Developers

[IMG]http://i.imgur.com/2sk8Q.png[/IMG] Due to Facepunch's flawless history in terms of collaborative programming projects I thought I would start another. Here's some quotes describing the overall idea for the game, but it is free to manipulation as we go along. [QUOTE=Ziks;34175470]Is anyone up for trying a group project again? I've had a game idea that's been bugging me for a while now, and I've been finding solo development on past projects a bit boring. The general idea is a Mars colony simulator, with a focus on mining for minerals. Ideally it would be an Infiniminer / Minecraft clone on Mars with a basic atmosphere model (think SpaceBuild), and optimally cooperative multiplayer. This can obviously be simplified to perhaps just being isometric, or top down tile based, or even down to an ASCII graphics Dwarf Fortress like game. Multiplayer would be fantastic, and I have some experience of networked game programming, but we can always sacrifice that for simplicity. If no-one's interested then I'll probably just start on my own, but I would really enjoy working with a group of programmers from the start. If anyone would like to know more about how I've been imagining the gameplay then I'll happily describe what I've been thinking about. Before I get relegated to Ideas Guy status, I will be doing a lot of the programming myself, and I have written a basic Minecraft clone, a networked RPG (Lewt) and the lighting simulator you might have seen at the end of the last thread. I would just love the opportunity to collaborate. Oh and it would probably be C# + OpenTK and Git. [editline]12th January 2012[/editline] We can always give it a try and you can drop out when we don't get anywhere with it.[/QUOTE] [QUOTE=Ziks;34176616]At the start we could just focus on rendering, then world generation, and then gradually adding more content and systems as we go along. If we were to go the whole way, I would imagine it to become a cross between OpenTTD and Minecraft. The world is cube based, with a cube being about half a metre in each dimension. The server would generate a reasonably large finite map, a square of the surface of Mars. The generator wouldn't have to be too complex, just a simplex noise heightmap with procedural craters and a few dried up rivers / chasms. A few patches of water ice would be placed on the surface in craters and such. Underground there will be seams of random minerals, more ice and so on. You will play the roll of an employee of one of the newly founded extra terrestrial mining corporations, who plan to set up a new mining colony on a recently prospected area of Mars found to be rich in rare metals. On joining a server you will be presented with an overview map, and a list of the current active colonies on that map. You can choose to start a new colony, or join an existing one (like OpenTTD). If you start a new colony you can choose where on the map your shuttle will touch down. The initial shuttle you arrive in will contain a moderate amount of supplies, such as water, stored electricity, food, oxygen, and building materials. Also on board is an automated crafting station, where you can create machinery and tools if you have the right materials. You'll first want to get some power generation going, which can be achieved by placing some solar panels somewhere on the surface and linking them up to the shuttle's batteries. Most machinery you build will need a power supply while operating, so a reliable supply of energy is essential. Power, fluids and gasses, and solid materials can be transported using cables, piping and conveyors respectively. Next you will need a way of producing more oxygen, which can be achieved by placing a water extracting device next to some ice. This requires power to operate, and outputs water. This can be piped to an electrolysis device, which again requires power and outputs hydrogen and oxygen. Oxygen can also be produced (but very slowly) later on by plants in greenhouses, which are also a source of food if we were to include hunger and thirst as properties of your character. Shelter can be constructed by placing wall, floor and ceiling panels. We will have to develop a system to detect each air tight volume, and store an oxygen level, possibly temperature and even the levels of each gas present in the game like hydrogen if we wanted to go that far. Air vents can be placed on walls or ceilings that are fed power and oxygen, that regulate the oxygen levels inside the volume they are placed in. If we simulate temperature then an aircon unit requiring just power would do the same for the room's temperature. You're character's suit oxygen level will refill if there is sufficient oxygen in the room. Mining can be performed with either hand held mining drills or automated mining bots. For mining bots, a bot station is placed that the bot recharges at and dumps the material it mines. You would program the bot to mine out a rectangle of a size chosen by the player, and then only need to interact with it when you want to give it a new program or to repair it when it occasionally A conveyor can transport materials from the bot station, which move in chunks of one block's worth of material at a time. The conveyors can be branched based on which material they carry, so you could send all the useless rock to be piled up somewhere on the surface and each metal ore to a respective smelter. Some devices like doors and lights will accept inputs, and others like switches will generate outputs. Each input accepting device can be given a name or will have an address or similar, and output giving devices will be given a list of devices to output to. In order for a signal to be sent from an output to an input they must be connected by a network cable, although different signals with different sources and destinations can use the same cable network. You could build an automated airlock with a cycle switch that will only open the exterior door when the interior one is closed, and only opens the interior when the exterior is closed and the oxygen level is high enough. The overall aim would be to make more profit than the other colonies operating on the same map, or if there is just one colony, to just make as much profit as possible. A shuttle will arrive every few days, where you sell minerals you have mined and can buy any supplies you desperately need. Eventually you would want the colony to be self sufficient, and even have most of the mining process automated. Every so often there will be a minor disaster, such as a random machine breaking down or a small meteor hitting somewhere on the map. You will want to make sure that your base is well partitioned with airlocks to minimise damage from the exterior wall being compromised. Different, and overall better, materials will be found the deeper you dig, but eventually you will discover some remains of an ancient alien civilisation deep underground. Not sure where to go with that though, but it would be cool. As I said before, we could simplify it a ton to make it easier, but I don't think there is anything above that we would struggle with too much. The general idea is Mars Mining Colony Tycoon, with preferably an Infiniminer style viewpoint but anything down to ASCII will still work. There's probably a bunch of stuff I forgot, I hadn't written any of the ideas down before now.[/QUOTE] Place your bets for how long this will last! [release][B]Feature / Todo list:[/B] - will be updated later * [I]Octree class[/I] - [B]done[/B] * [I]Rendering from the tree[/I] - [B]done[/B] * [I]World generation tests[/I] - [B]done[/B] * [I]Design structure of blocks / what information they contain[/I] - [B]done[/B] * [I]Render blocks with textures[/I] - [B]done[/B] * Design Entity class * Build component system for use with entities * Design networking structure * Server generates map, then sends to connecting clients * Create physics component for Entity / world collision detection / resolution * Create network component for Entity to synchronise client and server entities * Create player entity, and be able to walk around on a server * Add more things to do[/release] [release][B]Repository location:[/B] [URL]https://github.com/Metapyziks/MarsMiner[/URL][/release] [release][B]Current collaborators:[/B] - just ask and I'll add you to the list [URL="https://github.com/Metapyziks"]Ziks[/URL] [URL="https://github.com/Tamschi"]Tamschi[/URL][/release] [release][B]Some progress images:[/B] [T]http://i.imgur.com/r88f4.png[/T][T]http://i.imgur.com/HbKj3.png[/T][T]http://i.imgur.com/ht2Zf.png[/T][/release] [editline]14th January 2012[/editline] The next thing (apart from a few tweaks to the Octree system that I'll be working on) is to work out how we are going to describe blocks. Naturally there will be a enum for block type, and I guess we are going to have slopes so the terrain is generally smooth, so we'll have to store what slope type each block is. Are we going to have anything that isn't either a slope or flat? Like the "block entities" in Minecraft (switches, doors etc), or shall we not store them as blocks.

I fully support this project. Recently I've been using C# with OpenTK although I probably won't join the project, since you seem to know far more about OpenTK than I do. That means the project will be a huge learning source for me, though. (decent OpenTK tutorials are nowhere to be found) Good luck!

Is this going to have lua scripting? That would be p sweet. [editline]14th January 2012[/editline] Because I think we all agreed that Lua makes everything better.

Thank you for your support. I'm fairly new with OpenTK too, but if you don't feel comfortable using it then there are still the non graphics oriented parts of the project. I admit that at the moment there isn't much to do since I'm still planning out the groundwork. I'll always need people checking what I'm doing and spotting any improvements that can be made at this stage though. When the basic world and entity systems are in place then we can really get the project started.

[QUOTE=BlkDucky;34208313]Is this going to have lua scripting? That would be p sweet. [editline]14th January 2012[/editline] Because I think we all agreed that Lua makes everything better.[/QUOTE] amc will post in this thread in 3... 2... 1...

I think I'll help. We'll see how much work there is after school starts again.

[QUOTE=Ziks;34208000]Naturally there will be a enum for block type, and I guess we are going to have slopes so the terrain is generally smooth, so we'll have to store what slope type each block is.[/QUOTE] But a reference to an enum takes 4-8 bytes (depending on 32bit or 64bit VM I guess) and I don't think there will be more than 255 blocks (or 65536 for 2 bytes/block). Although maybe using an octtree reduces memory usage enough that this doesn't matter anymore. Minecraft is using 1 byte/block and is using tons of RAM though. [QUOTE=BlkDucky;34208313]Is this going to have lua scripting? That would be p sweet. [editline]14th January 2012[/editline] Because I think we all agreed that Lua makes everything better.[/QUOTE] Why not use C# as the scripting language? It's a .NET project after all.

Doesn't using this reduce the size at all? [csharp]enum BlockType : byte {[/csharp]

[QUOTE=Ziks;34208952]Doesn't using this reduce the size at all? [csharp]enum BlockType : byte {[/csharp][/QUOTE] If you are using numbers to represent block types (which you obviously will), it's a good idea to use per-save-file enumerations. For example (JSON): [code]{ ... "blockTypes": [ "Air", "Dirt", "Rock", "Bananas", "LavaModMainBlockOrSomething", ], ... }[/code] This allows for mods to installed and removed without the need to create new maps. In Minecraft, various mod loaders allocate block IDs at runtime, which causes the block IDs in existing maps to become misaligned and load as incorrect block types. [editline]blah[/editline] Mods (and engine internals?) would simply call: [code] this.BlockType_Cactus = BlockTypeManager::AllocateBlockType("PlantMod_Cactus"); [/code] (no idea if that's valid C#... haven't touched it for years)

Good point, may as well use an UInt16 for block IDs then to make sure we have plenty of space for mods to use.

This project just makes me giddy

[QUOTE=Ziks;34208952]Doesn't using this reduce the size at all? [csharp]enum BlockType : byte {[/csharp][/QUOTE] Fields in classes are usually padded so they don't cross a 4 byte border on x86 or (probably) a 8 byte border on x64 machines. You can set it to sequential (no packing) with [url]StructLayoutAttribute[/url] if all fields are [URL="http://msdn.microsoft.com/en-us/library/75dwhxf7.aspx"]blittable[/URL]. If you have references as fields, you can use an explicit layout. The reference size differs by platform, but that shouldn't matter if there's only one at the end. Instances on the heap will always be aligned to the pointer size, so changing block ids from byte to ushort won't increase the size. A good way to reduce the octree size would be not to store the position in each node. It doesn't seem to be used outside of recursive calls, so calculating it when it's needed is probably faster than resolving the reference anyway. [QUOTE=Ziks;34209378]Good point, may as well use an UInt16 for block IDs then to make sure we have plenty of space for mods to use.[/QUOTE] Sounds good. Serialized octree nodes should take up 10 to 18 bits that way. (The 256 most common blocks can be stored with two flags (one for IsLeaf, one for HasUshortId) and one byte for the ids). If the octree isn't saved with LODs, nodes with children are only 1 bit. The tree can't be modified if it's saved that way, so it only for the game saves. I started sketching a file format, but it's only a very rough draft so far. If chunks get changed flags for each octree, I can make the format incremental. It should also be transactional, so the writes either complete or are ignored on load.

[QUOTE=Tamschi;34212556]A good way to reduce the octree size would be not to store the position in each node. It doesn't seem to be used outside of recursive calls, so calculating it when it's needed is probably faster than resolving the reference anyway.[/QUOTE] I've done this to the best of my ability, and the size has been reduced by quite a lot. For things like setting volumes in the tree it seems to be faster, and the other actions I'll rewrite later to be a bit more efficient (for example in order to find the neighbour of a leaf I recurse back to the root of the tree, work back to find the original leaf's position, then recurse back to the root again and start working down finding the leaf's neighbour. This can be quite easily halved). I'll be unable to work on it for a couple of days, but if anyone wants to have a shot at rewriting the FindNeighbour() method then go right ahead. That sort of reminds me, I should start commenting methods because they might need some explanation.

I had a similar idea after seeing a video of Mars, never got nearly as far as you did. I wish you good luck and I can't wait to see further updates.

I finished the first draft for the save format: [URL="https://github.com/Tamschi/MarsMiner/blob/saving-v0/MarsMiner.Saving/Save%20Format%20V0%20Draft.txt"]Save Format V0 draft.txt[/URL] (Now on GitHub) The format is transactional and supports incremental writes, the downside is that it can fragment with a worst case of a bit less than 1:1 garbage:used ratio (only if all octrees change). Blob size is limited to around 2GB, so if we ever exceed that it will create a small pointer file and start the next blob :v: I'll start implementing this as MarsMiner.Saving.dll now, so tools can use this without referencing MarsMiner.exe if they only do save file operations. I don't think we should make any entities blocks: Tile entities are too small and too few to benefit from the sparse octree and will probably have attached states and scripts for each instance. We can use [URL="http://jitter-physics.com/phpBB3/index.php"]Jitter Physics[/URL] for actor and entity movement. It's an open source physics engine (zlib license) written in C# that supports multi-threading and efficient triangle mesh collisions. It has a very clean interface and can use a custom broadphase, so if the triangle mesh is not fast enough at some point, we can override it to collide with the octree directly.

I was just about to suggest Jitter Physics as the physics engine. It's CLS compatible, so as long as Mono can run on a system, so can Jitter. [editline]14th January 2012[/editline] also I would recommend licensing the project before you get a bunch of collaborators to avoid confusion over who owns the code.

[QUOTE=Tamschi;34219668]I finished the first draft for the save format: [URL="https://github.com/Tamschi/MarsMiner/blob/saving-v0/MarsMiner.Saving/Save%20Format%20V0%20Draft.txt"]Save Format V0 draft.txt[/URL] (Now on GitHub) The format is transactional and supports incremental writes, the downside is that it can fragment with a worst case of a bit less than 1:1 garbage:used ratio (only if all octrees change). Blob size is limited to around 2GB, so if we ever exceed that it will create a small pointer file and start the next blob :v: I'll start implementing this as MarsMiner.Saving.dll now, so tools can use this without referencing MarsMiner.exe if they only do save file operations.[/QUOTE] Excellent work. I was thinking of just setting up some basic AABB physics (for one last chance at doing them perfectly), but I guess if we use Jitter we can both save time and simulate more complex situations than just cuboids colliding. I suppose we can always tell Jitter to keep axis aligned too. I have a couple of hours before I leave, so I'll sort out the license now. [editline]15th January 2012[/editline] Shall we go with MIT?

I personally prefer zlib, but it's essentially the same thing as MIT.

Got distracted and rewrote the note searching methods, and holyshit it's fast now. [editline]15th January 2012[/editline] Should I put it in the header of the main source file, or in a LICENSE file? I'm a bit new to licensing code.

At the very least include a LICENSE file. I've seen a lot of open source projects slap the license as a comment at the top of every source file in the project, and I do that myself: [url]https://github.com/Robmaister/YetAnotherMinesweeper[/url]

[QUOTE=Ziks;34221241]Got distracted and rewrote the note searching methods, and holyshit it's fast now. [editline]15th January 2012[/editline] Should I put it in the header of the main source file, or in a LICENSE file? I'm a bit new to licensing code.[/QUOTE] When you GPL things, you usually put the full text into the LICENSE file and a shorter comment on top of each source file with the authors and respective years in wich they worked on that file. The MIT is a lot shorter, so it's probably the same with the full license in every file.

For the main LICENSE file should I put just my name, or try and reference that it's a group working on this (the Mars Miner team)?

[QUOTE=Ziks;34221375]For the main LICENSE file should I put just my name, or try and reference that it's a group working on this (the Mars Miner team)?[/QUOTE] As "The Mars Miner Team" is probably not a legal entity, I'd say just add your name and everyone else add theirs as part of their first commit. Edit: MIT is copyfree, so if someone signs the main license, it should mean that they can't claim exclusive ownership on any part of the program in the future. No guarantees on any of this though :wink:

Done. I'll write a quick script to add it to the start of each file too when I've eaten.

I have no idea what's what when it comes to licensing and such.. so this is just a layman's suggestion: Why not follow the legal choices of Linux, and use GPL? It has countless contributors, and I haven't heard of any major legal battles over ownership. [editline]![/editline] [QUOTE=danharibo;34223495]I think you mean GPL.[/QUOTE] Whoops, thank you.

[QUOTE=Deco Da Man;34222849]I have no idea what's what when it comes to licensing and such.. so this is just a layman's suggestion: Why not follow the legal choices of Linux, and use GNU? It has countless contributors, and I haven't heard of any major legal battles over ownership.[/QUOTE] I think you mean GPL.

I think ownership is a separate issue from licensing?

[QUOTE=ROBO_DONUT;34223716]I think ownership is a separate issue from licensing?[/QUOTE] Yes, Copyright is unrelated to licensing. Magnetite is currently licensed under the GPL as I would like contribution to be fed back into the main tree.

[QUOTE=ROBO_DONUT;34223716]I think ownership is a separate issue from licensing?[/QUOTE] Yes, but licensing is usually used to resolve ownership issues if ownership itself isn't tranferable, like the German Urheberrecht. I'd prefer the GPL too. zlib may be a bit problematic under German law... zlib's liability clause may be invalid here too, as there's no such thing as public domain or no-liability. There's a reason the GPL's warranty and liability clauses are at least three times as long as zlib's.

Apparently you can't be a programmer until you've gotten a degree in IP law.