I’ve moved to unifiedprogramming.wordpress.com. Much of the content is in draft form right now, but it will continue to be updated with new content every week.
I’ve been recently been working with a group of coders on github on a custom C++ minecraft server called MCServer. We’ve gotten pretty far, and we will soon be making a huge leap forward with a rewrite of the AI. However, as I’ve been working on it, I’ve been musing over what it would take to implement a custom minecraft client.
I really want to make it. It would be fully compatible with a vanilla server, and be built in such a way that it could easily be compatible with forge. I’ve already figured out how to handle the rendering of all of the chunks, entities, etc., but one thing I am struggling with right now is finding a list of the packets sent during the login sequence, in the order of which they are sent and received. If anyone knows of an up-to-date list, please let me know
So what would make it better?
- Faster. More chunks can be rendered at a time, which increases sight distance.
- Builtin support for high definition resource packs.
- Better handling of character movement so the player will no longer just look like he has no knees or elbows.
- Plugin Interface. I know the guys at Mojang are working on theirs, but they’ve been slow in its development.
- Better rendering of transparent blocks.
- Better looking water.
- Builtin support for rendering custom monsters, blocks, particles, GUIs, etc.
That’s just a few of the things that I have planned. If y’all can think of anything else that the minecraft client could improve on, let me know in the comments.
Neural Networks are not going to work until we understand how the brain works. We know that neurons transmit signals, and that depending on how they are interconnected they cause our bodies to do different tasks.
However, that is the extent of our understanding of the entire system. Some scientists have proposed that our actions are the result of random firing of neurons in the brain, along with the interpretation of sensory input. In other words, they believe us to be a pattern-matching machine that has its state influenced by a random number generator. I’m pretty certain that is incorrect, but it would take me having a P.H.D in Artificial Intelligence before anyone in the scientific community would recognize my work.
So instead of getting myself a P.H.D., I am going to do an experiment like any good scientist would. Instead of trying to mimic the brain and how it works, or trying to mimic the psyche, I am going to start from scratch. I am going to build an virtual machine and pump into it a whole bunch of entities, each of which is composed of randomly generated code. Those entities that run without crashing will be selected to move to the next round, and any “dead” entities will be replaced with newly generated ones. This will continue until I have at least 100 entities that do not crash.
Once the main pool of entities is established, the entities will be paired up. Each pairing will produce 1 to 4 child entities that are composed of sections of the parents code. Each child will have up to 100 chances during generation to receive a mutation in their code, though the chances of a mutation happening will be quite small. A mutation is the flipping of a single bit in the code.
Any child entities that crash will be considered dead and not used in the creation of the next generation.
All of the original entities will have their code saved. For child entities, references to their parents’ code will be stored, along with any mutations that took place.
Penalties will be placed on entities that have excessive amounts of unreachable code. They will have a lesser chance of being selected for the creation of child entities. What the definition of excessive code is I do not know yet, but I will need to implement it to keep code bloat down.
I’m still working out all of the details, so any of this should be considered preliminary. Wish me luck!
Well, school is finally out for the semester. I finally have time to start posting again!
Currently I am working on a proof-of-concept for an objective-c implementation of Minecraft, both client and server, that runs faster and more efficiently than the original, and implements a dynamic plugin interface along with some other things. Hopefully by the end of this month I will have something to showcase on youtube.
Recently I was browsing Hackaday and ran across an article about a deveopment board sporting a coprocessor touting 16 to 64 cores. It’s a kickstarter project by Adapteva, and they are trying to reach $750,000. They are trying to raise this money so that they can provide the boards and chips for around $99.
The $99 dollar reward for the kickstarter is a 16-core board, and the $199 is two 16-core boards, or if they reach their stretch goal, a 64-core board. Their stretch goal is three million dollars.
I love the idea of programming in parallel, and I really love the idea of computers being designed for parallel computing. So I am starting to teach myself OpenCL to prepare for the board that I am getting for my support.
I have been taking a break from my kernel. After a while of being the only developer on a project, I have to let my mind take a break from it so I can work on all of the other things I have going.
And so I got bored because I couldn’t decide which one I should do. Kinda stank like the inside of a Tauntaun.
Needless to say, I am no longer bored.
The DMG is now available on the Downloads page.