I should add that if they make these options well enough up front, then they don't have to worry about paying people to make new maps. All they have to worry about is having people test maps for acceptability for inclusion into MM, which should be significantly less spend. They make the game. They perform the quality control. Let the community create the content it wants to play.
If the dev kit is expensive to buy and difficult to use (or at least has a much steeper learning curve than Forge), that will be something of a natural quality control filter. Most of the people that bother paying for such a thing and that manage to use it to make something playable will be more dev-minded to begin with. You'll still have some crap, but that's no different from how forge works now, and it would probably be a much smaller percentage of the overall output that is just junk. And just like it works now, they can have 343 developers, or community cartographers (preferably ones chosen a bit more carefully...) select worthy community-made maps to go into matchmaking, and to push out as mandatory downloads. And with a dev kit, and the maps being a full download and not just a forge file (essentially just a tiny text file), they OUGHT to be a lot better. The average ones should be better than the average forge maps, and the great ones should be jaw-dropping and rival the on-disc maps. All of that would be fun for modders and minigame-makers, but it doesn't really help map-makers. To me, these kind of features are the probable future of forge. If they choose to take it to the next level, that is, while still keeping it noob-friendly. It means bigger file downloads, I think, which is one reason they don't do it. A fully-rendered map has to convey a lot more information to your XBox than current forge files, which are just lists of objects and their positions/rotation, with the engine doing the rest. This is both a blessing and a curse - it means forged maps are highly easy to play with anyone any time, and to insert into matchmaking without injecting long download delays; it also means you can save a billion of them on your hard drive without taking up much space. Those are the blessings. The curse is that forge ends up being extremely limited, and 343 has so far not shown much willingness to, or interest in, finding creative ways to expand the mode's capabilities.
Does the Xbox one update games when its not on? If it does I could see 343 having a map editor similar to farcry's in which each player is required to download the map before playing it. Maps could be downloaded straight to your xbox automaticly removing some of the issues that 343 has with the farcry system. Otherwise we will just end up with another improved forge tool instead of a semi map editor.
Quite right. My comment was more directed at the "Halo Store" add-on benefit, not the dev kit itself. And for me, one of the benefits of expanded capabilities for community-made things is that they should be free to help remove any incentive to make gameplay-critical items such as maps for-charge items. For the dev kit, they will have to bank on making back their investment on dev kit sales, not store sales. And unfortunately, if the audience is too limited, there is no financial incentive for them to do such a thing. Oh, yah . . . totally agree. However, if you're just doing single player like we do for most customs, you could easily play on the unrendered map. The benefit is on the MM side - just like with the dev kit proposal. MM updates don't occur all the time, and there's no difference between DLC and fully rendered Forge maps (or dev kit produced maps) on the download side. If the same playability exists on the forge maps, then the need to spend money on CA maps for MM updates is minimal . . . meaning that maps no longer need to be part of purchased DLC. All 343i needs to do on their end is run the contests (which they already do to a limited extent) and, if necessary, pay playtesters (which they already need) for some extra time once the potential field has been whittled down. The dev kit would be the coolest thing . . . but I question whether there is a large enough market for them to make it in the first place. If they choose not to go that route, then I really hope they expand the capabilities of Forge to include object creation - which is already kind of there for zones - and manually selectable luminosities / hues / textures.
Certainly so. They'd have to make up their income in other areas, which I'd be completely in favor of but other players might complain about - selling stuff like armor permutations, armor and weapon skins, custom in-game icons, armor effects, etc. Basically a bunch of aesthetic junk that doesn't affect gameplay that people might be willing to spend a dollar here and there on. I'd much rather have them selling this stuff, if they feel like they need that extra revenue, rather than the existing DLC model that ensures it's difficult to even play the maps we pay for.
Throwing this out there: If the weapon skins get too crazy, could they affect gameplay? That is, could rainbow colored BRs be difficult to distinguish from rainbow colored DMRs? Insert whatever colors and weapons you want into that sentence.. Basically: How far can we go with weapon skins before confusing players? Can weapon skins cause gameplay problems? As an addendum: if this whole forge kit thing happens, will the skins be varied enough to act as collectors' items without causing problems? Is it better to just stick to armor skins and forget weapon skins altogether?
I was thinking about how we have consistently used the coli wall as flooring in both reach and 4 despite the rounding error introduced by rotating it off vertical. It seems that it should be easy for 343i to change the coli wall 's orientation so that it naturally sits as a floor. Or to give us the same block with a skin that differentiates it from the coli wall while having a floor orientation. Then the bump in the floor becomes a thing of the past. I mean really it isn't necessary to create a coli floor from scratch and forgers have shown REPEATEDLY how valuable it would prove.
As far as I know, objects shift even if you place them at their intended orientation. It's the large size of the coliseum wall that makes the shifting so noticeable, not the fact that it's sitting at an unnatural orientation. Or am I wrong about that?
I believe you're wrong. At their natural orientation they shouldn't shift. What makes them shift is that the map file saves rotation data, which is in a decimal format and truncated past a certain number of digits. So it's really not saving the precise rotation you've given the piece, but an approximation of it. Thus when you load up the map later, the object will be misaligned. Object position is saved more accurately, so the best way to deal with the glitch is not trying to fix the rotation but instead slightly adjusting the position of the object (or multiple objects) to minimize the bumps. Anyway, point being - at its natural position an object has no rotation value, and thus shouldn't shift. At least that's my understanding.
I think this explanation is absolutely correct, but there may be an easier way to fix it rather than position adjustment. I'm currently building a map where I'm using coliseum walls as flooring. On the rough build, I simply rotated them 90 degrees and stuck them together with magnets. Upon reload, all things were misaligned. So I selected them, went into edit coordinates, and memorized the height and rotation data. Then I hit "Reset Coordinates", and used the coordinate editor - not the analog sticks - to put them back into the original position. Once there, I moved the X and Y back and forth by one increment. In all cases, when I made an adjustment (including resetting coordinates) I waited about 5 seconds after they stopped moving before I deselected them to ensure that they settled in the exact alignment indicated in the coordinate editor. Saved as a new map. Reloaded. Upon reload, no shifting occurred. Now, if you then select one of them and use the analog stick to move it just a tad, save, and reload, unless you just happened to put it at an even increment, the wall acquires a bit of rotation error and is misaligned. I think as long as you use the coordinate editor for the final position - and you make sure you wait a few seconds after moving them before deselecting them - the position/rotation truncation problem can be fixed. I'm not sure all the bumps I described above are necessary - I was doing this in the course of building a map rather than a general test - but since the wait is only a few seconds and you only use so many large walls, the total extra time the bumps add is negligible.
.The correct fix is to refactor the code so that no data loss occurs. But my suggestion is a quick work around that they could use with the existing code. Here is a link to a more detailed explanation. Maximus I think you are just getting lucky. The problem can occur using your technique. On a side note I think 343i tried to help us. The edges of the coli walls can be hidden in each other. Take two walls and line up their edges. Then merge one into the other unit the dark edges are hidden. Even if a wall shifts you won't see it.