A Picture in picture dialog- priority 3
why, to allow map maker to have a dialog show up that shows what is happening at a specific area of the screen.
Use: Allows mapmakers to show their players more than one place at once.
Haven't been here for weeks, and now I found this nice thread.
Still not too late to post a wishlist?
Well, pretty much everthing Ahli and SoulFilcher posted, plus:
Feature: A arcade filter for expansion-level
Use: So that the WoL players won't accidentally click the HotS map icons.
Feature: A 'Display maps which contain #Current Client Language# locales only' button:
Use: The arcade of TW/KR realm is full of KR maps, TW players can't effectively find maps localized in Chinese. Such a button could help them alot.
Some official fantasy-themed optional assets Mod
Use: Fantasy theme (WarCraft/Diablo themed assets for example) is really needed for future-expand the genre of arcade games. The StarCraft II itself is a bit too sci-fi for some game genre. Of course modders can create custom models via startools, but it would make the Mod too big to be spreaded since you need tons of custom assets to change the whole graphic style.
Enable editor's Test-Document feature for Start-Edition account
Use: Let's face it: The editor is already hard to master. The requirement that you need to buy the game first before you try the editor raise the bar higher.
I know tons of WC3 modders failed to switch to SC2 because of these two reasons - Some of the modders even chose to use crack tools to gain access the 'Test-Document' feature. Basicly if one chose the crack tool, he will never switch back to the genuine-user world.
While allowing Start-Edition account to test the editor, they can still be counted as members of the player-base, and they may even want to ask their friend to help publishing their games after they learned the editor.
Make custom race selectable in game lobby
Use: So that we can actually select customized race with their corresponding customized UI.
More Unit Attributes(Editor Feature)
Use: We can always use more Unit Attributes to create systems like WC3 armor types systems etc.
I will direct Blizzard to read this thread, good suggestions Renee.
At the end of the day I have to put forward issues that directly affect our development, as such, many issues that you guys wanted changed we wanted as well. For those that are interested, this is what I am sending to Blizzard.
Developer Experience Stuff
Feature: Financial Support
Feature: Developer Summit
Feature: Employment Pathways
Feature: More communication between Blizzard and Developers
Feature: Change the background colour of the Trigger/Data editor etc.
Feature: Offline Editor
Player Experience Stuff
Feature: Standalone Launcher and Matchmaking
Feature: Free To Play Arcade
Feature: Download Map/Mod BEFORE entering lobby! Pending Players are bad!
Feature: Server-Side storage of player data and global data
Feature: VIP Developers should get more storage
Feature: Map/Mod Encryption
Feature: Arcade should be expansion free
Feature: DNS Server for Map Links
Feature: Linking Maps on the Fly (Multiplayer Campaigns)
Hate the term "VIP Developer", but yeah. I find myself not really enjoying this 20 map limit. I like to have names reserved, test maps ready, and leave my older projects live. It's becoming increasingly difficult to do that.
What I posted was merely the headers of what I wrote, I did not see any reason to post the explanations etc.
@ ArcanePariah on the IRC, the question was asked what do we need; I responded as such. Some of them will fall into 'pure fantasy', the others will fall into 'easily doable', but that was the whole point of the exercise - to get an idea of what we want in a perfect world.
As to whether or not it would be cost prohibitive, it depends on where you want the arcade to go. If you want something that could rival steam in regards to Indi Projects / User Created Content then it would be wise to meet the bulk of these suggestions. If not, and it stays merely an internal sub-feature of Starcraft II, then yes, you are indeed right and there is very little reason to put in any of the more advanced features.
We have never hit the doodad limit and our Arenas are quite bland for the most part, so this does not affect us as much, but I completely agree with your statement. On a side note we did hit the unit limit whilst making Evo Wars X :)
The doodad limit as a whole isn't a huge issue (though we're likely to hit it in Starmon), but it's more that - to me - it looks like the easiest thing to fix ever. It seems like Blizzard just input a number for the maximum amount of doodads you can have in a map and that it would take them literally one minute to change the '1' in the number to a '2'. Also, the limit serves no real purpose, I think?
True, the feature request was indeed open ended, and depends on what one considers an "End to end game experience". I would indeed like nearly everything on that list, but I'm not entirely sure Blizzard is ready to become like Valve/Steam. Who knows.
As to stay on topic, the sole thing I would request is more documentation, and maybe some more technical oriented tutorials explaining abstract concepts that govern how the editor workflow works (Things like explaining the hierarchy/inheritence in the data editor, more of the actor messages, and actor concepts).
As for things like 512x512 and other limits raised, I agree, it almost certainly is a memory limit, my map can drive RAM usage (with maxed out graphics) to 2 gigs. I think the greater concern is Video RAM, making a 512x512 raises the possible memory requirements massively. My video card almost maxes out its VRAM in sc2, I can quite see having more textures or larger maps size flat out maxing out any gpu and causing gameplay crashes.
Slightly updated my initial post with more suggestions.
We know that some of the following suggestions might be unrealistic or very hard to implement, but please take the time to read through them and think about what impact they would have on the modding scene!
Feature: Asynchronous player input / local triggers
Priority: VERY HIGH
We desperately need a way to make mods with a custom controls system feel more responsive. The Arcade will never unleash its full potential if its not possible to create mods with custom controls, since it will always be limited to the default top down view. Almost all games which use custom controls have bad ratings complaining about lag and "bad" controls. This needs to be improved.
As an example of how this could work:
There could be special "local" triggers which just allow certain events, conditions and actions which don't require the game to be in a synchronous state. Examples for events would be key presses or camera movements. Actions could be interaction with the UI for a specific player, camera modification, Actor modification, ...
Yes, making single player games running locally by default is a good first step, however I don't think it resolves the core problem. We want awesome MULTIPLAYER experiences using custom controls!
Implementing asynchronous player input support would make it possible to create shooters, side scrollers, racing games and so much more! Yes, its a huge task, yes it will require a lot of work, but its essential for the Arcade to develop into something bigger!
Feature: Server-side storage of player data and global banks
Priority: VERY HIGH
Server-side banks have two advantages over local files:
- Bound to account instead of computer
If Blizzard expects more professional developers to start creating games for the Arcade they have to ensure that there is a save way to store player data for their projects.
In addition, it would be awesome to have to possibility of "global banks", bound to a specific map or maybe even the entire account. A global bank would basically allow to store global data for the map, such as highscore lists. This would open up endless possibilities and could even be used to create statistics together with some sort of simple time API!
Feature: Multiplayer Campaign / map linking support
It would be awesome if it would be possible to upload entire "Map Packs" instead of just a single map. A map pack would basically be a collection of maps which belong together. Players would HAVE to download all maps of the map pack to play any of them, enabling the possibility to load any map from the map pack with script while in the game.
This would allow mappers to create entire campaigns and also help solving the map size and map texture limit problem, since we could simply load a new map for each zone in the game!
Feature: Improved support for games not using default camera
In addition to the key input delay problem, ambigious modders also face the problem of a game engine which has a lot of trouble dealing with games not using the default camera view. This is obviously because StarCraft was optimized for melee games and top down view.
However, it would be awesome if there would be features to support games which dont use the default top down camera, and use a more three-dimensional camera instead for a first/third person look, like shooters or RPGs.
The following features would allow us to create AMAZING games:
- Level of Detail system: A Level of detail system would basically reduce the detail of all doodads/units/terrain textures depending on their distance from the players camera (far away objects would render with very low details), allowing modders to use a much higher farclip without causing huge FPS drops. As of right now, modders have to use a very low farclip and fog effects to make games like this possible, which looks very bad.
- Automatic 3D Camera Collision System: It would be awesome if there was a way to enable some sort of camera collision for 3D games. It is possible to create a 2D (note: not 3D!) camera collision using triggers that check pathing and current camera position, however those solutions are effected by battle.net delay (See „input lag“) and therefore dont work well over battle.net. In addition its impossible to simulate 3D camera collision using script, since there is only 2D pathing in the game.
Feature: Containers for the galaxy programming language
It would be awesome to have containers for the galaxy programming language, which could store all basic datatypes like integer, string, fixed, ...
We already have containers for units (unit group!) and players (player group, which is basically just a container for int limited to a length of 16 and numbers from 0-15), so why not add them for all important data types? This would be INCREDIBLY useful!
As a programmer I seriously think that one of the most common used features of every programming language I've used so far has been its containers. It would also make it easy to pass/return lists of data to/from functions. (See Unit Group which can simply be passed as parameter and returned)
Feature: Full environment modification support via script
This would include smth like:
- Getting terrain texture at point
- Setting terrain texture in area
- Changing terrain height
- Adding/removing cliffs
- Adding/removing water
- Placing doodads with collision without having to use units
A full blown API like this would open up endless possibilities for creating randomized terrain to improve replayability and awesomeness of mods! It would also work towards resolving the map size problem since there could be workarounds like using "portals" to warp into another zone (Which would basically just generate a new terrain etc.)
Feature: Better and more complete documentation
The editor is still missing lots of documentation, not only in the data editor but also in the trigger editor, which often misses important details about specific functions (What happens if parameter is null, possible return values etc.). A good example of this is the "Player of Player Group" function which returns the player within the specified player group at the selected index. Its not clear if the index starts at 0 or 1, so as a programmer you have to guess and test.
In addition there seem to be lots of missing patch notes about editor changes. Almost all big patches do changes to the editor which are not listed in the patch notes but can still have a big inpact on projects. Its important to know if something changed about the editor, no matter how minor this change will be. As an example, in patch 2.0.10 the global variable size limit has been increased significally but this change was not mentioned at all in the patch notes, however it might have saved a project relying on those changes to be able to continue.
It would be awesome if Blizzard could work on this, so we don't need to manually go through the entire editor to find possible changes (by accident) each time a new patch is released.
Guys, considering the amount of requested features is really huge and blizzard can't work on all of them, what do you think about creating a survey asking for the most wanted 3-5 features modders really want?
I can create the survey but I need someone that can help with a pointed list containing a summary of all features proposed on this thread. Anyone offering?