Skip to content

Steam Roadmap

Jump to bottom Edit New page
Анархид edited this page Jun 25, 2015 · 5 revisions

Roadmap and stuff for greenlight release (...now doubles as emo diary.)

There is ONE greenlight release. Failure is not an option.

After release there is not time for fixng, players leave quickly if the game is buggy.

If you plan to fix things when they are reported by newbies, then you already lost: Players are NOT beta testers!

Annoyances to existing players can not be avoided

Preparation for release will likely require actions that will annoy existing players: *deleting custom Commanders *reseting elo *limiting map pool *changes to lobby or game

''(those were random examples)''

Even if that annoys you, please understand that these things might be nessecary.

If you want to help the game, then do not bypass it: For example should map selection be limited, then it is not helpful to create custom hosts just to play your favorite map.

Likewise devs will need the courage/nerves to do things despite causing existing players to whine.

###STATUS:

  • ...There seems to be hesitance when it comes to doing certain things.

Feature freeze

  • It is not possible to test and polish something that is constantly changing.

  • Adding new things that risk to break the game should be avoided.

  • A spring game is never "100% ready" but when critical things like GUI, gadgets, widgets are being changed around then the game is not ready for launch.

  • It is impossible to do manuals/videos of an interface that always looks different.

STATUS:

  • ...stuff get changed too much.

May 2015:

  • things still gets changed around, new features are added, fundamental elements (like resource display) get re-designed, new big features (modular commanders etc) get planned,...

Network with other spring things

No spring game exists on its own. Each "sub system" must explictely state state that it is ready for launch.

Something is not ready ==> abort launch.

  • engine
  • lobby
  • playable content (game, missions, tutorial)
  • download sites
  • lobby server
  • manual, FAQ
  • auto hosts
  • ...

STATUS

May 2015:

  • parallel discussion of same the problem in multiple places escalated problems
  • "Developer diary" threads hidden between unrelated threads about submarine balance and other non-important threads
  • lobby, server: server-split after failure to communicate/find common solution with rest of spring
  • engine: after long time of using old engine, now brand-new unreleased test-engine version is used

Interaction with Steam

Legal entity to talk to steam.

Multiple people need to have the rights/passwords/knowledge to publish new versions etc.

Not good if a new version needs to be released but it must be waited 24h for the only steam-admin to get online.

STATUS:

FAQ

An FAQ is needed to get help to players.

Note: An FAQ is something that gets written after release, when new problems pop up.

If you think of writing an FAQ now then you should rather write a bug report or feature request.

FAQ engine

For engine trouble, the engine FAQ and bug tracker should be used.

STATUS:

  • The engine FAQ could need some updating.

May 2015:

  • nothing

Organization / Planning

STATUS

  • Strong resitance to anything that loosely relates to organization: Any attempts at even smallest guidelines ("how to use bugtracker") are at best seen as "nice to have but not crictical", more often seen as negative idea-guy-blabla.
  • Instead of tools like bugtracker or wiki, a forum is used.
  • A forum with no code-tags and no proper search function.
  • The wiki is not used because there are plans to write to an own, new wiki-software =** wtf!**
  • Now even a google-document was used, it seems to have been forgotten already.
  • As result: No overview how close/far the progress is.
  • user downvoted/"flamed" for investigating bugs, for ex. http://zero-k.info/Forum/Thread/14163
  • With no visible organization at all it seems too ineffective to contribute anything.

Bug reporting

For new bugtracker on github there need to be some standards. For example closing solved isses, using tags.

  • Needs a way to mark issues that are "steam-critical" to get an overview. ("Nicer model for bomber" is not steam-critical but "Tutorial crashes" is.)
  • Suggestion: Prefix title with "STEAM" - eg "STEAM: Tutorial crashes"

STATUS: getting there.

May 2015:

  • The new bugtrackers at https://github.com/ZeroK-RTS/ has become same mess as old bugtracker at google.
  • Both bugtrackers are active in parallel. wtf!
  • no sorting into categories is happening
  • All "How to report bugs" rules are broken: no details, no version, bad descriptions
  • game-Version is almost never mentioned, making it hard to figure out if a bug was already fixed or not.
  • Bugtracker is not used all that much, more common threads in forum.
  • Problems are accepted as "everyone knows about it" and not added to bugtracker

June 2015:

  • Ticket count is decreasing, issues resolved daily and investigated
  • googlecode bugtracker almost unused but still exists (wiki reimplementation required for deletion of project)
  • Ticket discussion (in PR and Issues) largely overcame dev use of forums

Helping one player does not fix the bug

