Koding Best Practices

Problems Koding something? Get help from other users here!
User avatar
Level 3
Level 3
Posts: 184

Koding Best Practices

Post#1 » Wed Aug 17, 2016 9:55 am

moved over from projectspark.com

People have recently been asking how Team Dakota goes about setting up its creations in Project Spark. When we work on games and creations, we have a lot of team members who can pitch in to it. It’s important they all follow the same processes. If you have a standard process (what is sometimes called a Standard Form), it makes it easier for each creator to follow along with and locate Kode they need.

What follows is our Koding Best Practices document each designer follows when working on a creation. This is a list of standard that has grown as our team has grown with each creation. It’s something we hope the community will find useful in how you set up your creations.

The goals of a Standard Form in Project Spark are to have consistent design methods, readable Kode and keep things clean.

General Practices:
Name Objects – So that Kode references are informative.
Name Pages – So that Kode references are informative.
Switch/Call Pages by Name - Do not use numbers or next page.
If a [when] statement has multiple [do] statements, put all of the [do] statements on separate child rules.
If a rule stretches off the screen to the right, move the [do] statement to a child rule, so that the logic can be read without scrolling horizontally.
Place Logic Cubes in the air above the scene unless they are a spawner/target/trigger.
Place Templates near the object that spawns them. – If multiple objects spawn the same template use your best judgment on where it should go. At the very least put it near the state manager for the area.
Never hide logic cubes or templates underground or out of sight.
NEVER use power as a way to tell a brain to run. Power should only be used for things with power states ( lights, VFX, and things with power on/ power off animations ).
Characters should be added to [ global ][ active players ], an actor list, this way we perform various actions across all of the current players (like disabling brains for cutscenes).

We use a lot of camera in our creations for cinematics and in-game mechanics. We use the Camera Gizmo to store all camera Kode. We also scale Camera Gizmos up to 250 – 400% so you can see them from a distance. We have two different categories for how we color Camera Gizmos in game to show what they are used for.
Purple: Cinematics Cameras
White: Gameplay Cameras (such as security camera style, tracking cameras, first-person cameras, etc)

Logic Cubes
We like to color our logic cubes based on their uses. That makes it easy to look around a world and find the logic cube types you’re searching for.
Red: Enemy spawners, arena logic
Orange: Gameplay target points (e.g. teleporter, look at, move towards; often scaled tiny to make more precise)
Green: Triggers (any scripted event that needs a trigger zone; only show trigger zones when needed))
Blue: State Manager (one per gameplay area; we make these larger to be easier to find)
White: Generic (when it doesn’t fit any other category, we use this color)

Rules of Thumb

Order your rules linearly. [Once] at the top. [On Page Enter] after that. Timers in order following. Conditions that change pages at the bottom.
Don't capitalize Variable names, Do capitalize Page and Object names.
Make Initialization pages for groups of variables and then call those page once on startup. For example enemies can have a page called Combat Variables Initialization that you call that sets their damage and health.
Keep objects a brain uses in an area nearby. Do not use hidden objects that teleport into a scene. Use templates that can be left invisible near the scene.

Blue State Managers
Only State Managers get to change their pages. No other object should tell a State Manager to change pages. Have a State Manager look at Booleans in other objects like triggers and cinematics to know what conditions are met to change states.
Keep page progression in State Managers linear. Create multiple inactive/hold/waiting pages if necessary.

In general, avoid direct object references. Object variables are almost always preferred in order to ensure levels can be broken up into discrete pieces and objects can be replaced with new versions easily. If you need direct object references, point to the object in world on an initialization page and set a variable to that object.

All cinematic sequences should have the prefix “Sequence” in its name. This way, when using the named object list, you can easily find the sequences. An example is naming a camera “Sequence Observatory Intro.”
Every cinematic sequence should be using the Camera Gizmo object and not a logic cube. Even if the sequence deals with other cameras or logic cubes.
Every cinematic should set a [ global ][ Hide HUD ] Boolean to true while it is playing and then false when it is over.
Every cinematic sequence should have two Boolean variables: “play” & “stop” both of which should be false from the very beginning. The State Manager sets the sequence’s “play” boolean to true to start the sequence and then waits for that sequence’s “stop” to become true before moving on. This means that there should not be any one off variables in the State Manager to play a sequences and wait for it to finish. The State Manger can use the in world picker and set that sequence's “play” to be true and then wait for its “stop” to become true before moving on.
Every cinematic should have 3 pages at the very least. Page names should be “Setup”, “Establishing Shot” and “End Cutscene” in that order. Any other pages/scenes can happen between "Establishing Shot" and "End Cutscene."
End of line.

Return to “Koding Konversations”

Who is online

Users browsing this forum: No registered users and 1 guest