So... back on wc3, I have a friend who implemented save/load features for a game so that players could save their stats. Somebody cracked their code, so they came to me and I put in rather advanced encryption. This person then, rather than cracking the code, opened the map via an MPQ viewer and modified the JASS code inside to give them cheated codes. Good map protection would have saved his game. Due to all of the code resets, most people have quit playing his game.
In games with lots of information like TKoK, the save/load codes are really massive. In some games, people have to type in 100+ characters. These games also save very little information =|. Codes can be used to save things like ratings for a mini-game or character information for an ORPG.
The next problems that arise from save/load codes are item trading and abuse of the open access to codes. For example, a player might save their character and then trade their item to another player and have that player save. By doing this, they have duplicated that item.
Players might abuse save/load codes in mini-games where ratings are saved. If a player loses, they won't want to save their code at all. In this way, every player will end up having 0 losses and the highest ratings possible.
The abusing can also occur when data is saved to a player's hard drive. They can just modify that data to be whatever (even if it's encrypted). They can, for example, change the data to some older data they had for the map, thus avoiding a loss.
So, by not supporting map protection, it welcomes cheating in maps (from mini-games to games with persistent player data). By not supporting persistent data online (off of the player's computer), this welcomes player abuse.
Also, I don't think that full mods will be that popular by anyone as it sounds like these change the actual game. Players only go for things that are easy to download and play through the client, meaning that full mods will probably never be popular, meaning that most map makers will be doing scenarios.
Also, ORPGs are an extremely popular genre. Supporting them, I think, would be in DoF's best interest, otherwise how is DoF to compete with SC2, which does support persistent data and map protection. DoF should use a better persistent data design (online persistent data rather than local) and map protection, thus offering superior tools to people who want to make their own scenarios.
The next thing is only support for 8 players. This really does seem like a small number, especially when Blizzard, the dominator of online RTS games for the last few years, has always used 12 (a 50% increase).
The game's longevity is not based on its regular gameplay, but on the modding community and the ease of getting things like scenarios (as I stated earlier, I don't think full mods will ever be popular). Maximize what can be modified with simple scenarios to increase the quality of custom scenarios and to increase the likelihood of wc3 and sc2 modders moving over to DoF ; ). As it stands, a lot of modders are unwilling to move because of the lack of features (including myself ofc).
The question that I'm asking myself right now is, "why spend money on a game where players can cheat on anything that is made." If you look at the major modding sites like hiveworkshop.com and thehelper.net, the modders hate cheaters. A lot of time is invested in anti-cheat packs and security ; |. In ORPGs, systems are made that prevent players from trading items to stop abuse of save/load codes.
If the needs of modders in these major communites are addressed, they will surely move from wc3 and sc2 to DoF =). I'm sure that these major sites would also support DoF if the modders on them supported DoF, which would increase accessibility to custom resources and modders (easier recruitment for projects), thus increasing the longevity of the map =).
The Warcraft 3 modding community is still thriving because a lot of modders dislike SC2. I know that I didn't get SC2 because it actually added limits and removed features =|.
This isn't about "we probably aren't going to support that," this is about what the modders actually want. If you support certain features, you'll get more modders willing to move to DoF. If you decide to not support certain features, then you lose those modders and future modders that would have otherwise moved to DoF.
Why will a modder mod for DoF over SC2 or WC3? When they read the capabilities, some key things that will stand out are "persistent data" and "model/animation editing" and "terraining" and so on. If SC2 is superior in all of these, then why would they get DoF? The only thing that seemed to really stand out for me in DoF was the Lua, but even if it's a better language, what's the point if you can't actually make the games in DoF that you can make in SC2 =\.
Also, for features, I suggest you let modders know about the scenario size limits, scenario linking, and file size limits. These are major bonuses that DoF has over WC3 and SC2. Also let players know that local data similar to GetLocalPlayer is possible ; ).
This, for example, is a popular wc3 script for clearing text messages for a specific player
if (GetLocalPlayer() == player1) then
Local data is also useful for displaying information to a single player.
Yes, DoF might have like limitless capabilities for single player full modded games, but compare the popularity of single player games to online games. Furthermore, compare the popularity of fully modded things (even tools that extend the game) to just vanilla stuff. RtC was fantastic and a lot of modders loved it, but the players wouldn't download the thing, so the entire project had a very limited audience and only a couple of maps were made in it (only played by a few modders ofc).
Now, if there was a way to join a game through the client that was fully modded and play it online, that'd be another story, but I doubt that that's supported =|. Assume that 99% of players will only play games through the client and will only download games through the client. This means that you can also assume that the majority of modders, with the biggest target audience in mind, will make games that can be played online and downloaded through the client. Supporting fully modded games is fine and good, but in all the time wc3 has been out, there was only 1 fully modded project, and that one was never even finished.
Oh yes, and terrainers like to be able to make things like caves and underground tunnels as well as change camera perspective to something like first person. The first 2 are accomplished in warcraft 3 via masses of doodads. The third one is only really ever done in single player due to delay on multiplayer.
Also keep in mind that 2D games and side scrollers mght also be a goal. For example, there have been a few side scroller games in warcraft 3. In SC2, someone made Bomberman -> http://www.hiveworkshop.com/forums/s...%3D20%26t%3D69
And ofc, things like floating windows are also very popular in both Warcraft 3 and Starcraft 2. Just look at how much effort goes into making full screen custom UIs (generated by 2D images and etc) http://www.hiveworkshop.com/forums/s...Dlist%26r%3D20
If you notice, the above system was fully scripted. You can even see the terrain tiles present through out the window.
This one here is an immensely popular hero pick system
I'm just trying to show you guys what modders want and what they want to be able to do.
Another major thing is projectile systems, which is why I talked about being able to reference a projectile and even change that projectile's motion or whatever.
Ofc, modeling and animation is also very important for moddelers. Being able to attach things like an item to a model in-game is also important (like Warcraft 3's attachment points). Being able to rotate a model any which way in game is important. Being able to make a unit's position be relative to another unit is also important (if one unit moves, the other unit's position also moves). An easy way to support that last feature is to have support for changing the origin to whatever location (including a possibly moving location that comes from a unit). The default location would be the origin (0,0,0), but this location could change into something like a unit or a tree. From there, the second unit can still move and what not, but it'd also be relative to its set origin. The angle of the unit relative to the origin should also be able to be changed. This would make things like rotating circles and spheres extremely easy to do.
Text tags are also widely used ;p -> http://www.hiveworkshop.com/forums/s...-0-3-a-204524/
Also, 16 tiles in terraining isn't enough for high quality scenarios ; )
Another feature that would also be cherished in tower defense/tower war games would be a path exists function. For example, DoesPathExist(unit, point) or DoesPathExist(point a, point b). If the unit can't get from where it is to the point, then it'd return false. If it can get there, it'd return true. Coding an A* Pathing Lua resource just seems silly when DoF already has that coded in c++ : |.
Also, a Kd-Tree with the units in it and easy ways to loop through it would be nice, this way nearest neighbor searches or searches for units within range of another unit can be done.
Another thing is a way to benchmark scripts =p. Right now, people are using stress testing (how much it takes before the computer freezes) to benchmark wc3 scripts ;|. Back when RtC was working, people used its stopwatch things.
Anyways, I suppose that that's all I have to say ^)^. I've shown precisely what modders want and what is popular. It's up to the DoF team to decide whether it's worth implementing this stuff or not =).