I gotta give it to electricblooz. He is right on when he talks about the limitations of the "box" - meaning the platform. I am actually pretty amazed that 4J can work with 512MB of RAM and still produce what it can. We're talking about a PC game that calls for a minimum of 2GB of RAM.
Hes not right HernDiddy, hes basically blaming all the mechanics that are not in place yet, and or that were bugging and blaming it on the xbox hardware, imho hes blowing chunks.
Now I only said he was right about acknowledging the 'hard' limitations... everything else is just theory.
I have done a little C++ but mainly I remember coding using Python and man.... I feel for programmers. It's actually a secret love of mine.... I love/hate to program.
But you have to admit there are serious hardware limitations. Having said that, I know that is not a good excuse to use. I am just amazed at what 4J can do!
Actually handling villagers using different doors isn't that big of a problem, the game can already get a object list of houses (doors), the game already iterates through villagers sending them to 'the closest' house when nightfall arrives. It really isn't that much for them to...get first door, send first 3 villagers there, get second door, send 3 villagers there, (is this the last house, yes-> all remaining villagers here, else get next door, and so on.
In respects to the xbox reaching its limits in processing power (CPU), yes, I agree its very near its limits. In respects to it reaching the 360s limits in GPU ( r u freaking kidding me), it was profiled on the PC, that less then 2% of all computing power goes into rendering. Lets face it MC isn't a top notice graphical wow, with millions of polygons and a very sophisticated lighting/bit mapping/blending and shading game now is it.
In respects to generated villages entering into a infinite breeding state, this is a BUG, and simply putting a cap on villagers rather then addressing the fix is well rather weak.
Villager population is based on the number of qualified 'houses' in a village, which basically means there is a door somewhere that qualifies a structure as a house.
If a table is kept of door locations and villagers spawned in relation to those doors, then an algorithm could be built to spawn villagers and associate them to a particular door (house), and then when night begins to fall, that villager can try to 'go home' and find a path to the nearest door they can safely get to on their way home, seeking an unoccupied house first if possible, and re-associating if a closer unoccupied house is available.
This would help to avoid the night time clustering and allow villagers to re-associate to new villages if they are moved. Or as village houses are redesigned and doors are moved. Or they just can't seem to make it back to their original designated home space.
The over population (infinite breeding) issue appears to be by design to me. This happens because the space that is computed for a village is different that the space that is used to count the number of active villagers for the village population count to see if breeding should occur. If the same space was used for each of these calculations, then infinite breeding would be significantly harder than it is now and would be exceedingly unlikely to occur in randomly spawned villages.
Greg, this is true. Infinite breeding is by design. Villagers can see a village and see whether or not the villager cap has been met so they can breed as part of the village. However, the villager can be outside of that village boundary so the village itself can't see the villagers and will never add them to the villager limit. That loop hole makes the breeding possible but I think Cire said something earlier about TU12 having a broken village mechanic. I agree that the cap to try to fix crashes due to infinite breeding wasn't the right approach.
I'm not talking about the mechanics of infinite breeding, but more so the mechanics of how villages are spawned. When a village is made that allows villagers to be +- 5 of the horizontal axis of the village then there is a chance that the village will attain a infinite breeding state. Obviously this points to village creation being bugged. We've seen villages popup in the most odd places, and the game needs to take more care when creating villages.
Also villagers by default should NOT never leave the village boundaries. They should not be willing to take fall damage that will kill them but will from time to time be willing to take small amounts of fall damage. They have no fear of fire, lava and cactus and will kill themselves on these from time to time.
it needs to be infinite, My iron farm has at least 192 villagers alone and now with villager trading coming out I'm gonna be screwed. just bring back the infinate village breeder glitch back.
Hes not right HernDiddy, hes basically blaming all the mechanics that are not in place yet, and or that were bugging and blaming it on the xbox hardware, imho hes blowing chunks.
It might be your opinion Cire - but you're wrong.
There was no broken mechanic in TU12 - the villager breeding worked (and continues to work) exactly like it did on the PC. The horizontal axis design made by Mojang leads to villagers breeding and then not being counted for the purposes of the limit. Surprise, surprise, when these cells happened on people's machines and spawned massive amounts of villagers, it overtaxed the system and they crashed. QED. It's not a bug - it's how Mojang designed villager breeding to work, I don't know why - seems like a very stupid design choice, but it is what it is. 4J is not going to go back and create a brand new breeding system; they are not creating code, they are porting. If you don't like the limitations of the 360 - go play on a PC. Continually whining about how "the game ought to be able to do this," is counter productive and, frankly, annoying as hell.
Greg,
Your idea about an association table is certainly how villager AI should have been developed in the first place. Why they didn't do it that way, I have no idea except to note, if you permanently associate a villager to a single door instance, you preclude moving villagers from one village to another. You also would have to do should additional coding to address what happens when a particular villager's door is broken. Not saying it's impossible - but coding would be very complex. When you look at what we do have, it's pretty clear that Mojang just took the easy road.
There was no broken mechanic in TU12 - the villager breeding worked (and continues to work) exactly like it did on the PC. The horizontal axis design made by Mojang leads to villagers breeding and then not being counted for the purposes of the limit. Surprise, surprise, when these cells happened on people's machines and spawned massive amounts of villagers, it overtaxed the system and they crashed. QED. It's not a bug - it's how Mojang designed villager breeding to work, I don't know why - seems like a very stupid design choice, but it is what it is. 4J is not going to go back and create a brand new breeding system; they are not creating code, they are porting.
Then why do they have a suggestions thread if they are not going to take suggestions?
Bottom line is, it is a bug. If unintential infinite bredding happens, then it is a bug and should be fixed.
If you don't like the limitations of the 360 - go play on a PC. Continually whining about how "the game ought to be able to do this," is counter productive and, frankly, annoying as hell.
The typical response. Why try to improve the xbox version, just go play on the pc instead. Sorry, many people prefer the xbox version and would like to see game improvements, including a villager system that works. Is there a problem with pointing out issues that we would like addressed?
Personally I think villagers are a part of the game that many use. With trading coming, they will play a bigger role. I like to have some "life" around the towns I create. Unfortunately, the cap and bugs have ruined that aspect. Surely there is an inteligent way to code the villager AI that would not be that difficult. At least raise the cap and find a way to stop the clumping.
The more I think about it, the more I'm convinced that the tension is between Minecraft as a "game" and Minecraft as a "simulation." I have to admit that I'm as guilty as the next person - I'd like for Minecraft to behave a bit more like a world simulation (such as villagers behaving like they had brains, animals behaving a bit more intelligently, etc.) However, that's not what Mojang gave us and what Mojang gave us is what 4J is trying to reproduce. Go back to the roots of Minecraft and it is still a survival game; all the stuff that has been added on top of that was just to make surviving more interesting. All that extra stuff - however - has also made the game seem more like a simulation (or and RPG, if you will).
Ergo, when we talk about design decisions, I think we need to keep in mind the obvious core philosophy that started MC. That's why I agree that upping the villager cap count is a good idea - ghost town villages are boring. But, the key issue is to balance adding interest with keeping the game running within the constraints of the 8-year-old 360 technology.
The more I think about it, the more I'm convinced that the tension is between Minecraft as a "game" and Minecraft as a "simulation." I have to admit that I'm as guilty as the next person - I'd like for Minecraft to behave a bit more like a world simulation (such as villagers behaving like they had brains, animals behaving a bit more intelligently, etc.) However, that's not what Mojang gave us and what Mojang gave us is what 4J is trying to reproduce. Go back to the roots of Minecraft and it is still a survival game; all the stuff that has been added on top of that was just to make surviving more interesting. All that extra stuff - however - has also made the game seem more like a simulation (or and RPG, if you will).
Ergo, when we talk about design decisions, I think we need to keep in mind the obvious core philosophy that started MC. That's why I agree that upping the villager cap count is a good idea - ghost town villages are boring. But, the key issue is to balance adding interest with keeping the game running within the constraints of the 8-year-old 360 technology.
Indeed. We have to go back and look at how Notch coded his "cave game". I don't think he thought that it would explode to what it is today and instead of stream-lining the code they just kept adding on top of it, making it that much harder to add and modify without messing up the syntax.
I love this game and yes the 360 edition is still a port. I believe 4J did say that they wanted to stray from where the PC was going and take the game in a new direction but time will tell.
The Meaning of Life, the Universe, and Everything.
Join Date:
9/17/2013
Posts:
62
Member Details
I'm all for as large a villager cap as can be managed on the xbox. Its great to grow and develop villages in minecraft. One of the most interesting and challenging aspects of minecraft, for us, is managing villages. We currently are playing on a seed with five villages, and are gradually developing the whole map. We've learned how to protect the villages with fencing and light, and it is always an interesting puzzle to figure out how to restrict their access to caves and dangers, while letting them roam around as much as possible. We've managed to get all five villages in a thriving state, with three of them so far spawning golems, two with two golems! We've built a railroad system to connect the villages, and are gradually building our own houses in each one, plus more houses for the villagers. It's very interesting to create different village designs out of nearby resources, while preserving and improving the 'old town' original structures. Landscaping, fountain and park building, it's an endlessly interesting experience. We've just recently discovered how this aspect of the game creates an ongoing playability in minecraft. Very creative and, actually, one of the few video games where you can play at being a 'helper', a builder, and making the villagers 'lives' and environments cooler and safer is a unique experience in gaming. It is a survival game, but when you try to help villagers survive also, it becomes all the more interesting.
While it would be great to have villager trading and more interactivity, if that is a problem with increasing the villager cap (which I am very much FOR), couldn't it be done where only a certain percentage of villagers are traders? That would be more 'realistic' anyway. Any little tweaks in the AI experience would be great too. It's fun to have them roaming around and 'congregating' suspiciously ;-) in various places... And watching you build, and coming into your house in the middle of the night to stare at you ;-) of course... But if a little more interactivity could be introduced, that would be cool also.
There was no broken mechanic in TU12 - the villager breeding worked (and continues to work) exactly like it did on the PC. The horizontal axis design made by Mojang leads to villagers breeding and then not being counted for the purposes of the limit. Surprise, surprise, when these cells happened on people's machines and spawned massive amounts of villagers, it overtaxed the system and they crashed. QED. It's not a bug - it's how Mojang designed villager breeding to work, I don't know why - seems like a very stupid design choice, but it is what it is. 4J is not going to go back and create a brand new breeding system; they are not creating code, they are porting.
When have you ever heard of a village with 200+ villagers on the PC that isn't created by the player? ahhh, never, why because the PC generates villages correctly, oh i guess you can blame this on the limitations of the Xbox hardware too.
If you don't like the limitations of the 360 - go play on a PC. Continually whining about how "the game ought to be able to do this," is counter productive and, frankly, annoying as hell.
How about this, if you don't like it don't respond to it, the amount of negativity you bring to every damn thread is well frankly annoying as hell. Quit blaming every aspect that is either a bug, or "feature" on the limitations of the xbox hardware.
Villages on the PC do NOT generate when they can put themselves into a infinite breeding state, ie +-5 across the horizontal threshold, but alas according to you the xbox can generate a village it just can't track how its generating it because of the limitations, yeah right tell me another one, dumbas.s
For example - the crowding problem. Right now, villagers AI is programmed to produce behavior that looks like the villagers are interacting. In other words, on balance, when two villagers are near each other, they stay near each other. When night falls each individual seeks the closest door. Because villager day time behavior encourages clumping, you get clumping at night. To "fix" this problem and still retain the realistic day time behavior you would need to implement a system internal to the villager AI which "checks" if a "door" is occupied and, if so, does a search routine for the next closest door. Problem is, that you have to define what "occupied" means and you have to also introduce a fail safe routine for intransitive options, otherwise villagers would get caught in endless loops trying to pick a door. (BTW - what do you think caused the famous "spinning head" glitch with the animal mobs? it was because the mob was caught in a endless loop between which direction to move). Now, imagine what it would do to your CPU if you had 200 villagers stuck in a non-resolvable decision loop.
That is where you are wrong, and this was discussed at great length in the PC as well, I will try to find the link to that thread. However as many pointed out there are functions in the code that allows (a) a villager to find the closest door to them, as well as find all doors in a village which is called from time to time and then counted to check if there are enough doors to warrant a Golem to spawn or not. We also know that come nightfall the code gatherers all villagers and sends them to the closest door, and there is a code bug that takes place quite often which ends up using the same door the first villager it starts with. Thus here is where we begin with the clumping that takes place. By altering this function to... Gather all doors, set 'occupied' counters on doors to 0. Select closest door to villager, send villager to this door and increment occupied counter. Check if occupied counter is 3 or more, if so remove this door from our list of valid locations to send the villager providing its not the last door.
This is not going to break the 360, as for the most part most of this code already exists, and all we are doing is inserting a signed short int on door collections contained within the village.
Next and the thing I can't seem to make you understand is that its not the mechanics of village breeding that is broke, but the mechanics of HOW a village is being generated. On the PC a village can't generate if it will put itself into a infinite breeding state, in other words if the horizontal axis of the village sways more the +4.
This will cause the 360 to generate villages not in the side of mountains and hills and more so around plains, deserts. There is a serious issue with the 360 when it will spawn a village on the side of the map with most of it in the ocean, or if it will generate in areas that will cause infinite breeding to take place. This has NOTHING and I repeat NOTHING to do with the xbox reaching its limits, as the village is already spawning, it just needs to be more selective of 'where' it can spawn.
Now I realize that some seeds under this rule might not generate a village, but this is how it has to be, we can't always have villages if they are gona break themselves. I believe that 4J opted for the opposite in other words they are attempting to make sure that at least 1 village spawns per seed where possible, and I believe they are not checking for variances on the horizontal axis.
Oh and before you state that 4J is just porting the code and not making any changes, this isn't true. Off the top of my head I can think of two that is increased minecart speeds and animals spawn mechanics, both of these were modified specifically for the 360 and differ considerably from the PC.
Oh and before you state that 4J is just porting the code and not making any changes, this isn't true. Off the top of my head I can think of two that is increased minecart speeds and animals spawn mechanics, both of these were modified specifically for the 360 and differ considerably from the PC.
Don't forget about the Ender Dragon. It's movement and fighting were changed for the xbox and the purple fire charge it shoots and acid it spews were also added xbox exclusive.
I thought I read that 4J hired an AI specialist awhile back. Hopefully this means that this person will have fixed the AI issues for the next update.
The main issue is just the clumping. If they eliminate the clumping during the day, it will fix the problem at night. Just have the villagers move in random directions during the day and if they pass within a certain number of spaces of another villager, they stop and interact for a few seconds, then move on and can't interact for x amount of time. This should eliminate any perpetual interactions. Now that they are spread out, they just go in the closest door at night.
I sincerely hope they fix this bug because it really does ruin the game. I am no coding expert, my exposure was a long time ago, but I really don't see how this can't be addressed in a fairly simple model. Maybe they need to simplify first, then later try to come up with other improvements. Just get the villagers spread out.
Greg,
Your idea about an association table is certainly how villager AI should have been developed in the first place. Why they didn't do it that way, I have no idea except to note, if you permanently associate a villager to a single door instance, you preclude moving villagers from one village to another. You also would have to do should additional coding to address what happens when a particular villager's door is broken. Not saying it's impossible - but coding would be very complex. When you look at what we do have, it's pretty clear that Mojang just took the easy road.
I never suggested that they would be permanently associated to any particular door and it isn't that complex to do, and I did cover re-association conditions if it isn't practical to get back to the original door before nightfall...or if that door isn't present anymore or has otherwise been moved.
I have to agree with Cire360 that the original design of villages precluded naturally occurring infinite spawning loops for villagers... but finding available flat land to build on in the limited size 360 map can be challenging at best, so another solution needs to be sought for the haphazard village constructions that tend to spawn on the 360 maps.
Some more advanced AI could be built into villagers to prevent them from injuring themselves which can be borrowed from other passive/aggressive MOB AI now (as these other creatures tend to avoid conditions which would injure them already, including lava, cactus walls, falls from heights, etc.) And should be extended to have villagers actively avoid paths that would prevent them from returning to their village/door (such as avoid going down 2 blocks if there is no viable path back).
4J is not going to go back and create a brand new breeding system; they are not creating code, they are porting.
So... you're saying that the XBox controller interface is part of Mojang's original Java Code for the PC? Or the Console Crafting interface? Or the fact that chunks do not unload as a player moves away from them? or split-screen functionality... that was definitely in Mojang's original Java Code, I'm sure....
The fact is, 4J has put a lot of their own innovation into developing Minecraft for the consoles, and have already modified a lot of existing in game code including, but not limited to diamond ore frequency, MOB caps, Village spawning algorithms, etc.
I have done a little C++ but mainly I remember coding using Python and man.... I feel for programmers. It's actually a secret love of mine.... I love/hate to program.
But you have to admit there are serious hardware limitations. Having said that, I know that is not a good excuse to use. I am just amazed at what 4J can do!
Remember...... pseudo code always works....
In respects to the xbox reaching its limits in processing power (CPU), yes, I agree its very near its limits. In respects to it reaching the 360s limits in GPU ( r u freaking kidding me), it was profiled on the PC, that less then 2% of all computing power goes into rendering. Lets face it MC isn't a top notice graphical wow, with millions of polygons and a very sophisticated lighting/bit mapping/blending and shading game now is it.
In respects to generated villages entering into a infinite breeding state, this is a BUG, and simply putting a cap on villagers rather then addressing the fix is well rather weak.
If a table is kept of door locations and villagers spawned in relation to those doors, then an algorithm could be built to spawn villagers and associate them to a particular door (house), and then when night begins to fall, that villager can try to 'go home' and find a path to the nearest door they can safely get to on their way home, seeking an unoccupied house first if possible, and re-associating if a closer unoccupied house is available.
This would help to avoid the night time clustering and allow villagers to re-associate to new villages if they are moved. Or as village houses are redesigned and doors are moved. Or they just can't seem to make it back to their original designated home space.
The over population (infinite breeding) issue appears to be by design to me. This happens because the space that is computed for a village is different that the space that is used to count the number of active villagers for the village population count to see if breeding should occur. If the same space was used for each of these calculations, then infinite breeding would be significantly harder than it is now and would be exceedingly unlikely to occur in randomly spawned villages.
Also villagers by default should NOT never leave the village boundaries. They should not be willing to take fall damage that will kill them but will from time to time be willing to take small amounts of fall damage. They have no fear of fire, lava and cactus and will kill themselves on these from time to time.
It might be your opinion Cire - but you're wrong.
There was no broken mechanic in TU12 - the villager breeding worked (and continues to work) exactly like it did on the PC. The horizontal axis design made by Mojang leads to villagers breeding and then not being counted for the purposes of the limit. Surprise, surprise, when these cells happened on people's machines and spawned massive amounts of villagers, it overtaxed the system and they crashed. QED. It's not a bug - it's how Mojang designed villager breeding to work, I don't know why - seems like a very stupid design choice, but it is what it is. 4J is not going to go back and create a brand new breeding system; they are not creating code, they are porting. If you don't like the limitations of the 360 - go play on a PC. Continually whining about how "the game ought to be able to do this," is counter productive and, frankly, annoying as hell.
Greg,
Your idea about an association table is certainly how villager AI should have been developed in the first place. Why they didn't do it that way, I have no idea except to note, if you permanently associate a villager to a single door instance, you preclude moving villagers from one village to another. You also would have to do should additional coding to address what happens when a particular villager's door is broken. Not saying it's impossible - but coding would be very complex. When you look at what we do have, it's pretty clear that Mojang just took the easy road.
If you could go ahead and continue to keep it clean that'd be great...
Then why do they have a suggestions thread if they are not going to take suggestions?
Bottom line is, it is a bug. If unintential infinite bredding happens, then it is a bug and should be fixed.
The typical response. Why try to improve the xbox version, just go play on the pc instead. Sorry, many people prefer the xbox version and would like to see game improvements, including a villager system that works. Is there a problem with pointing out issues that we would like addressed?
Personally I think villagers are a part of the game that many use. With trading coming, they will play a bigger role. I like to have some "life" around the towns I create. Unfortunately, the cap and bugs have ruined that aspect. Surely there is an inteligent way to code the villager AI that would not be that difficult. At least raise the cap and find a way to stop the clumping.
The more I think about it, the more I'm convinced that the tension is between Minecraft as a "game" and Minecraft as a "simulation." I have to admit that I'm as guilty as the next person - I'd like for Minecraft to behave a bit more like a world simulation (such as villagers behaving like they had brains, animals behaving a bit more intelligently, etc.) However, that's not what Mojang gave us and what Mojang gave us is what 4J is trying to reproduce. Go back to the roots of Minecraft and it is still a survival game; all the stuff that has been added on top of that was just to make surviving more interesting. All that extra stuff - however - has also made the game seem more like a simulation (or and RPG, if you will).
Ergo, when we talk about design decisions, I think we need to keep in mind the obvious core philosophy that started MC. That's why I agree that upping the villager cap count is a good idea - ghost town villages are boring. But, the key issue is to balance adding interest with keeping the game running within the constraints of the 8-year-old 360 technology.
Indeed. We have to go back and look at how Notch coded his "cave game". I don't think he thought that it would explode to what it is today and instead of stream-lining the code they just kept adding on top of it, making it that much harder to add and modify without messing up the syntax.
I love this game and yes the 360 edition is still a port. I believe 4J did say that they wanted to stray from where the PC was going and take the game in a new direction but time will tell.
While it would be great to have villager trading and more interactivity, if that is a problem with increasing the villager cap (which I am very much FOR), couldn't it be done where only a certain percentage of villagers are traders? That would be more 'realistic' anyway. Any little tweaks in the AI experience would be great too. It's fun to have them roaming around and 'congregating' suspiciously ;-) in various places... And watching you build, and coming into your house in the middle of the night to stare at you ;-) of course... But if a little more interactivity could be introduced, that would be cool also.
No your wrong, and we can keep this up all day.
When have you ever heard of a village with 200+ villagers on the PC that isn't created by the player? ahhh, never, why because the PC generates villages correctly, oh i guess you can blame this on the limitations of the Xbox hardware too.
How about this, if you don't like it don't respond to it, the amount of negativity you bring to every damn thread is well frankly annoying as hell. Quit blaming every aspect that is either a bug, or "feature" on the limitations of the xbox hardware.
Villages on the PC do NOT generate when they can put themselves into a infinite breeding state, ie +-5 across the horizontal threshold, but alas according to you the xbox can generate a village it just can't track how its generating it because of the limitations, yeah right tell me another one, dumbas.s
That is where you are wrong, and this was discussed at great length in the PC as well, I will try to find the link to that thread. However as many pointed out there are functions in the code that allows (a) a villager to find the closest door to them, as well as find all doors in a village which is called from time to time and then counted to check if there are enough doors to warrant a Golem to spawn or not. We also know that come nightfall the code gatherers all villagers and sends them to the closest door, and there is a code bug that takes place quite often which ends up using the same door the first villager it starts with. Thus here is where we begin with the clumping that takes place. By altering this function to... Gather all doors, set 'occupied' counters on doors to 0. Select closest door to villager, send villager to this door and increment occupied counter. Check if occupied counter is 3 or more, if so remove this door from our list of valid locations to send the villager providing its not the last door.
This is not going to break the 360, as for the most part most of this code already exists, and all we are doing is inserting a signed short int on door collections contained within the village.
Next and the thing I can't seem to make you understand is that its not the mechanics of village breeding that is broke, but the mechanics of HOW a village is being generated. On the PC a village can't generate if it will put itself into a infinite breeding state, in other words if the horizontal axis of the village sways more the +4.
This will cause the 360 to generate villages not in the side of mountains and hills and more so around plains, deserts. There is a serious issue with the 360 when it will spawn a village on the side of the map with most of it in the ocean, or if it will generate in areas that will cause infinite breeding to take place. This has NOTHING and I repeat NOTHING to do with the xbox reaching its limits, as the village is already spawning, it just needs to be more selective of 'where' it can spawn.
Now I realize that some seeds under this rule might not generate a village, but this is how it has to be, we can't always have villages if they are gona break themselves. I believe that 4J opted for the opposite in other words they are attempting to make sure that at least 1 village spawns per seed where possible, and I believe they are not checking for variances on the horizontal axis.
Don't forget about the Ender Dragon. It's movement and fighting were changed for the xbox and the purple fire charge it shoots and acid it spews were also added xbox exclusive.
The main issue is just the clumping. If they eliminate the clumping during the day, it will fix the problem at night. Just have the villagers move in random directions during the day and if they pass within a certain number of spaces of another villager, they stop and interact for a few seconds, then move on and can't interact for x amount of time. This should eliminate any perpetual interactions. Now that they are spread out, they just go in the closest door at night.
I sincerely hope they fix this bug because it really does ruin the game. I am no coding expert, my exposure was a long time ago, but I really don't see how this can't be addressed in a fairly simple model. Maybe they need to simplify first, then later try to come up with other improvements. Just get the villagers spread out.
I never suggested that they would be permanently associated to any particular door and it isn't that complex to do, and I did cover re-association conditions if it isn't practical to get back to the original door before nightfall...or if that door isn't present anymore or has otherwise been moved.
I have to agree with Cire360 that the original design of villages precluded naturally occurring infinite spawning loops for villagers... but finding available flat land to build on in the limited size 360 map can be challenging at best, so another solution needs to be sought for the haphazard village constructions that tend to spawn on the 360 maps.
Some more advanced AI could be built into villagers to prevent them from injuring themselves which can be borrowed from other passive/aggressive MOB AI now (as these other creatures tend to avoid conditions which would injure them already, including lava, cactus walls, falls from heights, etc.) And should be extended to have villagers actively avoid paths that would prevent them from returning to their village/door (such as avoid going down 2 blocks if there is no viable path back).
So... you're saying that the XBox controller interface is part of Mojang's original Java Code for the PC? Or the Console Crafting interface? Or the fact that chunks do not unload as a player moves away from them? or split-screen functionality... that was definitely in Mojang's original Java Code, I'm sure....
The fact is, 4J has put a lot of their own innovation into developing Minecraft for the consoles, and have already modified a lot of existing in game code including, but not limited to diamond ore frequency, MOB caps, Village spawning algorithms, etc.
They do NOT only JUST port code.