Jedi Knight (where I get my username) had a feature called "only pickup safe weapons" which is a similar concept. If you try to grab a weapon, and it picks up something dangerous to shoot, like a rocket launcher, it would not switch to it while you are intending to shoot something relatively safe. This seems similar, because priority should be given not to "safe" weapons, but to objectives OVER weapons. However, it might also be difficult to get the player to intentionally take the weapon near a flag if they desire... --- Double Post Merged, Jun 15, 2017 --- My request: CROSS PLATFORM PLAY (if what we think is going to happen for PC, actually happens)
True but I'd take that over picking up an smg instead of the flag. I also think the reticle override would get rid of the problem
I doubt it will be no sprint, but no sprint. It's negative impact on map design and weapon balancing in the context of a Halo game is undeniable. - Map scaling becomes incredibly awkward in a Halo with sprint. Travel times and distances between cover must be optimized with the max movement speed in mind. Engagements are not fought at this speed however, and it causes sprint to have the paradoxical effect on certain maps of slowing the game down because to move from cover to cover at an optimal speed requires the lowering of the players gun, punishing offensive play and rewarding more defensive play styles. This is not tactical, it is just clunky and it muddles with the fun. - Lack of controlled map flow, brought about by the long jumps made possible with the new movement, mean that to control map flow (and map flow must be somewhat controlled and predictable to be competitive), designers must upscale. This is limiting as close-quarters spaces become incompatible with a map that has a clear flow in its pathing and intention. - Inconsistency of travel times decreases predictability of movement, and in turn, the competitive value of the game as the random element increases through players having to use more guesswork to determine when and where players will appear, since they cannot know which travel speed their opponent will use. - Weapons are optimized for use against sprinting players (e.g. Sniper magnetism), yet are mostly used against players moving at base speed, breaking weapon balancing. This means blast radius', tracking strength, and aim assist/magnetism of certain weapons must be increased. As sprint makes maps bigger, weapons such as the shotgun need more range to compensate. When used up close in ranges more typical of classic games, CQC weapons become overpowered. Pretty much every issue with modern Halo has stemmed from this unnecessary mechanic, simply added to make inpatient people feel more comfortable. Anyone with an understanding of how Halo's mechanics work and a half-critical mind will know this. It is not a matter of opinion but a measure of experience with the series and critical thought. If Halo is to have a chance of being at least what it was, if not better, sprint must be done away with. All the improvements in the world can be added to Forge but it wont make me want to use it any more than I do now until the issues with the game I design for are addressed. For me, sprint is the root cause of all the other factors that have sucked most of the joy out of map design.
If we have the option to conjoin objects into a single mesh, that's likely going to complicate the budget. If we can join any number of objects into a single object, and have it only reduce object count by 1, then object budget becomes meaningless, as someone could conjoined their entire 1500 object map into a single object, and proceed to add 1500 more objects, which could then be joined into the first grouping, and so on indefinitely (leading eventually to a game-crashing map). Such a feature could work, but the budget system would need to be reevaluated. One option would be to have a budget based on polygons and/or vertices. Another other would be to eschew an object budget altogether in favor of a framerate/performance meter. We could also have a limit either to how many objects can be added to a single conjoining, and/or a limit to the total number of conjoinings. Another option would be to allow conjoining of objects, but still have it treat the object as multiple objects in budget terms. In this case, if you were to merge 3 objects into a single mesh, it would still remove unnecessary vertices (possibly only upon export, if we go the "export optimized map file" route), yet still subtract 3 from the object count. In other words, with this particular option, it would be about performance rather than budget-stretching. You wouldn't be able to build *more,* but what you did build would perform better. I personally would prefer to be able to use conjoining as a way to stretch the budget & build bigger and/or more detailed, but this is at least an option to consider. Anyone else have any thoughts as to how budget could/should work going forward, especially if we have options to scale, warp, carve, join, etc?
**** budget. it's unnecessary, and the number it is now is completely arbitrary. a properly optimized engine should allow thousands of objects before performance dips.
There is probably more to say about sprint and I know the argument (not that it should be called an argument) has been going on since Reach, but this one mechanic influences the design of pretty much everything else in the game. There are some good ideas on this wishlist but until the core mechanics are solid, no additions will make the game any better for me. Classic Halo was certainly not perfect, but the refinement of map design and weapon balancing that comes from a simplified consistent movement system, cannot exist in a Halo with sprint. Map design, weapon balancing, and movement, exist in a three-way matrix with each influencing the other. How can you possibly perfect the design of maps and weapons when the movement system is so inconsistent?
And any REAL spartan would be moving at top speed anyway. I pictured the chief just waltzing and skipping along and then activating sprint.
Ah yes I just remembered today that Favyn has summarized everything already, may as well link these videos every time that any of these debates come up! Next person to tell me that disliking sprint is just my preference, is welcome to resolve the scaling for my next map... I know it isn't impossible to design around all these abilities, Multi explained it well: Point is... you really shouldn't have to deal with all these hurdles to make a map, it's unnecessarily restrictive.
I would like to see some kind of placeable water so I can add rivers and waterfalls with multiple levels, also some bigger canvasses would be nice. As for the budgets, I would like to see them eliminated altogether, or at least get rid of either the object or physics budget, the combination of the 2 budget limits makes halo 5 forge unnecessarily difficult. It would be great to be able to sculpt your own terrain in halo 6. A couple of urban canvases would be nice too. Also I would like to be able to either spawn/script ais on forge or at least be able to create custom modes with ais. Last, YOU SHOULD NOT BE ABLE TO DIE WHILE FORGING! The fact that you can die by going over a kill boundary while in forge mode is the worst ****ing problem in all halo forge so far.
monitor mode should not do this, but spartan mode should kill because testing things in forge mode, where possible, saves a ton of loading/unloading time. It also sucks when you forget that tiny detail and have to go back into forge mode just to change it. They at least did fix having the monitor killed by scripts that kill players...
A multiplayer map rotation that includes maps that provide very different experiences. A scripting engine that works consistently.
Back in my day, the Gravity Hammer's purpose as a weapon was to **** with gravity and the physics engine. I used to knock back grenades, do insane jumps, launch fusion coils and vehicles, etc. Now it's just a Sword clone and nothing more (seriously, why does it have so much lunge now?).
I hear ya, but I still find comments like this a bit confusing. When and where is a script not working consistently? I have never seen that in actuality. It only seems like a script isn't working until you uncover the usually logical reason it isn't doing what you wanted it to do, which is a design issue. There are some things in the game that aren't intuitive, and a seemingly "broken" script might illustrate that, but again, it is probably doing what it is designed to do, but the scheme it sits in may not be working as you intend, which isn't necessarily the script engine's fault. I'm not saying you're wrong, but I have never seen something coded to do a thing simply refuse to do it. Do you have an example? curious...
Excluding move and rotate... We've gotten so used to that junk we forget about it. Tee-hee They fixed some bugs, but there might be some left I'm forgetting. But combining what you both said, it could use some reworking to make it more intuitive what the actions and conditions do.
haha yeah, refinement for sure. I want to work with the scripters guild to come up with an exhaustive list of things that should change. That is, a wishlist specific to scripting, but more importantly, calling out the game's bugs and undocumented features that interfere with scripting at times. I think that's my point, really. The scripts themselves don't just wig out and not work. They always work. But, what doesn't work, is our understanding of how they should work, and how that interacts within the game. So, if there are any bugs they are in our heads and the game. Often times, less experienced scripters would not do the scientific testing to figure out why something didn't work, but just assume "meh, just like other things in H5, this sucks too". I would like to get people to think differently about this, because while at times I have felt the same way I have also learned that I have been wrong. EDIT: Rotate and Move are a case in point... they technically "work" but the game interferes with how satisfactorily they operate for our purposes. For instance, if you tell an object to move via movement script alone, doesn't it always move? It just looks really bad...