TrueCraft, An Open Source Implementation of Minecraft 1.7.3
truecraft.io
truecraft.io
If you had an army of 100 developers, what tasks would you set them to do to improve TrueCraft?
- Building a client with OpenGL
- Implementing world logic (grass growth, door logic, etc)
- Improving terrain generation
It'd be really hard to take on 100 contributors at once, though. In my open source projects, I need time to figure out how each contributor writes code and what they like to work on so I can leverage them appropriately.
There is no support for redstone right now. When support is added, any machines that work on beta 1.7.3 and not on TrueCraft are considered bugs in TrueCraft.
A freely-licensed texture pack would be great, I faced this same problem when developing a different voxel-based game. There are plenty of texture packs available on Minecraft Forums or Curse but very few released under permissive licensing terms, or those that I could find were outdated.
So I made my own, feel free to use it or parts of it if you would like to: https://github.com/deathcap/ProgrammerArt - it is updated for and includes all items and blocks for Minecraft 1.8, available in "resource pack" (1.8-1.6), "texture pack" (1.5), and "stitch pack" (1.4 and earlier, prebuilt texture atlas) formats. It is not the greatest quality artwork I admit, but can serve as a decent placeholder, and best of all is released under CC-BY 4.0 so it can be freely used and distributed. Though if your contributor makes a better free texture pack I'll probably switch =) cheers
Pick some logic you'd like to see work (example: right clicking a door will toggle the door state) and just implement it. Stop by the IRC channel to chat and we can find more things for you to do, too.
FTA: "Most of what Mojang has added since beta 1.7.3 is fluff, life support for a game that was “done” years ago."
I don't know if Minecraft really has ever been done, but I couldn't agree more with the statement that Mojang has just added fluff. I'm amazed at what they accomplished in 2012 and most of 2013, but things seemed to come to a near-halt in 2014...with a major release taking ~8 months that resulted in flags, a handful of new blocks, and still no sign of the oft-requested, oft-promised Mod API.
If there was one feature that would greatly expand the lifespan of the game, it would be a consistent modding interface. Anybody who has been begged by their kids to install a mod knows what a nightmare it can be, just from an end-user standpoint. Why the development team didn't make this top priority remains a mystery.
I can't help but think that once Mojang finished counting their money, they decided to sit on their laurels...Alexander weeping and all that. The Microsoft purchase, while appearing disastrous at first, may be the best thing for the game at this point as the remaining Mojang staff don't appear to be very interested in doing much other than bringing the Xbox version up to PC capabilities. At least Microsoft will want to get their money's worth out of the franchise.
This would be a major improvement to the multi-player experience.
Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks.
Those "fixes" will completely rid the game from "hackers". Witch is the biggest problem with Minecraft (and most other multi-player games).
Orebfuscator or Spigot.
>Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks.
What? No. You can't make sure everyone moves the same way, and this would undoubtedly lead to desyncs. If you want to make sure players don't move too fast, use NoCheatPlus or what it was called.
A far bigger issue for servers is mods like Gammabright which make all blocks have a brightness of 15, thus not requiring you to use torches or light sources, as that's very hard to work around.
Spending a lot of time in the darkness? enjoy blindness, nausea effect and being on fire next time you venture topside while the sun is out.
Quake III was doing server-side calculated game state 16 years ago stupid fast for 32 players moving quickly on dial-up modems; I doubt it'd be much of a problem to do these days with even a lousy architecture for a game with much much slower movement, e.g. Minecraft.
This problem has been solved pretty well many many times before.
But I agree, there is no reason for Minecraft performance to be so bad when there are only 2 people on a server just mining one brick at a time!
Not quite. The map in Minecraft changes. But if you optimize the game for the "constantly changing" case, when it usually changes less than 1 block per user per 10 seconds (and even that is high), then you're going to end up with code that doesn't handle normal behavior very well.
Quake 3 has also got pretty sophisticated client side prediction code to make things seem instantaneous to the players. This is much more complicated to do in Minecraft where the whole terrain may change and lots of race conditions may arise.
Network game code may seem like a solved problem but it's still a complex distributed soft real time software system where solutions are highly application specific. What works for Quake isn't necessarily good for Command and Conquer or Minecraft.
[1] https://github.com/SirCmpwn/TrueCraft/blob/master/README.md
Although, a big part of that (for me) was the soundtrack. Just three short piano tracks by C418. I hope there's some way to include those in TrueCraft.
http://www.howtogeek.com/203196/how-to-change-your-minecraft...
The authentication-related stuff also is broken in most (old) versions, same goes with skins. These can be fixed through mods, though I'm not really sure if it's worth the effort.
TrueCraft seems pretty interesting. I'm always a fan of open source games, and voxel games interest me a bit more than other types of games.
MineTest had/has some potential, though it really needs some polishing. Movement doesn't feel as smooth as in most other games, the textures aren't the best, same goes with the menus. It has a decent modding API, though it's mostly server-based which means there aren't any client-side mods (that I know of).
Terasology is also an interesting open source voxel game, though the overall aesthetic of the game doesn't feel consistent. It has simple Minecraft-like textures, yet fancy effects/shaders. I'm also not a fan of the menus, though that's just me being picky.
I think what makes Minecraft a bit different from these open-source games is how everything is laid out. Movement feels smooth, menus are consistent and simple, the font is legible, the controls are fine, the textures are easy to get used to and the sounds/music are great.
I'm interested in seeing how TrueCraft ends up, if it will be following the style of Minecraft in terms of visuals and gameplay.
There's been no security issues in Java... there been security issues in the java web browser plugin.
Just don't install the plugin. There's zero risk of installing java and playing minecraft.
When held to those standards, Java has been kind of disappointing—repeatedly oscillating between "just about good enough" and "major hole preventing this setup from working." Likewise, many things Javascript got right immediately (like the FS API providing per-origin virtual filesystem containers rather than a view of the actual OS) were never even considered. Despite the marketing, safe execution of untrusted code was never much of a real goal for the platform, and disappeared entirely as a "tentpole" after 1997 or so (despite everyone still remembering the marketing and thinking Java "should" be capable of that.)
When taken as just another bytecode-VM-based runtime platform like the .NET or Erlang runtimes, used for executing code already granted the same level of trust as the other native code on the system, Java is great.
Or let me put it differently - what's the most popular open source client?
TrueCraft is a Minecraft implementation.
It's just the basics - only renders terrain and some static blocks. But it's also based on 1.7.3 protocol.
I've just checked and it kinda works with TrueCraft server: http://i.imgur.com/Brf2NXg.png
Another open source Minecraft-compatible client in the works is https://github.com/thinkofdeath/steven. Written in Go, already decently functional, though still far from finished it is under active development and progressing nicely. Not that popular yet but seems to be promising to me. The author is a major contributor to one of the most popular Minecraft server software packages.
May dictate how you guys choose to build your product moving forward (you gotta love building something for fun that potentially leads to something more lucrative!)
As a mod developer, my plan on revitalizing Minecraft and making it more of a sandbox again was always centered about designing a modpack going in that direction - I've been working on it since December.
I don't really feel splitting the community into twenty reimplementations is a good idea myself, though.
Eager to investigate modding this.
Still, nice job.
What would you have done it in? C, and never get any contributor? Or Java, and do as bad as the original?
If your main goal is to get as many contributors as possible, perhaps JavaScript would be the best choice.
And I'm still not convinced that Java is the main cause the original Minecraft was bad.
Although I write all my games in C++ (native) and JavaScript (web) I did some Java games for Android and the language is rarely the bottleneck if you are careful about object life-cycles. The main bottleneck is usually the graphics hardware.
I'm not saying that C# is bad choice. Actually I think it is a good choice, just not for the reasons you state.
I didn't mean to say C++ would have been a bad choice, I was mocking the recurring mentality that a project is only good if it's in C (or even lower-level languages). It's quite tiresome to deal with it, I'm sorry it didn't quite get through.
Java was definitely one of the reasons the original Minecraft was bad though. It (along with bad architecture) was the reason behind the massive server footprint and why hosting minecraft servers is extremely expensive and completely unscalable.
Hey, remember when Notch said he'd open source Minecraft once he was done with it? I remember...
No. It wasn't Java.
The reasons are many, but here's some: All world logic happens in a single thread (fixed in Minecraft 1.8, now there's a thread per world). Entity lookups are very badly coded (mitigated, but not fixed by CoFHCore which explicitly excludes dropped items from the lookups). There are many bad coding decisions made throughout Minecraft (a nice amount of them is fixed by FastCraft, which optimizes Minecraft and reduces its RAM usage by ~300MB; OptiFine used to be good for the GPU but 1.7/1.8 integrated most of its fixes). Every neighboring block/tile entity access loads that neighboring chunk, then marks it as unused, then unloads it every 30 seconds (not a huge issue in MC itself unless you use a lot of pistons, but a massive issue for modded servers)
Etc, etc, etc. It is possible to scale Minecraft, however nowadays it is not possible to scale Minecraft without mods and at least a basic knowledge of how the engine works.
There was an experimental mod made by nallar in 2013 which dynamically ASM-patched Minecraft and every mod to make all world logic fully threaded in multiple worker threads, as well as a separate thread for chat; however, that was really hard to maintain in practice, especially as mods grew more and more complex.
A commonly used method is to run multiple instances of Minecraft servers and use a proxy glue server like BungeeCord to treat them as separate world on one server.
I'm well aware of all those efforts. I'm also well aware of the insanity behind them and just how much effort was required for it all. Java really didn't help the entire matter.
Interesting.
Jesus on a bike.
We aren't god damn unicorns.
Hi, I just wanted to mention I have started such a project: https://github.com/deathcap/voxel-clientmc - a Minecraft-compatible client written in JavaScript.
It sure could use more contributors =) help welcome if anyone is interested. Currently not many features are implemented, but you can connect to a Minecraft server (works with the official Minecraft server and its modifications, but I usually test with Glowstone or Glowstone++ for a 100% open source stack) in your web browser via the WebSocket/Minecraft proxy https://github.com/deathcap/wsmc. The protocol decoding is implemented by PrismarineJS https://github.com/PrismarineJS/node-minecraft-protocol, much of the client logic by mineflayer, and the WebGL voxel rendering using http://voxeljs.com.
JavaScript has some interesting benefits for game development, I enjoy its dynamicism; plugin loading is a breeze. Since it is already a "scripting" language, it is easily modifiable by third-parties. Some game engines have taken to implementing a second language runtime, for example Minetest and MC-Server are written in C++ but allow addon development in Lua. The Minecraft modifications ComputerCraft and OpenComputers also allow in-game programming using Lua. ScriptCraft, a CanaryMod plugin for Minecraft, allows writing plugins in JavaScript. etc. But when everything is written in JavaScript, there is no platform/addon dichotomy. In voxel.js (especially https://github.com/deathcap/voxel-engine-stackgl), much of the core functionality is even implemented in "plugins".
You mean the third best-selling game of all time? Yeah, they could've done much better if they used C++.
But if its your preferred language and framework then I say have at it. It's your project you should be able to enjoy working on it.
> A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011).
> To get started, sign the Contributor License Agreement to establish that you have not, in fact, ever read decompiled Minecraft code.
> 'Clean room design is the method of copying a design by reverse engineering and then recreating it'
Not sure why it makes sense to say in the repo you reverse engineered it but then make contributors sign an agreement saying they havent read decompiled mc source.
Reverse engineering is a very broad term, but generally involves analysis of decompiled source, no?
Not necessarily. If you are reverse-engineering a file format for the purposes of reading and writing files compatible with the software, oftentimes you start by using the software to generate multiple files with small changes. Your analysis is limited to the output generated by the software, not the actual software itself (you treat the software as a black box).
There are exceptions, though, and it's worth people being aware of whether or not it is legal in their country, but the biggest risk with reverse engineering generally is not the legality of reverse engineering itself, but that it makes it harder to justify yourself if the newly written code happens to look surprisingly like the original code.
It is not unusual for people to come up with very similar structured code if the code is largely dictated by the same functionality and requirements, and then it's easier if everyone involved can truthfully say they have never seen how the original did it.
If you are looking for an open source Minecraft-compatible implementation in Java, I humbly suggest (shameless plug) checking out https://github.com/GlowstonePlusPlus/GlowstonePlusPlus. Glowstone++ like TrueCraft currently only implements the server portion, and it has some differences such as targeting 1.8.4 compatibility not 1.7.3 beta, but being implemented in Java has some significant benefits.
For those not aware there is a huge ecosystem of additions available for Minecraft written in Java. This includes thousands of "Bukkit plugins" available from http://dev.bukkit.org/categories/, Spigot plugins from http://www.spigotmc.org/resources/, and now an emerging community of Sponge plugins from https://forums.spongepowered.org/c/plugins/plugin-releases. Writing Minecraft-compatible software in Java has the advantage of being able to potentially support these plugins. Glowstone++ in fact implements much of the Bukkit API and Spigot API, as well as (currently a small subset of) the Sponge API through a bridge. Based on the original Glowstone server, Glowstone++ is completely open source, yet it ties into the existing "Minecraft" plugin development ecosystem.
Java has some disadvantages of course as well, so it's good to see alternative implementations in other languages (not only C# TrueCraft, but C++ MC-Server, Rust Hematite, JavaScript PrismarineJS, etc). The more choice the better =)