Learn NinjaScript: Planning the Better Moving Average (BMA Part 2)

In the last post, we kicked things off with the big idea: build a better moving average indicator—one that adapts to your logic, reflects it visually on the chart, and gives you full control over how it behaves.

But before we start writing code, we need a blueprint.

Rushing into NinjaScript without a plan is one of the fastest ways to create something messy, hard to maintain, or worse—totally unusable. That’s why this post is dedicated to laying out exactly what we want this indicator to do, what settings we’ll need to expose to the user, and how we’ll organize everything to keep the code clean and scalable.

And since we’re building this live, you’ll get to see that thought process in action. If we run into design limitations later, we’ll talk about how to fix them. That’s part of what this series is all about: not just the finished product, but the real steps it takes to build something useful from scratch.

Let’s break it down and design this thing the right way.

🔍 Why Planning Matters

It’s easy to think, “I’ll just start coding and figure it out as I go.” And sure—you can do that. But if you don’t define the structure up front, you’ll constantly find yourself hacking things together, rewriting logic, or trying to force visuals into code that wasn’t built to support them.

This is especially true for indicators that are meant to be flexible and customizable—like the one we’re building.

We want this script to:

• Support multiple logic styles (not just one hardcoded condition)
• Let users choose how trend is defined and how it’s displayed
• Be cleanly organized so that visuals (plot, bars, background) are decoupled from logic
• Be easy to extend later if we want to add alerts, smoothing, confirmation filters, or additional behavior

That’s what we’re planning today. By defining the inputs, logic options, and visual structure before we write a single if statement, we’ll save ourselves time and make this indicator something that’s actually worth keeping in your toolkit.

Let’s start with the moving average core inputs.

📘 Moving Average Inputs

At the heart of this indicator is a moving average. But instead of locking the user into one type (like an SMA or EMA), we want to let them choose which built-in NinjaTrader moving average they want to use—and how it behaves.

That means we need two core inputs:

But there’s a catch: not all moving averages support all periods.
For example, using a period of 1 for HMA might break or return strange results. So we’ll either:

• Add validation inside the code when the user selects a period, or
• Limit period options dynamically based on the MA type (if you really want to go advanced later)

In our code, we’ll likely use a switch statement to map the user’s selection to the correct built-in NinjaTrader indicator. We’ll also need to store a reference to the selected MA’s values so we can analyze them for trend logic later.

This is the foundation everything else will build on—so keeping it flexible and stable matters.

Next, let’s figure out how we’ll define trend.

🧠 Trend Logic Style

Now that we know what kind of moving average the user can select, we need to define how we’ll interpret the trend based on that line.

We don’t want to hard-code just one method—every trader thinks about trend differently. Some look for slope, others care about crossovers, and some just want to know if the price is above or below the line.

So instead of forcing a single logic style, we’ll give users control through a dropdown-style enum called TrendStyle. This will let them choose from several common ways to define trend:

🧭 TrendStyle options:

This one input will completely change the logic we use later on in OnBarUpdate(). So our plan is to structure the code using a switch block to route the behavior based on this setting. Each logic condition will feed into its own internal signal (likely a Series<int>) that other parts of the script (like visuals or alerts) can tap into.

By isolating this logic, we keep our visuals fully decoupled—no messy if statements cluttering up our brush assignments.

Next, let’s look at how we’ll handle visuals while a trend is active.

🎨 Visuals — Trend State

Once we’ve detected a trend, we need to decide what the chart should actually do with that information. This is where visuals come in—and where we give the user full control over how trend conditions are displayed.

This section covers the visual feedback that happens while a trend is ongoing (not when it changes). Think of it as: “the market is trending right now—how do I want to see that?”

Here’s what we’re going to support:

🟥 Color Bars

We’ll use BarBrushes[] to apply color to price bars in OnBarUpdate() when the corresponding trend condition is true.

🖼️ Color Background

We’ll use BackBrushes[] here for chart-wide visual context. Some traders love this for context; others will turn it off.

All of these will be controlled independently. If the user just wants background shading and bar color? Totally fine. We’ll make sure they have that option later in the logic.-

Next, we’ll focus on what happens when the trend flips.

🔄 Visuals — Trend Change

Unlike the visuals we apply during a trend, this section is all about the moment when direction flips—from rising to falling, falling to rising, or into a neutral zone if that’s supported.

These events are often more actionable, and they tend to be where traders want a little extra attention—color flashes, arrows, or even audio alerts.

Here’s what we’ll support when a trend changes:

🟥 Color Bars and Background on Flip

We’ll allow different visuals to be triggered just once when a new direction is detected. The idea is to emphasize the change, not maintain the visual throughout the entire trend. We will use similar inputs as above.

➡️ Draw Arrow on Change

This gives the user a consistent, clean visual that marks the exact bar where the transition occurred.

🔔 Alert on Trend Flip

Alerts will only fire once per change, and we’ll build in tracking to prevent duplicate firings on the same direction.

🧱 Structuring the UI with Display Groups

We’ve planned a lot of inputs—and if we just dump them into the NinjaTrader settings panel, it’ll be overwhelming. To keep things clean and user-friendly, we’ll organize everything using [Display(GroupName = "...")].

Each major section will have its own group so that related options stay visually bundled together.

Here’s how we’ll group them:

This structure keeps the user experience smooth and helps us manage the code more easily as we add new features. Each group will be implemented in order, and we’ll use consistent [Order = X] attributes within each section to keep everything intuitive.

📋 Planning Recap

Before we jump into building the indicator, here’s a quick recap of everything we just defined:

This plan gives us a solid foundation that’s flexible, easy to debug, and simple to expand. Every input, logic block, and visual option has a purpose—and we’ll start wiring them up in the next post.

🎉 Prop Trading Discounts

💥89% off at Bulenox.com with the code MDT89