Any problem needs to be reported: Noob: help, something is broken. Dev: ok, delete this file blablabla go to menu XY. Noob: thanks, now it works.

After such dialog the problem is not solved!

Only one player was helped, many others will encounter the same problem again.

STATUS:

May 2015: *excactly that still happens. After the problem is 'worked around' it is not added on bugtracker or FAQ

Bug reporting (non-dev players who want to help)

Try to read most of the FAQ etc and keep a bit up with development, so that you give the correct help.

Many times newbies will simply state their problem in chat. They can not be expected to fill out a detailed bug report. Be on the lookout for that. Report problems even if they did not happen to you.

Where can newbies report problems?

Players need an easy, hassle-free place to report bugs. Where should that be? *zK Forum: requires having sucessfully registered a springlobby account - not good. *github: No normal gamer has a github account. Site is too "intimidating." - not good. *google.code: google accounts are somewhat common - might work.

Still bug reports ("complaints") will be all over the place: It will be nessecary to read reviews, steam forum, everything, and fill it into the dev bugtracker.

Any plan that relies on players helping newbies will not work

  • The idea that "lots of moderators can help players" or "experienced players can help newbies in chat" is naive.
  • Manual helping is a band-aid, not a solution.

It is false sense of security to think "zK has more experienced players than other mods and so will be okay." If you already have the feeling that newbies will need help, then improve those areas that give the bad feeling.

Small pre-release before big release

A test-launch of some sort might be good: Instead of thousands of new players, only a few dozen. That can help to fix problems for the real release.

For example:

  • release on steam as "beta" or "pre-release alpha" or what other options greenlight offers
  • Announcement on steam: "This is our final release-test"
  • release on a smaller plattform first. (for ex desura) But risk of having to maintain 2 things in future.

STATUS:

  • ...need to check what options there are?

May 2015:

  • a note on download page that asks players to report problems was not wanted: "makes us look to unprofessional"

Engine version

  • Use newest version: Engine devs refuse to deal with problems of old version.

  • Should be tested for some weeks.

STATUS:

next engine version is not released yet.

May 2015:

  • unreleased test engine version (98.0.1-451-g0804ae1) is used. Stable would be better.

Matchmaking

  • Gamesize needs to be limited. In a 8v8 with newbs, too many will crash out or be noobing around, a game will never this way start. Similiar with speclimit, it is not desirable to have 30 newbs stuck as specs.
  • Possible solution: Limiting roomsize & speclimit is more robust than any matchmaking algorythms. It reliably works with all lobbies. If there is flood of players then trying to balance does not even matter: Everyone is new, many will have problem.

With such playerbase there is initially no need to care about balancing, the only thing that matters is that players get to play as many matches as easy&fast as possible.

Another situation that needs to be accounted for: "We are four newbies and want to play together, without other players."

STATUS:

...?

May 2015:

  • no upper playerlimit on rooms
  • lobby looks like this: http://imgur.com/kCoqK0B
  • some pools and discussions about matchmaking, several systems were tried: no idea which discussion relates to which system.

Packaging

  • The "package" that players download from steam must contain everything needed to play.
  • If there is a dozen newbies in a room and half of them are waiting for map-dl to finish, then no game will ever happen.

Another way that might work is that the lobby downloads everything (as is now) but then... ..that needs to be very clear. ..spring server must be able to handle it.

  • Maximum size should be ~1GB: Too large and it causes annoyance if one has to re-download etc.

STATUS: bugged

  • ...solution needs to be decided and implented...?

May 2015:

Map selection

  • Newbies do not know which map is suitable for FFA, 1v1 or chicken or what teamsize. They will randomly play anything.

  • The maplist must account for that and only contain maps that are suitable for as many game modes as possible.

STATUS:

...There are "featured" maps but those are way too many.
A map list proposal has been added to the wiki.

May 2015:

  • The map pool from above list and the actually featured map-pool are different.
  • random featuring & un-featuring as maps go in&out of fashion.

Testing

*"I played zK for 3 years and it seems pretty ok" is not testing. *Everything needs to be througly tested, from download to tutorial to ingame. On different systems. *Best to record it (openbroadcaster, twitch.tv, anything) and share for analysation. *Newbies should be encouraged to record/stream their install-to-game process so it ca be learnt from. Even one such video would be more helpful than endless discussions.

STATUS:

*Game is not tested beyond normal playing/modding. *There are no reports how geniue newbies react to the game.

May 2015: *a bit of benchmarking has been done to see which engine version gets better FPS: http://zero-k.info/Forum/Thread/10027 and http://zero-k.info/Wiki/Benchmarker

  • asking newbies on download-page for feedback was not wanted
  • no testing regarding userfriendless

Ingame Interface

*Must work out of the box, without tweaking. *No "moving that menu a bit too left", no "making this list a bit bigger", no "change cameraspeed": Delete all your configs and custom configurations because that is how new players will experience it.

STATUS:

*Nobody is playing with default interface. *GUI is constantly being worked on and not final.

May 2015: *Seems still nobody uses default GUI, on every screenshot/video it looks different. *GUI is constantly being worked on and not final, camera widget too

Hotkeys

*Hotkey selection should be clearer. Epic menu may not be the best framework for this, as it uses a simple list, while most RTS games either use a grid or a tree. *"Construction Hotkeys" in should probably just be removed (Integral Menu/Command Panel deals with this in a gridded fashion, its alternatives also have their own way of doing production hotkeys). *"Selection Hotkeys" could probably benefit from some thought given to the various groups this may be useful for. Rise of Nations is a good example of type-based selection hotkeys done very well, though that game only applies them to buildings.

STATUS:

*Integral Menu/Command Panel has production hotkeys laid out in a gridded fashion. *Hotkey assignment menu uses internal names for Command Hotkeys, should be more human-readable. *Hotkey assignment menu uses clear names for Selection Hotkeys, though maybe more group options should be added.

Tutorials, Missions, Manuals

*The tutorials must be 100% clear and work. Needs selection of first few missions that newbies play. *Missions that teach the game are more important than missions with story. *Missions needs some tracker that shows how many newbies tried to play the mission and how many completed it. *Until release maybe re-enable "manual download" link, to get non-zKlobby users to test too.

STATUS:

*Comments under missions report many problems. *It is not known if/how many newbies are completing the tutorial.

May 2015: *still the same *with the introduction of Spring.Reload() the web-based menu seems antiquated.

Videos

*Instruction video is needed that explains the game in 1 minute. Not. Longer. (No longwinded "blabla video-diary style.") *Must use default interface. *In such video it is not nessecary to go into too much detail: It is about teaching the bare minium to play.

There can be more videos on specifique topics like hotkeys, eco in detail etc.

One short video per topic: Unlike written text, videos can not easily be edided if things change.

It is easier to make one new "hotkey video" instead of editing an hours-long supervideo that tries to cover everything.

STATUS:

  • There are no instruction videos
  • The manuals are bit outdated (screenshots etc) and it is not clear in what order they should be read (?)

May 2015:

  • still the same.
  • the GUI is still changing, no use to record videos or make pictures

Unlocks / Commander Modules / Newbie rooms

  • Too many buildoptions are confusing = bad.

  • It is not possible to make a tutorial/video/manual that explains the game when even the basic construction unit is always a different one.

  • Many different Commanders are bad: ** They require [i]one more[/i] menu to navigate. ** If the resource-income is different among them, then it is harder to learn(teach!) buildorders. *** Tutorials would then need to take that in mind, too. ** Morphing the Commander too soon can be a newb-trap.

STATUS

May 2015:

Suggestion to Newbie-Hosts:

  • All the newb-trap-units are strictly locked. (no nukes, no singus, no antis etc)

  • Only two factories: One vehicle, one bots. ** (No water, no air, no anti-air: The game is complex enough without them)

  • One type of Commander.

  • There is no way to unlock things. ** To play with full unitset player has to go to a normal room.

  • The newbie-hosts are limited to even fewer maps: ** These are 1-3 special "newbie-maps" with VERY clear design: *** Arrows pointing to metalspots, markings for good defense places, roads towards enemy. *** Signs on the maps with the kind of hints that a helpful teammate would give: "Defense here", "At start take those 3 mexes" *** The start area is similiar to the location used in tutorial. (in ex. middle of 3 mexes, geo) **** This way things learnt in tutorial can directly be used ingame. *** Fixed start locations are used instead of free choice. This takes care of another newbtrap.

If this seems too strictly limited then think: *Newbies will be overwhelmed in their first games anyway. *In your first game you can only play on one map and with one factory anyway. **Better make sure it is a good map and a noob-friendly factory ***Preferably the factory that is best explained in tutorials

STATUS:

*There are different opinions how unlocks/modules/newb rooms should work.

May 2015: *There are different opinions how unlocks/modules/newb rooms should work.

Keeping track of events, statistics, measuring sucess

  • A "diary" of notable events should be kept: Learn from past, avoid making same mistakes again.

