I have a way to explain the SSP-SMP thing. If anyone has ever played Halo, you can join other people's games. I'm guessing you can choose if you want people to join your game in the new update. That's basically what Minecraft is going to do.
I certainly dont want to take a lag/error/lack of mods whatever hit on SSP just for some feature that I have no interest in.
If you saw some of the updates of this snapshot, the made a HUGE lag fix(tons of TNT on a server will barely freeze) and there might be a lack of mods at first, but now mods will work with BOTH single player, multiplayer, and a Mod API can be made which would make updating mods much easier.
I'm going to <Facepalm>, at the comments, at the nay-sayers.
I'm going to give away 2 secrets of success -- long term success -- in coding:
1. New school: Separate Model, View, and Controller. How your data works; how your user interface works; how you control the behavior of things; all three of those are separate. No single routine should ever touch more than one of these. By definition, the controller has to make calls to both view code and model code, but it only makes calls -- it does nothing else. Neither data nor interface talk to each other.
2. Older school: Logic and Data are separate. A given routine will either manipulate data _OR_ perform some logic. Combined with a decent object-oriented system (includes Objective C and Java; excludes C++) this permits a given piece of code to be reused no matter what data is being worked with. Also know as: Abstract classes. NB: Modern C++ adds "Templates" to achieve the same result at a very large memory cost.
If you have looked at the decompiled code, you know that both of these rules are broken. Which leads us to #3:
3. Assume that your first draft is out of ignorance, and will be thrown away. Avoid the "I know everything, add the "sink" in now" factor of the second draft.
Mojang wrote single player first. It has all sorts of ... interesting assumptions -- like "The user activated a chest. Lets open it up right away", which breaks in multiplayer. In fact, almost everything turns into asynchronous actions for multiplayer.
Now, with that said, and not yet looking at the new code decompilation, what can be said?
There will be a routine that is called to handle opening a chest. It may have the ability to fetch a list of items. It may be supplied with a list of items. (probably the second).
In multiplayer, it _has_ to be called after receiving data from the server. It cannot be called as a function of a key being pressed. Instead, the key has to notify the server code "Process chest".
In single player, it _SHOULD NOT_ be called as a function of the key press. That is view -- user interface -- acting as controller.
Instead, key press signals controller. Then, two options:
1. Full server operation/emulation: User interface code exits. End of cycle processing. Controller gets the list of items from the model (data), calls the routine to display the chest.
Side effect: World continues while your game is open at no cost.
2. Other: Controller activates the routine to open chest. Note that the code call for the user interface catching the keystroke is still on the stack. Interface window opens.
Side effect: World is basically on pause while the chest is open.
What, you want the world to continue? Ok, then your chest code, because it is blocking the tick code, has to make calls to the tick and video update ...
Err, that's too hard. So lets make it multithreaded. Lets have tick code over here, video display code over there, and all of that running while the user interface is blocked on an open chest display ...
Do you start to understand how things tend to get out of hand?
As far as I know, Minecraft single player up to 1.2.5 was basically single-threaded. Process user input; if you're running more than 20 fps do this several times; after the timer goes off run the tick code. (Yes, you with your hand up, I know that LWJGL basically forces you to be multithreaded, and I know that user input and drawing are in different threads, and I know that Optifine does part of its magic by altering thread priorities so that user input is not ignored by a speedy GPU that is silently throwing away 2/3rd's of the frames.) In order for life to continue in the background if a user interface is taking over is for the controller code to become a subroutine called from elsewhere -- so that everything that affects the user interface can keep calling it. Chests call it. Signs call it. Options -- well, we want that to pause, so it won't, right? Mods and plug-ins call it. Etc.
Wait, do all of them all do it consistently? Does time pass while writing on a sign? (If I recall, it did not in 1.1, and I haven't checked in 1.2 as I'm SMP now). What about furnaces and dispensers? Etc.
Look at Somnia (the mod that simulates the passage of time while asleep). Look at what that author had to say about the layout of the tick processing -- it has graphics stuff hardwired in. The amount of work needed to pretend that time passes because the old code cannot just pass time without graphics updating is ...
Well, it's bad news.
Ideally, you should be able to pass time by the controller managing the world, making calls to the model, and no calls to the user interface, unless you want a "Leave bed" button up while the screen is otherwise blank. Tick code processes tick after tick after tick with no gui calls. Too slow? Ok, process several ticks per mega-tick. Water operates every 4 ticks, I think; redstone has a "natural" frequency of every 2 redstone ticks (also 4 game ticks), and pistons are three game ticks interacting with redstone in 4 game ticks. So you may be able to cut significant overhead by doing 4 times as much less frequently.
Or not -- maybe that makes the redstone code too complex; maybe that makes pistons even more glitchy. So you scrap that optimization. Find your slowest frequent tick loop, and speed that up 10%.
When all is said and done, how can a single player game differ from a single player on a multiplayer server?
Answer: Not significantly. The "server" does not have to be a separate process. But a full separate server makes maintenance and compatibility much easier. Is it trivial?
Entities -- and entity interaction -- is a pain unless a single thread is responsible for everything.
Think movement in general. If you want the user interface to be smooth, then the "I press a key, I move a meter" cannot be slowed by round trip lag. "I aim my bow at the animal", the animal has to be where the user thinks the animal is.
One axiom of multiplayer games: Never trust the client. Clients can be hacked.
So how do you have the user move when the user thinks the user is moving, and still have things regulated by the server? That's ... a big issue.
But this is two decades later. It's ... "more or less solved" now (:-).
I wont pretend this is easy. 1.2.5 fence pens have little effect in multiplayer. They have about a 50/50 chance of being ignored per animal at shut down/start up (more specifically, when the server shuts down and restarts, any animal near the fence has a 50/50 chance of being on the wrong side of the fence at restart). Different clients see different entities in different locations because each client is, in some sense, running a local copy of the entity with the server correcting the clients every so often. Paired movement -- someone riding a boat -- is just wonky. Etc.
Separating MVC is a big win.
Forcing single player to use a separate server thread/process means that all the multiplayer timing bugs _MUST_ be fixed -- which is a good thing.
But is it too high of a bar? Is it too much work? Will it require a total rewrite of the code engine?
My guess: Close, maybe, and yes.
But as people have pointed out, they did this with pocket edition already. It's been done once, so they know how to do it now.
In effect, we will be getting the third implementation, not the second. That's good.
I'm not the biggest fan of how the new local server thing is set up, however I believe it is DEFINITELY a step in the right direction. I believe if an option was given --right after you select the world you want to play in-- asking you if you want to make a local server out or not, people would be MUCH happier
I love the sound of the thread derailing into oblivion. Although im not superman that can hold the minecart and put it on its track though.
Lets hence the word "snapshot". Its just like a beta release! Some features are going to be in the game, some aren't. I've gathered some information about the SMP/SSP merge.
Be able to invite people to your world. STOP. No, greifers and noobs will not come on your world and greif it or spam it. As dinnerbone hinted, there will be some kind of friends list for Minecraft where you can invite friends to your world like MC Xbox.
Merging SMP and SSP together. Nope, you do NOT need a internet connection to play Minecraft. I bet they are going to just use the "Play Offline" button on the Minecraft launcher. Also this will actually cause LESS LAG. Now the server is running on a separate program on your computer it will reduce lag on your client. One con about this I found is dedicated servers, although I think Mojang will figure that out!
Friends List This is a list of friends that where you can type in your username and send them a friend request. Also I think Mojang will assign a unique ID for each Mojang user so it can be a easier ban, and allows Mojang to change usernames without greifers having a avantage. And I bet there will be a blocked user list so you won't get spammed by the same user in friend requests.
Mod API This may be in 1.4 but this will integrate with the SMP/SSP merge so the modder can have a easier time to update their mods. The only downside to it is the modder may need to rewrite their mod.
I wish this helps out the thread and keeps noobs from spamming "THIS SUCKS!"
i cant wait for this update i play all the time in SMP and never play SP
i have my own local server that me and my friends play on with hamachi
i hope this update still retains hamachi compapatability because one of my friend has a slow internet connection and so needs hamachi
i also hope i can replace the server.jar with a bukkit server so we can add plugins
now i wont have to open a terminal command inside of a folder to run a server (but the downside to this is that if i need to disconnect(because i am lagging or something) from the server while my friends are playing, it might shut the server down.
As a snapshot? Probably so.
After they release the highly polished and optimized version on 1.3? I put my bets on the opposite effect.
Also, do you have a source of this knowledge of how the future update is going to affect players or are you making assumptions? I just make assumptions, like the assumption that you are making assumptions.
No, I compared results to older versions. While yes, changes are made when it's no longer a snap shot, but not a huge amount. I also hate the fact you can't pause O_o
An observation (13 pages, forgive me if this has been said already). I think that calling the component parts "server" and "client" is asking for trouble. This is why I asked for the clarification back on the first or second page (thank you for the replies there btw). Causing the confusion I had is: A server is something I connect to external from my computer. Be it in the office with my terminal connecting to the server in the IT room or when I log onto steam or battlenet servers or when I log into one of my friends servers they are running. If I run a server it is for others to connect to me. In either instance an internet connection is needed. I do get the intention of the game being self serving (egregious pun) but I am not seeing that a lot of others are, they are having the same notion I originally had "sever is online, moving my game online, I need to be online to play..." chain of thought.
I have a few friends that play minecraft. I would love to be able to share my world with them without having to email it to them and wait for them to email it back and it sounds like this is a means by which I will be able to.
Mojang knows what theyre doing and theyre smarter than a bunch of 4 year old complainers. They
know what to do and what not to do with the singleplayer/multiplayer thing.
Why do you get so upset about it? all it is is you can invite other people to your singleplayer world,
Why do you get so mad about that? Its not like all your worlds will be deleted or something.
I disagree, 4 year olds can't write as good as some people here.
1. This is a snapshot. Meaning, any bugs or slow-down on your FPS will not be in the final product. YOU ARE STILL BETA TESTING IF YOU USE THIS SNAPSHOT
2. When this is finally implemented, it will be 100% OPTIONAL. You will not need an internet connection to play MC, no. You'll need a connection to play with other people. Sound familiar? Only difference is you'll be able to forgo using servers and just play with friends without all the hassle.
3. To anyone who is complaining about how X mod will be outdated and useless and the Modders will have to take a bunch of time to convert their mods: THAT IS THE ENTIRE POINT. They are doing this for them, even. Sure, that first update is gonna be a b****, but afterword they will be able to work with source code like never before and, with Mojang's offical support, be able to integrate with each other to a far better degree.
I do not like this Multiplayer crossover, Mojang. I thought it would be okay at first when i heard news about it, but now i have SINGLE PLAYER LAG? I go on single player because i have no lag! And I don't like how people can just join my connection if i want to be alone.
The other problem that totally is going to make this impossibly annoying is that you can't pause. I liked pausing to go to the bathroom, or noobing out and changing to Peaceful when a creeper comes behind. C'mon, Mojang. -.-
Rollback Post to RevisionRollBack
"We are the music makers, and we are the dreamers of dreams."