Rather than arguing here about the degree to which 4J might be able to use parts of their coding on the other consoles and concerning ourselves with their internal corporate business, wouldn't it be better if we leave it to 4J to decide how many programmers they need to do the job and how and to what extent they can organize them to avoid unnecessarily duplication of work and wasting of time. it seems they've managed to run a pretty successful company without us so far... wish I could have bought some shares a year ago.
seeing as they have already converted the java code to a C code, most of the hard work is done. However function calls for ps and xbox are still obviously different. Further, I am sure that somewhere along the lines this was anticipated, and they have already writen the code as to be more set for multiplatform, which takes longer to do but once its done its done.
Not to mention, most companies taking on larger undertakings very well might hire new people.
One last time, and I'm done here. The high-level coding language is irrelevant. Each system needs system-level code designed specifically for it, regardless of which human-friendly language is used to arrive at the proper machine language through compilation. Transplanting a 360 program to the PS3 and expecting it to work with a few tweaks is like training someone to fly an Apache helicopter and then telling them to use their training to fly an F15. And it makes no difference that the training for both aircraft is in English.
Yes, but the system-level code is already written. That's what you get when you buy the development kit (among other things) -- the system-specific code and the API to interface with it.
Now, if you were talking C, you'd be more accurate; C is really a souped-up assembler masquerading as a high-level language. But C++ isn't C (and it really should have been called "P", but that's just my geeky opinion). It really is a high-level language, and it doesn't have to talk directly to the hardware; that's what lower layers are for.
Look at the PC version: it runs on Windows, OS X, and Linux. Did they write three different versions from scratch for this? Of course not. They wrote one version, in Java, and the Java virtual machine handles all the system-level stuff. Think of MC as the officer ... "go get this done" ... and the JVM as the noncom "do this, that, and the other thing to get it done."
It's very much the same thing with console ports: the C++ version tells the computer (MS XBox, Sony PS, Infinium Phantom, whatever) what needs to be done: "Draw a blue line from here to here." It doesn't have to (and in fact is designed not to) know jack about what it takes to carry out that command. It's not poking at graphics memory like we did back in the Apple II days! The low-level API takes that request (drawing the blue line) and the system software (think driver) does whatever it takes on that platform to create a blue line. The physical graphics system could be completely replaced and the high-level software would never know the difference.
That's why you don't have to buy new software every time you get a new video card! Your software -- Minecraft, Photoshop, even your OS itself -- doesn't talk directly to the hardware. It talks to drivers and APIs for other software. I can write a program on my computer and give it to you, with a totally different computer (assuming the same OS, where most of the interfacing is handled), and you can run it just fine, because my program neither knows nor cares what your actual hardware is, only whether its "draw a blue line here" API call would be valid or not.
The differences in consoles, from a programming point of view, is not direct interaction with the hardware, but whether that way one interacts with it -- that is, the API calls -- support certain functions or not. Beating my example to death, if your software needs the system to be able to draw blue lines at specified coordinates, and -- due to a limitation in the hardware, or for any other reason -- there's no way to tell the system (via its API) to draw a line where you need it, you've got a problem. That's the sort of thing some of the more cutting-edge games run into, where they're taking advantage of esoteric things (generally involving lighting, as I understand it) that only exist, or exist in that form, only on a particular console. But Minecraft isn't one of those games. For the love of little green creepers, a form of it runs on just about everything out there, including everything from the iPhone to the XBox 360 to the Raspberry Pi. It's not doing weird, esoteric stuff. It's telling the API it talks to "draw a blue line here" and the blue line gets drawn.
I think all of 4J's work on the Xbox 360 will be available for them to use on the other platforms and they will try to use as much as they can across all the platforms to save on unnecessary duplication of work. I think it's completely evident that the Microsoft exclusive has now expired and will no longer be any concern. It looks like the exclusive gave Microsoft the early inside track - i.e. they were able to make money on the 360 for a little over a year without competition from the PS3. It also looks like it gave them the right to be the first to announce it on the next gen consoles. Now, however, the playing field is wide open and all the companies involved will be working in unison to keep Minecraft bringing in money for all of them.
If there is a whole lot of extra work involved (and it may not be all that much), 4J will probably increase its staff to handle the additional workload. As a result, , update frequency may remain about the same. I think there is a possibility that, IF a bottleneck occurs, it will be in getting the updates into Microsoft's certification testing schedule (since at Minecon 2012, Microsoft indicated that they had streamlined the procedure a bit for Minecraft in light of their "partnership" with Mojang and 4J. That may also mean that if 4J was getting a break on Microsoft's fees for submitting updates, the updates may cost 4J more money to submit to Microsoft from now on. Still, however, I believe that the game will still be updated relatively frequently since part of the "popular" culture surrounding the PC version is about frequent updates.
Highly unlikely, since that will mean spending extra money for one team to just redo all the same stuff that the other team has.
It might. If that is a big deal for some people, then they're gonna have to deal with it.
Might? it'll be a lot slower. I could care less after TU14 (which we will have way before Playstations have it, we might even have TU16) They have 5 different consoles, and 3 of those consoles are very different from the standard two, and 1 of those three has a big difference in how the game will work... Playstation Vita will just be another Pocket Edition, lol.
Rollback Post to RevisionRollBack
Religion, has actually convinced people, that there's an invisible man, living in the sky, who watches everything you do every minute of the day, and the invisible man has a special list. Of 10 things he doesn't want you to do. And if you do ANY of these ten things he has a special place, full of fire, and smoke, and burning, and torture, and will send you there to suffer and choke and scream for all of eternity... But he still loves you.
Might? it'll be a lot slower. I could care less after TU14 (which we will have way before Playstations have it, we might even have TU16) They have 5 different consoles, and 3 of those consoles are very different from the standard two, and 1 of those three has a big difference in how the game will work... Playstation Vita will just be another Pocket Edition, lol.
PS Vita has enough RAM as the current gen consoles. I expect some sort of resembelence to the console edition. This... sucks. Microsoft is stupid for not renewing their contract with Mojang. More money milking copies would've come from Xbox One. That was like, the only good thing showed at the XB1 Reveal. Someone hire more 4J employees.
Might? it'll be a lot slower. I could care less after TU14 (which we will have way before Playstations have it, we might even have TU16) They have 5 different consoles, and 3 of those consoles are very different from the standard two, and 1 of those three has a big difference in how the game will work... Playstation Vita will just be another Pocket Edition, lol.
Since no one here works at 4J, none of us really have any credibility to say how long the updates are going to take.
Refer above to the people talking about how there really isn't much of a difference between the consoles when it comes to programming. 4J has already worked on the PS3 so it's not like it's new territory for them.
PS Vita has enough RAM as the current gen consoles. I expect some sort of resembelence to the console edition. This... sucks. Microsoft is stupid for not renewing their contract with Mojang. More money milking copies would've come from Xbox One. That was like, the only good thing showed at the XB1 Reveal. Someone hire more 4J employees.
How about you calm down and wait to see how this affects things then you can complain. 4J never stated to any of us that updates are going to be fast so I don't know where people get this idea. 4J is gonna do fine, I'm sure they can balance all the consoles very fine and still get content out fairly quick. With all the money they'll be making by both Sony versions and Microsoft versions they'll have enough money to have split teams. 1 team for 360/one 1 team for ps3/ps4/vita
How about you calm down and wait to see how this affects things then you can complain. 4J never stated to any of us that updates are going to be fast so I don't know where people get this idea. 4J is gonna do fine, I'm sure they can balance all the consoles very fine and still get content out fairly quick. With all the money they'll be making by both Sony versions and Microsoft versions they'll have enough money to have split teams. 1 team for 360/one 1 team for ps3/ps4/vita
4J also never stated that it was going to be to slow. I guess we will have to wait for the PS4 and XBO Versions to come out then we'll see the progress they make between each TU. I hope it can stay at this steady 2-4 month period w/ DLC.
Might? it'll be a lot slower. I could care less after TU14 (which we will have way before Playstations have it, we might even have TU16) They have 5 different consoles, and 3 of those consoles are very different from the standard two, and 1 of those three has a big difference in how the game will work... Playstation Vita will just be another Pocket Edition, lol.
Why?
I believe 4J currently has 18 employees. Let's say 10 of them are currently working on Minecraft-related things, and out of those people, six are converting code from Java to C++, two are dealing with XBox 360-specific matters (getting the C++ code to talk to the 360 API, basically), and the other two are dealing with XBone-specific matters (same thing). Mind you, I'm pulling this breakdown out of thin air, but the basic idea is sound even if the numbers are way off. Now, if they want to also port to the PS3, PS4, and PS Vita, they'll need platform-specific experts for each of those. So they need six more people -- two for the PS3, two for the PS4, and two for the Vita. The same basic code is being used, once it's hammered into C++; the only thing that really needs more people will be the things that are specific to each platform.
So, using the real total number of employees, and a totally imaginary breakdown of how they're assigned, 4J would have to expand from 18 people to 24 people to keep up the same total output as they have today. In reality, there are probably going to be a few more people hired, too -- maybe someone to coordinate the various platform teams, another marketing person or two to handle the expanded marketing needs, and so on. But my point is, they don't have to hire 18 more people, duplicate the company, and do the entire Java -> C++ port from scratch; they just have to hire enough people to handle the specifics of each console. This is no doubt why they're hiring. (and given the current state of the game industry, there are a lot of talented programmers out there looking for jobs)
At the very worst, let's say that all 18 employees have been working solely on the XBox 360 port (even though we know that some of them have really been working on XBone-specific things, and they do other game ports too, remember). And none of them are anything like an accountant or an office manager or anything else; they're all full-time code grinders. Even if that absolutely-worse-case assumption was true, and they would need another full 18 employees for each platform (XBone, PS3, PS4, and Vita) -- we're still looking at the company expanding to a total of 90 employees. That's still fewer people than work in a typical Wal-Mart. It's still few enough to count as a small business in the US. By way of comparison, Electronic Arts has 9.370 employees -- over 100 times that many.
So there's no reason to assume updates will necessarily be any slower. Sure, the multi-platform aspect of the work might slow things down, if they try to keep all the updates in sync. But the fact that they're hiring more people might speed things up, too. Odds are, the updates will be coming out at about the same rate they are right now.
Wow. That's a lot of assumptions.
To me it's simple. Sony and MS comes to 4J with expectations. 4J calculates they need to hire X number of people to comply and needs X amount of dollars from each party to do it. Everybody agrees, and the updates keep rolling out as usual.
Basically it doesn't matter if they need to hire 9 or 900- 4J has made sure they receive enough money to hire the people to meet their contractual obligations. And the contractual obligations remain the same. So don't worry about updates.
Xbox One and PS4 = the same when it comes to programming.
They both use the exact same x86 programming structure, unlike the Xbox 360 and PS3 which were vastly different.
I'm half-expecting them to scrap the PS3 contract once its up. By then the next-gen consoles would have a decent foothold, and it won't be worth the trouble of pumping out updates for the PS3.. or the 360 for that matter. I estimate another 6-10 months of updates.
Xbox One and PS4 = the same when it comes to programming.
They both use the exact same x86 programming structure, unlike the Xbox 360 and PS3 which were vastly different.
It would be about as similar as Windows is to Linux.
With C++ you can generally use the same source-code on all platforms, the program/software still have to be compiled seperatly for each console, different OS'es use different machine-code (The compiler translates the source-code to machine-code). And I'm quite sure that XBO and PS4 will not be using the same OS.
Rollback Post to RevisionRollBack
I <3 Mechanical Keyboard (Tesoro Durandal G1NL) Just have to love it when someone changes the specs when comparing with and without optifine..
Machine code doesn't matter. That's what you have compilers for. Humans never see the machine code, only the source code.
You can take a simple C++ program -- say, one that prints "hello, world" to the console -- and compile and run it on any computer with a C++ compiler. The machine code will be necessarily different if you're building it for a x86 machine running Windows, or a PS3, or a 68000 Mac, or a PDP-10. In none of these cases does printf actually tell the video hardware how to display "hello, world". The compiler, which is specific to that type of machine, takes that and converts it into the appropriate system calls -- in effect, "hey, display routine, I've got something here I need you to put on the screen. More text! Handle it!" That whole part gets taken care of out of sight to the person writing the actual code; that's kind of the whole point of a high-level language.
Now, when you're dealing with more complex (read: hairy graphics) matters than a simple "hello, world" program, you won't be printing your output directly like that. You'll be making calls to an API - application programming interface -- for that console. The API call to draw a shape on the screen on a 360 may be different from the one for doing the same thing on a PS3 -- even something as simple as having the same arguments but in a different order. There are a lot of ways this can be handled, everything from differential compilation (compiler commands embedded in the source, to build different parts according to commands given to the compiler) to an intermediate level, either a translation routine or a codewalker, that converts a generic command into the real API call for the target platform, or something else entirely. That's what the platform specialists on the team do.
And I'm writing this on an iPod Touch, so I'll elaborate more later if necessary when I have a real keyboard!
Not to mention, most companies taking on larger undertakings very well might hire new people.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYes, but the system-level code is already written. That's what you get when you buy the development kit (among other things) -- the system-specific code and the API to interface with it.
Now, if you were talking C, you'd be more accurate; C is really a souped-up assembler masquerading as a high-level language. But C++ isn't C (and it really should have been called "P", but that's just my geeky opinion). It really is a high-level language, and it doesn't have to talk directly to the hardware; that's what lower layers are for.
Look at the PC version: it runs on Windows, OS X, and Linux. Did they write three different versions from scratch for this? Of course not. They wrote one version, in Java, and the Java virtual machine handles all the system-level stuff. Think of MC as the officer ... "go get this done" ... and the JVM as the noncom "do this, that, and the other thing to get it done."
It's very much the same thing with console ports: the C++ version tells the computer (MS XBox, Sony PS, Infinium Phantom, whatever) what needs to be done: "Draw a blue line from here to here." It doesn't have to (and in fact is designed not to) know jack about what it takes to carry out that command. It's not poking at graphics memory like we did back in the Apple II days! The low-level API takes that request (drawing the blue line) and the system software (think driver) does whatever it takes on that platform to create a blue line. The physical graphics system could be completely replaced and the high-level software would never know the difference.
That's why you don't have to buy new software every time you get a new video card! Your software -- Minecraft, Photoshop, even your OS itself -- doesn't talk directly to the hardware. It talks to drivers and APIs for other software. I can write a program on my computer and give it to you, with a totally different computer (assuming the same OS, where most of the interfacing is handled), and you can run it just fine, because my program neither knows nor cares what your actual hardware is, only whether its "draw a blue line here" API call would be valid or not.
The differences in consoles, from a programming point of view, is not direct interaction with the hardware, but whether that way one interacts with it -- that is, the API calls -- support certain functions or not. Beating my example to death, if your software needs the system to be able to draw blue lines at specified coordinates, and -- due to a limitation in the hardware, or for any other reason -- there's no way to tell the system (via its API) to draw a line where you need it, you've got a problem. That's the sort of thing some of the more cutting-edge games run into, where they're taking advantage of esoteric things (generally involving lighting, as I understand it) that only exist, or exist in that form, only on a particular console. But Minecraft isn't one of those games. For the love of little green creepers, a form of it runs on just about everything out there, including everything from the iPhone to the XBox 360 to the Raspberry Pi. It's not doing weird, esoteric stuff. It's telling the API it talks to "draw a blue line here" and the blue line gets drawn.
The golden age: it's not the game, it's you ⋆ Why Minecraft should not be harder ⋆ Spelling hints
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMight? it'll be a lot slower. I could care less after TU14 (which we will have way before Playstations have it, we might even have TU16) They have 5 different consoles, and 3 of those consoles are very different from the standard two, and 1 of those three has a big difference in how the game will work... Playstation Vita will just be another Pocket Edition, lol.
Refer above to the people talking about how there really isn't much of a difference between the consoles when it comes to programming. 4J has already worked on the PS3 so it's not like it's new territory for them.
If you check out their website and go under "Careers", you'll see they're already on that.
How about you calm down and wait to see how this affects things then you can complain. 4J never stated to any of us that updates are going to be fast so I don't know where people get this idea. 4J is gonna do fine, I'm sure they can balance all the consoles very fine and still get content out fairly quick. With all the money they'll be making by both Sony versions and Microsoft versions they'll have enough money to have split teams. 1 team for 360/one 1 team for ps3/ps4/vita
It might, it might not.
This seems like a reason to not worry.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWhy?
I believe 4J currently has 18 employees. Let's say 10 of them are currently working on Minecraft-related things, and out of those people, six are converting code from Java to C++, two are dealing with XBox 360-specific matters (getting the C++ code to talk to the 360 API, basically), and the other two are dealing with XBone-specific matters (same thing). Mind you, I'm pulling this breakdown out of thin air, but the basic idea is sound even if the numbers are way off. Now, if they want to also port to the PS3, PS4, and PS Vita, they'll need platform-specific experts for each of those. So they need six more people -- two for the PS3, two for the PS4, and two for the Vita. The same basic code is being used, once it's hammered into C++; the only thing that really needs more people will be the things that are specific to each platform.
So, using the real total number of employees, and a totally imaginary breakdown of how they're assigned, 4J would have to expand from 18 people to 24 people to keep up the same total output as they have today. In reality, there are probably going to be a few more people hired, too -- maybe someone to coordinate the various platform teams, another marketing person or two to handle the expanded marketing needs, and so on. But my point is, they don't have to hire 18 more people, duplicate the company, and do the entire Java -> C++ port from scratch; they just have to hire enough people to handle the specifics of each console. This is no doubt why they're hiring. (and given the current state of the game industry, there are a lot of talented programmers out there looking for jobs)
At the very worst, let's say that all 18 employees have been working solely on the XBox 360 port (even though we know that some of them have really been working on XBone-specific things, and they do other game ports too, remember). And none of them are anything like an accountant or an office manager or anything else; they're all full-time code grinders. Even if that absolutely-worse-case assumption was true, and they would need another full 18 employees for each platform (XBone, PS3, PS4, and Vita) -- we're still looking at the company expanding to a total of 90 employees. That's still fewer people than work in a typical Wal-Mart. It's still few enough to count as a small business in the US. By way of comparison, Electronic Arts has 9.370 employees -- over 100 times that many.
So there's no reason to assume updates will necessarily be any slower. Sure, the multi-platform aspect of the work might slow things down, if they try to keep all the updates in sync. But the fact that they're hiring more people might speed things up, too. Odds are, the updates will be coming out at about the same rate they are right now.
The golden age: it's not the game, it's you ⋆ Why Minecraft should not be harder ⋆ Spelling hints
To me it's simple. Sony and MS comes to 4J with expectations. 4J calculates they need to hire X number of people to comply and needs X amount of dollars from each party to do it. Everybody agrees, and the updates keep rolling out as usual.
Basically it doesn't matter if they need to hire 9 or 900- 4J has made sure they receive enough money to hire the people to meet their contractual obligations. And the contractual obligations remain the same. So don't worry about updates.
They both use the exact same x86 programming structure, unlike the Xbox 360 and PS3 which were vastly different.
I'm half-expecting them to scrap the PS3 contract once its up. By then the next-gen consoles would have a decent foothold, and it won't be worth the trouble of pumping out updates for the PS3.. or the 360 for that matter. I estimate another 6-10 months of updates.
Pretty sure that 4J will be able to get all the updates out at nearly the same time.
It would be about as similar as Windows is to Linux.
With C++ you can generally use the same source-code on all platforms, the program/software still have to be compiled seperatly for each console, different OS'es use different machine-code (The compiler translates the source-code to machine-code). And I'm quite sure that XBO and PS4 will not be using the same OS.
Just have to love it when someone changes the specs when comparing with and without optifine..
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYou can take a simple C++ program -- say, one that prints "hello, world" to the console -- and compile and run it on any computer with a C++ compiler. The machine code will be necessarily different if you're building it for a x86 machine running Windows, or a PS3, or a 68000 Mac, or a PDP-10. In none of these cases does printf actually tell the video hardware how to display "hello, world". The compiler, which is specific to that type of machine, takes that and converts it into the appropriate system calls -- in effect, "hey, display routine, I've got something here I need you to put on the screen. More text! Handle it!" That whole part gets taken care of out of sight to the person writing the actual code; that's kind of the whole point of a high-level language.
Now, when you're dealing with more complex (read: hairy graphics) matters than a simple "hello, world" program, you won't be printing your output directly like that. You'll be making calls to an API - application programming interface -- for that console. The API call to draw a shape on the screen on a 360 may be different from the one for doing the same thing on a PS3 -- even something as simple as having the same arguments but in a different order. There are a lot of ways this can be handled, everything from differential compilation (compiler commands embedded in the source, to build different parts according to commands given to the compiler) to an intermediate level, either a translation routine or a codewalker, that converts a generic command into the real API call for the target platform, or something else entirely. That's what the platform specialists on the team do.
And I'm writing this on an iPod Touch, so I'll elaborate more later if necessary when I have a real keyboard!
The golden age: it's not the game, it's you ⋆ Why Minecraft should not be harder ⋆ Spelling hints