If you graph the numbers of any system, patterns emerge. Needs logs or graphs of:

  • players numbers / new players
  • players idle/ingame/in room
  • stats about mission: who played, how often, what outcome
  • stats about players: how many games do they play / do they leave after 1 match?
  • server logs like dl bandwith etc

The graphs need to be in a sensible scale so that one can see cause & effects.

For example it is helpful to know "On same day as update #342: ingame player numbers dropped" Not so helpful if the graph only tells "drop was somewhere in novembre"

  • These analysis should be collected in one place.

Steam has shown potential to bring hundreds of players at once into lobby: Currently zK has ~30 players playing at peaks, if that was to grow by 10 then that would be a relative sucess but the large missed potential means it would ultimately be a failure.

STATUS:

  • There are some public statistics but they are scattered and I am not sure how helpful they are.

May 2015:

  • There are no good stats
  • This page is now a diary

Understand that the game is NOT easy

We all do complex hotkey combinations and mouse-wiggles while playing as if it was the easiest thing in the world.

  • BUT: Do not confuse ''powerful'' with ''easy''

The gamedesign of zK is in ways uninuitive and even basic things are hard to explain without lengthy descriptions. That can not be changed anymore, but good to keep in mind.

For example a Starcraft tutorial might say: "Left-click on an SCV to select it, then rightclick on a mineral to mine resources. Leftclick the commandcenter and click the "build SCV" icon." That covers everything.

In zK a tutorial might say: "Select a commander in menu. Select a startlocation in your box and near metalspots. Go to the eco-tab of the buildmenu. The game is not really started yet, but you can still do that. Select the metalextractor icon and click on a metalspot."

It is many more steps and there are more things to do wrong. (for example the map might have no near metalspots for that player) ''That is why simplified newbie rooms are so important.''

STATUS

  • "powerful" gets confused with "easy" n/a

Communication to newbies (technical)

A way is needed to announce things to newbies. For example:

  • "The lobby server will restart and be down for 30min"
  • "Singleplayer is currently broken, hopefully fixed next day"
  • "You absolutely need to do XYZ or the game will not work"

How can such things be communicated to all players?

  • Annoucements on steam
  • lobby-broadcasts
  • sticky forum threads
  • "wiki status pages"

...will all be needed and must be maintained.

  • The "news" pop-up of lobby should be used for this, too.
  • Sticky threads should not contain text but a link to a wiki page: This makes updating easier and avoids having old infos lingering around.

STATUS:

  • ...there is lobby-popup-news on login, bit ugly
  • ...?

May 2015

  • Choatic
  • Last status post on steam was one year ago, from steam's user point of view game might as well be inactive
  • Since the split: no zero-K have been posted news on springrts.com
  • In the situations that required communicating info to players there was much confusion and misleading. (lobby/server split)

Talking to newbies (style/social)

  • Players will be very blunt with critic.

The comments will not be as positive as before release. Before release players are more positive towards the game because their opinion is solely based on descriptions and videos and that When something does not work then they are rightfully annoyed. If a review reads "The interface is shit and the crappy AI always gets stuck" then you STILL can NOT reply in the same tone. In intern discussions "anything goes" but whenever you are posting in public steam forum you are representing the game.

Some statements that in any form are unacceptable:

  • '''"It is open source, go help fix it."''' -- they are players, not developers.
  • '''"The game is actually very easy and casual"''' ** A game with 100+ units is never easy. ** A game with so much focus on interface & hotkeys is never casual.
  • '''It is free and you get what you pay for"''' ** Free software is a selling point or "ideal", not an excuse. This WILL annoy players who got attracted by the OS part
  • '''"You are too stupid for xy"''' ** obvious.
  • '''"Game/Lobby XY is even worse"''' ** obvious.

'''If you feel you can not communicate without falling into such behaviour, then stay away from newbies.'''

That also goes to players who might want to defend their favorite game. Do not be an overzealous "fan boy"

No false joke advices, no matter how obvious it seems to you:

No "CTRL-A, CTRL-D for more overdrive", No "Build another 12 storages"

Instead of trying to come up with own solution, stick to what is written in FAQ. If needed, expand FAQ.

For engine trouble, use the engine FAQ.

STATUS

n/a yet

Be honest

  • There is nothing wrong with saying "We do not know why that bug happens" or "I do not know if feature XY can be done"
  • It is not helpful to contiually promise fixes or tease with new features and not deliever.

STATUS

May 2015:

  • announcement on steam-forum about release date ("soon", "two weeks" etc) were not realistic
  • PlanetWars seems overly present (entry in menu even if not running since long time, often described as more epic/better than it actually is)
Add a custom footer
Add a custom sidebar
Clone this wiki locally