12-18-2014, 01:25 PM
(12-18-2014, 12:12 PM)alias link Wrote: As he said, i think the center of weight should be moved on players in co-op MP at least (didn't think about PvP yet), that's why i prefer players reporting/spotting enemies, objectives and not the AI, i don't want to see tags on enemies or markers for them on the map, and definitely i don't want aimbots or auto-aiming not that this has been an issue until now but it represents the extreme we want to stay away from it.
...That's why i'm not a big fun for guided rockets.
You are missing the point. There are two layers at work: The actual state, and what is presented to the user.
In Computing, there is a paradigm called "MVC", short for "Model-View-Controller". In this, a "model" is a dataset with associated operations, "view" is a presentational element (for example on a UI), and "controller" is the glue code inbetween that translates user action on the view into model operations. As an example, take the typical integer entry widget with two arrows next to a text field with a number. The model is the number and the operations "increase" and "decrease". The view is the code that draws the widget/control on screen. The Controller is the event handler that translates a press on the "up" arrow to an "increase" operation and so on.
In this example, the model always stays the same. It's a number and two operations. There is nothing in the view that makes any assumptions over the way the model stores its data. We can easily exchange the view, for example make it a slider, or a dial, or Mickey Mouse pointing at numbers with his hands.
The same thing holds true here. Your model is whether the officer is alive or not. The view is tasks or no tasks. There is no difference in the model (you could even have Clippy or Mickey Mouse pop up and tell you what the state of the mission is) regardless of what view you choose. What you can do, though, is determine when and how the controller updates the view.
What you are arguing about is the view, not the model. What Fuiba argued about is the controller. You are arguing against tasks as a view, and argue as IF it were the model. Fuiba argues about the controller and when it updates its information to the view. Fuiba uses tasks in his missions, and quite plainly, there is nothing wrong with tasks. They are the appropriate method to visualize progress. I think we can all agree that Mickey Mouse is poor at pointing out numbers in a range greater than, say, 1..12. A slider is good for values lower than, say, 500. Other than that, you need the input box.
Quote:The hard part in this approach is that you have to test the mission very well to make sure everything works, and you have to keep it simple and give hints visual/txt chat/sound without breaking the mission/immersion, we are all here for fun after all and i personally don't like puzzle games
This is not at all any different whether you use tasks or not. Your model is the same, always, and your controller code needs to decide when to consider the task completed. Whether you present that to the player with a task hint or a radio message (or, as I usually do it, both), is completely irrelevant to the difficulty.
Quote:For instance in my missions i use campfires, radio/chat message, vehicles or whatever comes to mind to "signal" the targets, waypoints or important area. The sense of accomplishment is higher when a player does something well without hand holding even with the help of some subtle hints.
I strongly object to your calling tasks "hand-holding", with all due respect, that is bollocks. A task that says (as in the flashpoint mission you quote below) "Escape the area" is in no way any more hand-holding than having a briefing saying "Escape the area"?
In Operation Flashpoint: Dragon Rising, the "hardcore" mode took away all HUD elements. They called that "realistic" and failed because there are information in reality that you have access to that are no more available in the game. For example, hardcore mode made it impossible to determine whether you had selected the grenade launcher of the normal fire, a bit of information that would be easily available to anybody because you usually know what trigger you are holding. Taking away does NOT equal more realism. It just means withholding information, information that the player is POTENTIALLY entitled to have.
Now, you think that withholding the information "Task Completed" makes the game more realistic. Which is what I object to. Of course, we COULD go about playing missions that draw out for hours because we don't know if the mission is completed, or we could play it to the end only to hear in debriefing that the mission was a failure. However, that is not what I would want to play.
Take my recent convoy mission. It has two objectives for the convoy: Prevent the armour from reaching the outpost, and (optional) destroy the complete convoy.
I could of course go ahead and just let you continue trying to mob up the convoy while the crew of the first tank is already getting drunk in Chernogorsk. Would be fun for the tank crew, but once we are at the end of the mission and hear from our CO that there was a tank that escaped and we failed the mission. So, the task failing is the best way to tell the players to not bother anymore.
A good example of what Fuiba was referring to is actually in the East Wind campaign. You have to kill a high-ranking officer after getting inserted by sub. The mission goes like this: You insert, kill a few perimeter guards, and then start to engage the town. After the town is cleared, you have to identify the target. THAT is actually a good example of how to do things like that, and it uses tasks all along without any supposed negative effects.
I don't need luck, I have ammo.