NinjaScript for Traders: How a Basic NinjaTrader Strategy Is Built

Most first NinjaScript strategies break on bookkeeping, not on the trading idea. An entry fires twice, a stop never gets attached, or the logic evaluates a bar that hasn't closed yet. Knowing how a script is organized lets you spot those problems before real money is involved.

What NinjaScript can build

NinjaScript is NinjaTrader's C# based framework, and it produces three kinds of objects. Indicators calculate and plot values on a chart, such as a custom moving average or a session volume line. Strategies submit orders based on conditions you define. Add-ons extend the platform itself with new windows or tools. For most futures traders the useful pair is indicators and strategies, and this article sticks to strategies.

Start with the Strategy Builder

In NinjaTrader 8, open the Control Center and choose New, then Strategy Builder. You pick conditions (for example, a fast average crossing above a slow one) and actions (enter long, exit, set a stop). For simple rules the builder can generate the underlying code, and you can unlock that code in the NinjaScript Editor afterward. Reading what the builder wrote is a quick way to see how NinjaTrader expects entries, exits and stops to be arranged. The builder has limits, so expect to move into the editor once your rules need custom state or multiple data series.

How a strategy file is organized

Every strategy is a C# class that inherits from the Strategy base class. Four areas matter.

• Variables and properties hold indicator references, counters and user inputs shown in the strategy dialog.
• OnStateChange() runs as the script moves through its life cycle. Defaults such as Name, Calculate and EntriesPerDirection go in the SetDefaults state. Stops and targets that apply to every trade are normally set in the Configure state. Indicator objects get created in DataLoaded.
• OnBarUpdate() holds your entry and exit logic. It fires when a bar closes or when a tick arrives, depending on the Calculate setting.
• Order event handlers such as OnOrderUpdate and OnExecutionUpdate are for tracking fills when you need that detail.

The Calculate setting is the one new authors overlook. With OnBarClose, your logic sees only completed bars, which is easier to reason about and to test. With OnEachTick or OnPriceChange, the same code runs repeatedly inside a forming bar, so a condition can flicker true and false and submit orders you didn't expect. Choose OnBarClose until you have a reason not to.

The syntax you'll use most

Close[0] is the current bar's close and Close[1] is the previous bar's. High[0] and Low[1] work the same way. Indicators are called like functions, so SMA(20)[0] returns the current 20 period average. Before reading Close[20] or SMA(20)[0], guard with a check on CurrentBar, otherwise the script throws errors while the chart is still loading history.

Position.MarketPosition tells you whether you are flat, long or short. Test it before every entry so the script doesn't stack positions. EnterLong() and EnterShort() submit market orders, EnterLongLimit() places a limit entry, and ExitLong() closes a long. SetStopLoss() and SetProfitTarget() attach protective orders to entries.

An illustrative example

The rule set below is a teaching sketch, not a tested or validated strategy. Go long when the close falls more than two standard deviations below a 20 bar average while flat, and exit when price returns to the average. Attach a fixed stop of 40 ticks.

protected override void OnStateChange()
{
    if (State == State.SetDefaults)
    {
        Name = "DeviationRevert";
        Calculate = Calculate.OnBarClose;
        EntriesPerDirection = 1;
    }
    else if (State == State.Configure)
    {
        SetStopLoss(CalculationMode.Ticks, 40);
    }
}

protected override void OnBarUpdate()
{
    if (CurrentBar < 20) return;

    if (Position.MarketPosition == MarketPosition.Flat
        && Close[0] < SMA(20)[0] - 2 * StdDev(20)[0])
        EnterLong();
    else if (Position.MarketPosition == MarketPosition.Long
        && Close[0] >= SMA(20)[0])
        ExitLong();
}

Check the stop in dollars before running it anywhere. On ES, 40 ticks is 10 points, and at $12.50 per tick that is $500 per contract before slippage. On MES the same stop is $50 per contract. A stop order can fill beyond its price in a fast market, so treat $500 as the planned loss, not the ceiling. Also note the logic has no time filter, no session handling and no protection against a market that keeps trending away from the average. Those are the failure modes you would add rules for after reviewing results.

Compile, then test in SIM

Open New, then NinjaScript Editor, edit the file, and compile with F5 or the Compile button. Typical errors are a missing semicolon, an undeclared variable, or a method called with the wrong arguments. A clean compile only proves the syntax is valid, not that the logic is sound.

Next, apply the strategy to a chart or the Strategies tab, select a simulation account in the Account field, and watch real orders appear in the Orders and Executions tabs. Check three things: did every entry get a stop, did an exit ever fire while flat, and did any signal repeat on the same bar. Then review the Trade Performance report for the SIM account. SIM fills are simulated, so they say nothing reliable about queue position, slippage or how you would behave with real money at risk. Fifty SIM trades are a debugging aid, not live proof.

Where to look things up

The official NinjaTrader 8 help guide at ninjatrader.com/support/helpguides/nt8 documents every method and property with examples, and it is the authority when anything here differs from your installed version. The NinjaTrader support forum is useful for specific error messages. If you want to see how a fixed set of reference prices turns into rules a bot can follow, the KPL bot specs describe the published behavior without you having to guess at the logic.