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.
If I'm not mistaken you're using the original Minecraft's textures. I would suggest switching to something that isn't copyrighted by Mojang to avoid issues.
As xlib said, the screenshots were taken with the official client. I have a contributor who is working on a free (as in freedom) texture pack that we can use when we start working on the client.
> As xlib said, the screenshots were taken with the official client. I have a contributor who is working on a free (as in freedom) texture pack that we can use when we start working on the client.
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
- 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.
I'm eligible for contribution, since I've never looked at decompiled Minecraft code. I haven't touched C# in over ten years, though, so that might be something of an impediment.
I used to be really active within the redstone scene back then. A lot of projects we made, such as computers, relied on the fact that we could made 1 tick busses by abusing a bug with pistons. Are things like that implemented in this project?
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.
It's been a while since I've done any redstone but from what I remember there were quite a few bugs/glitches. Large complex redstone machines (that served no real purpose in a game like Minecraft) depended on those. I'm really looking forward to going in and seeing how well my old contraptions run and building crazy stuff.
As someone who has spent some time playing Minecraft (and has kids who have spent even more time doing so), I'm really happy to see this effort.
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.
I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it.
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).
>I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it.
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.
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.
The speed of light has not improved since the days of Quake 3. Network gaming code must still be tolerant of latency up to 100 ms or more. At best, network connections today are a lot better than back then but at worst, they are as bad as they used to.
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.
The big difference is that the map in Minecraft is constantly changing which can in turn change players position and potential actions - Quake 3 was comparitively much simpler, more or less just a coordinate and velocity vector.
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!
> The big difference is that the map in Minecraft is constantly changing
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.
Mining time can actually be incredibly low in some cases. With a max efficiency enchanted diamond pickaxe, for example, you can practically swim through netherrack. With the optimization you suggest they would be noticeable lag.
Etho does something he calls speed mining. This involves max enchanted picks (efficiencyV), and beacons set to hasteII and speedII It's very fast. And leaves a lot of entities around.
I'd rather have effort spent on making the game funner for those who play legit. Especially since many of those anti-hacks, if implemented in the wrong way, make mods more difficult. Nothing like working up a mod tech tree to get flying/super speed to have it boot you ever 4th time you use it.
Could you at least add explanations on how to compile your thing on different platforms? All this code is really nice, but if it doesn't actually compile and do something it's quite pointless. Besides, bear in mind that not everyone is running on Windows on this planet.
Glad to see someone is doing this. Early Minecraft was so beautiful in its simplicity.
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.
Though multiplayer on these versions is dead for the most part, for obvious reasons.
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.
Cool project! Can't wait to see a pure .NET client with OpenGL down the road. I don't install Java on anything anymore (mostly due to all the security issues) so I haven't played Minecraft in years.
Java was originally marketed as a secure VM sandbox allowing for untrusted mobile code execution: centrally web "applets", but also zero-install desktop apps. Basically, it was attempting to do what Javascript (especially with ASM.js coupled to a browser's desktop-app integrations) eventually succeeded at doing.
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.
There's a Rust client in the making called Hematite[1], but it currently will only allow you to move around static worlds, with no other interaction. The focus so far has been on making the rendering as close to pixel-per-pixel identical as possible: [2]
> Or let me put it differently - what's the most popular open source client?
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.
Huh - so, I'd wager that Minetest is the most popular open source thing that's KIND OF like a Minecraft client, but your point is that it's not ACTUALLY a Minecraft client, right?
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.
It runs on Windows, Linux, OS X, and BSD, and probably more platforms if you tried hard enough. Build instructions are in the README. I do most of my development on Linux.
Yes? It seems like a good choice. Maybe 6 months ago I would have said it's foolish, but with C# being an actual open language now, I'd say it's a rock solid choice.
What would you have done it in? C, and never get any contributor? Or Java, and do as bad as the original?
Take a loot at some open source projects. The Battle For Wesnoth (c++) has many more contributors than FreeCol (Java). I'm sure that number of C# developers in the world who develop open source stuff is even smaller.
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.
Fair enough, though I didn't mean to imply those were the only good reasons.
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...
>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.
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.
And guns don't kill people, they just make it very easy to do so.
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.
I'm not looking for a bunch of contributors, for what it's worth. I specifically alienate a large group of potential contributors by forbidding anyone who's read decompiled source from contributing.
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".
Yeah, I'm a little let down this isn't in C++. Also, I'm not sure how open .Net actually is but it is cross platformish so not a bad choice. Though I imagine that .Net and Java would have share the same sort of performance issues.
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.
I chose C# for the cross platform nature of it, the strong OO model, the pluggability, and my large established base of Minecraft code in C# to draw from. All of these things make it a strong candidate for a project like TrueCraft.
Actually, I don't really care what language. I was mostly making a comment on the lack of detail of the post. I had to click all the way down to the source code to see what language it was in, which to me seemed like the most important aspect of this entire project.
It seems to be a wrong choice to me, here's why. There is a lot of mods for Minecraft that use unofficial Forge API. If this project reimplemented Minecraft and made a similar API, many of the mods could be ported to 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?
> 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).
Reverse engineering is usually illegal, but trying to reproduce the behavior of said software by trial and error is not. That's why they mark the difference.
Reverse engineering is legal in a large number of countries - I'm not so sure it's accurate to say it is "usually illegal".
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 =)
Garbage collection pauses work very much fine on a heavily modded server I monitor as part of BuildCraft development. The server, with its 40+ mods and about 20 thousand tile entities running at any given time generates about 50-100MB of objects every second. In fact, Minecraft's own explicit chunk GC is MUCH slower than Java's and causes actual 2-3 second pauses!
