Guide for new and aspiring DEVs

Post Reply
User avatar
Snowman
Posts: 370
Joined: Sat Oct 03, 2015 4:44 pm
Contact:

Guide for new and aspiring DEVs

Post by Snowman »

Afternoon all,

As mentioned at the community meeting, we are introducing significant changes to the mission developer role within the community.

Firstly, let me clarify a few points.

The mission developer role is NOT just about designing and building your own missions, it's about growing the community as a whole by also supporting others who wish to develop content for the community. It's about being approachable, helpful and knowledgable in providing this assistance to aspiring devs.

If you just want to make your own missions and not be expected to help others then that's fine. We do not wish to prevent anyone developing content.. just don't expect to receive the tag.

Ok, so let's get to it...

What is expected of a ZEUS Community Mission Developer
A member with the developer tag should be capable of:

[*]Uploading missions to test server upon the request of non tagged mission devs.

[*]Providing support to aspiring devs whom may not be familiar with various aspects of the Eden editor.

[*]Provide support to aspiring devs about the correct usage of basic essential scripts for a mission. E.G. init.sqf, description.ext

[*]Be mature enough to provide constructive criticism on suggested ideas posed to them by aspiring devs, in a manner that will guide them towards the type of gameplay we adhere to in zeus.

[*]Able to provide assistance in testing missions of aspiring devs on the test server.

Briefing standards and design checklist
We expect all new missions from developers to adhere to the following standards. Failure to comply with this will result in the removal of the tag.

[*]Developed your mission with the startup parameter “-showscripterrors” enabled with no addon dependencies (CBA).

[*]Followed the standardised briefing structure and have given ample information and intelligence covering all areas or have given particular reasoning as to why a critical piece of info is not available. (see Briefing Standard) - https://docs.google.com/document/d/1M4E ... sp=sharing

[*]Invested thought in and provided loadouts/equipment critical for the particular mission and subsequently actually tested their functionality (for every role).

[*]Ensure the mission has functional triggers/condition checks, as well as clearly defined (and documented in the briefing) Failure and Success conditions.

[*]Defined endings within the mission so the players know what result they achieved and the mission doesn’t have to be ended by staff.
[“End1,true,true”] call bis_fnc_endmission;
Or ["End1"] call BIS_fnc_endMissionServer;

[*]Defined settings for respawn and supplied respawn positions if required (Instant respawn is not allowed)

[*]If your mission is a mission that doesn’t use respawn, make sure that you have defined/ set up a spectator system for KIA players to follow the action.

[*]Have entered the necessary mission meta data such as a brief description of the mission to be shown in the lobby, Min/Max players, onLoad, game type, etc…

[*]Named your mission according to the grooming/naming standard (see naming convention)

[*]Entered your mission into the Zeus Missions Doc and supplied all the necessary meta data there.

[*]If your mission has mission critical assets ensure that this is highlighted in the slotting up screen so that the mission commander is aware before the briefing begins.

[*]If your mission contains assets such as “Rhino”, “Hawk”, “Eagle” etc. then please ensure you state what vehicle each asset uses.

[*]TFAR module/functionality enabled and fed the correct data.

[*]Used and configured (with correct parameters) the ACE 3 modules for features like the medical system, logistics, pointing, etc… (see necessary modules list)

[*]Made sure that your equipment distribution/loadouts are taking into account TFAR/ ACE/ RHS for special equipment needs like i.e. radios, bandages, etc...

[*]Make sure that your method of distributing loadouts will not cause locality issues (i.e. please use a kitscript)

[*]Specialist roles are fully tested and can perform their expected tasks (Doctors / Repair Crew etc).

Briefing Standard
(note this does not require all sections to be in your mission but you should have good reason not to mention their respective information points)

(BACKGROUND)
SITUATION
[*]Enemy Forces
[*]Friendly Forces

MISSION
[*]Tasks/ Winning Conditions
[*]Failure Conditions

EXECUTION

SERVICE & SUPPORT

(SIGNALS)

(SPECIAL NOTES)

(ADMINISTRATION)

Basic Design Checklist for Newcomers
Have you asked yourself these questions?

[*]On the lobby screen, are all assets/roles clearly identified?
[*]If there is a driver/gunner, what are they driving?
[*]If there is an engineer team are they to function as support or EOD?
[*]Are any roles essential to the completion of the mission?
[*]JIPs - Where will they spawn? Do they have a fast method to get to their team?
[*]Have you added custom/scripts functionality and ensured they work in a dedicated MP environment? Testing in SP/local MP is not sufficient. Consider the locality of commands such as CreateVehicle and use isServer etc.

Minimum Requirements for the Dev Tag

[*]Base line experience of 10+ missions (Across both servers - vanilla and addon - This could be just 1 mission for server 1 and 9 for server 2 or vice versa.)
[*]Missions must have been played at least twice on gamenights
*Amended* We appreciate it can take a while before a mission is played twice, so we are relaxing this to once (with no bugs / issues of course).
[*]Missions are expected to be maintained. If bugs or balance issues are reported via the feedback form it is expected that the mission will be updated to address those concerns.
[*]10+ missions that have been played once, all on V1 with bugs or feedback outstanding would not qualify an individual.
[*]Missions made must have sufficient documentation. (Correctly filled out briefings to the minimum expected content, slots in the lobby must be correctly labeled, mission critical assets must be highlighted in mission description or the slot.)
[*]Must be able to demonstrate competent use of the FTP server.
* Added * [*]On missions with no respawn an inclusion of at least one of the following: 1. Mission failure conditions, 2. Time limit (ideal max is around 90mins), 3. Wave respawn mechanic.[/color]

This last point is one raised and discussed with the current DEV team. It provides a means to curtail the overlong missions which causes dead or waiting to join players to leave rather than wait to the next mission. The three mechanisms can be woven into missions at your discretion as we believe there are enough creative ways to build these into missions without limiting a developers options or breaking immersion.

======================

Ok, so a lot to take in there.. but please appreciate this is designed to solve a few problems and reduce the anxiety and wasted time in loading incomplete or broken missions.

These lists were compiled by myself, technicians and mission developers from the community. If you have any questions or wish to discuss these changes, please find me in team speak or post your questions here.

StealthySnowman.
Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests