Part 3: Structuring Projects with Namespaces, MVC and MVP

If you’ve been following along, you’ll notice our domain-based folder structure naturally supports another important practice we should be enforcing in all C# projects: proper namespaces.

A C# class’s namespace should always closely mirror its file path so that at a glance, we know what context, file and domain we’re in, but in our case we need to ignore Unity-specific quirks like Assets/ or Scripts/. Either way, if your structure is clear, you should be able to look at a namespace and immediately know where the file lives, and vice versa.

Example Structure
Assets/pixelfat/CandySmushSega/Scripts/Application
Assets/pixelfat/CandySmushSega/Scripts/UI
Assets/pixelfat/CandySmushSega/Scripts/Model
Assets/pixelfat/CandySmushSega/Scripts/Game
Matching namespaces
pixelfat.CandySmushSega.Application
pixelfat.CandySmushSega.UI
pixelfat.CandySmushSega.Model
pixelfat.CandySmushSega.Game

But Dan, you say, I’m making a game, not an app..

Well, that’s not strictly true. Your game is just one feature of the application that delivers it. If you keep that in mind, you can use namespaces to write naturally decoupled code with much less effort, which is a huge win for everyone. And as the lead, senior or architect, you can use these patterns to encourage others to write naturally decoupled code too. So, if we were to keep our game outside of our applications layers and instead have them consume the game, we can do whatever is best for our purpose and even switch out the game or reuse the application layers in other projects.


By keeping your layers and systems separate, it’s easy for any developer to recognise an overall MVC (or rather, MVP) pattern in the application and overall project structure with no confusion as to where things are or should be. All while allowing your game code to follow whatever pattern best suits it.

The Right Tool For Each Job

If we write our game-specific code in pixelfat/CandySmushSega/Game, then our namespace is naturally pixelfat.CandySmushSega.Game. The application that consumes it lives in pixelfat.CandySmushSega.Application. This means the application can create instances, invoke methods, and subscribe to events in the game, while the game has no knowledge of the application at all. It only needs the app to start it, pass in resources, and handle events.

Namespaces are practical guard rails. They guide your devs (and future you) into the right place to implement each feature. But they are also used to separate concerns, systems, data models and everything else. So, while you may steer away from MVC because you’ve been taught it’s an anti-game pattern, we can still use it for what it’s best at – organising our application code.


With domain-driven structures and namespaces in place, we can now apply MVC (or any other pattern you deem fit) where it fits best: in the application layer, while allowing our game devs the freedom to use any pattern they want in the game code. Personally, I like to stick with MVP for games as it’s very similar to the MVC pattern I use for applications, and works well with Unity scenes and component structure.

This way, game logic doesn’t bleed into UI or presentation, and namespaces provide the road markings that keep every developer in their lane. And by every developer, I mostly mean future me. Drink water before bed, write clear namespaces, future you will be grateful.

Don’t just take my word for it:
https://unity.com/resources/level-up-your-code-with-game-programming-patterns
https://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-differenc

So, we can now have something like this:

using pixelfat.CandySmushSega.Game;

namespace pixelfat.CandySmushSega.Application
{
    public class CandySmushSegaApp // controller/presenter
    {
        public CandySmushGameView GameView;    // view
        public CandySmushGame GameInstance;    // model
        public ICandySmushInput GameInput;     // input, specifically for the target platform

        public CandySmushSegaApp()
        {

            // Create a game instance
            GameInstance = new CandySmushV1();

            // Attach the input system
            GameInstance.SetInput(GameInput);

            // Subscribe to events the application cares about (game over, etc)
            GameInstance.OnEvent += HandleEvent;

            // Attach a Unity view component to present the game
            GameView = new GameObject("Game View").AddComponent<CandySmushGameView>();

            // View subscribes to state/events, does any setup it needs
            GameView.SetGame(GameInstance); 

        }

        private void HandleEvent(object sender, GameEvent e)
        {
            // Translate game events to app/UI actions
        }
    }
}

Note: There are many ways to create a game instance, hook up input, implement a presentation layer, and handle it through your application, the above is just one example. You may want to just instantiate a prefab ICandySmushGame GameInstance = Instantiate<ICandySmushGame>(prefab) and that’s it.. which is perfectly fine too!

Could we go further?

Sure, we could implement an interface IMatchThreeGame have our application use only that. We can write wrappers for many off-the-shelf match three solutions that implement it and have several completely different implementations of match three in our project. Then we can switch out the game code whenever we like, without affecting the application part at all.

Should we go further?

Not unless switching out the game is either a part of your agreed upon scope, or on the roadmap. Many senior or lead devs will push for the use of interfaces early, but there’s rarely any reason to do so unless it’s a part of the current requirement. So don’t be ashamed to dump your entire game in a prefab and just directly reference the class returned when you instantiate it. If that’s all the requirement calls for, that’s good architecture. Pedantry is not. Just make sure you can switch it up for an interface if it does become a requirement later.

What you shouldn’t do is end up with buckets like Game.Core or Application.Controller. Those names hide intent and erode boundaries. This mapping isn’t just about cleanliness – it enables better IDE navigation, refactoring, code reuse, and on-boarding. It also stops you from dumping everything into one giant Scripts folder and hoping for the best.

But try not to take everything I’m saying here verbatim, as an architect it’s up to you to figure out what the best tool is for the job, then figure out how to best use it – I’m just trying to give you a starting point and make it clear that you can use more than one paradigm in your project, without having to mix them, and well structured namespaces will allow you to keep it all separate.

Assets/pixelfat/CandySmushSega/Game/Model             <-- Game as a Peer
Assets/pixelfat/CandySmushSega/Application/Game/Model <-- Game inside Application (tightly coupled)
Assets/pixelfat/CandySmushSega/Model/Game             <-- Feature first, mixed app & game model
Assets/pixelfat/CandySmushSegaGame/Model              <-- Split root - CandySmushSegaGAME
Assets/pixelfat/CandySmushSega/Core/Game/Model        <-- Context-driven (ergh.. 'core')
Assets/pixelfat/CandySmushSega/MatchThree/Model       <-- Vertical Slice (my preference)

There’s loads of ways to do this, and none of them break the paradigm so use the one that makes sense to you, the project scope and your team.

I’ve used this approach for many years and it works beautifully with domain-based thinking – your game logic doesn’t even bleed into your UI or how you present that game to the user at all. Instead, you’re building clear architectural lanes, and namespaces give you the signs and road markings.

OK so where do I put my binary assets, Mr. Fancy Pants?

I want to be very clear that as with any software project, there’s no one solution that fits all. But if you use this way of separating concerns and using namespaces which reflect your directory structure, then you can do the same with assets!

For example, what if I wanted to keep my application and game assets completely separate? I tend to put all of my binary assets in a /Source folder, then I can split that further down into prefabs, materials, shaders and so on. But it’s all one project, so I risk mixing the game assets which should be structured clearly for our 3D artists to manage, with the application graphics which our graphic artists will want to manage. So I have a source folder in the game which has a complete set of all required assets, then another in my application layer containing the customized assets I want to use for this application of the game (see what I did there?).

Your game isn’t one thing, it’s a series of products, combined

Let’s consider off-the-shelf solutions, games we buy from the asset store and we want to use them to make some quick cash or meet a clients feature requirement. In any similar situation, we’d simply buy that asset, drop it into /Assets, reference it in our application, and start customizing the assets to match our design. So, why not follow that pattern and treat our game and application as two distinct products; one consuming the other, just as we described earlier…

Think of the game as a plugin your application consumes.:

  • The application owns state and orchestration. it contains the variations of the game resources needed for its version of the game.
  • The game just plugs in to be run, because it’s the App’s content. It contains a complete set of assets needed to use it.
Assets/pixelfat/CandySmushSega/Application/CandySmushSegaApp.cs <-- only required component in the scene, sets the current state
Assets/pixelfat/CandySmushSega/Application/Scripts/UI <-- UI instantiates and disposes of panel prefabs
Assets/pixelfat/CandySmushSega/Application/Scripts/UI/Panels <-- panels are components attached to prefabs in source/prefabs/UI/...
Assets/pixelfat/CandySmushSega/Application/Scripts/Model <-- data classes that need to be passed around or consumed

And our binary assets sit in our Source folder..

Assets/pixelfat/CandySmushSega/Application/Source/Prefabs/GameTheme/Space/Gems
Assets/pixelfat/CandySmushSega/Application/Source/Prefabs/GameTheme/Bugs/Gems
Assets/pixelfat/CandySmushSega/Application/Source/Prefabs/UI/Menus
Assets/pixelfat/CandySmushSega/Application/Source/Textures/Icons

And our game, now looks like this…

Assets/pixelfat/CandySmushSega/Game/CandySmushSegaGame.cs <-- the entry point of our game asset, maybe even a prefab we just instantiate
Assets/pixelfat/CandySmushSega/Game/Scripts/LevelComponent.cs <-- A component or base class for an implemented level
Assets/pixelfat/CandySmushSega/Game/Scripts/GemComponent.cs <-- A component or class, part of our games data model

Assets/pixelfat/CandySmushSega/Game/Source/Prefabs/Levels <-- Level prefabs with Level component attached and configured.
Assets/pixelfat/CandySmushSega/Game/Source/Prefabs/Gems

No One Rule

How you name or structure these directories really doesn’t matter, we can even choose to simply use /CandySmushSegaApp and /CandySmushSegaGame. But crucially your namespaces still line up with the directories, so traversing both the code and asset structure is a breeze, we can use the correct pattern for each system, and we can switch out code and assets without worrying about breaking something somewhere else.

However you choose to do it, thinking about your project this way makes it much easier to approach the problem of keeping your code and project structured, easy to traverse and ring-fenced.

And as for never using MVC in games or mixing paradigms… Well, we didn’t, did we? But we could if we wanted to…

I use Unity to make just as many applications and installations as I do games and every one of them is just a single feature or set of features that is being presented to the user, by my application layer. Whether it’s a WebGL face-filter, a combat/strategy game or an app for engineers to inspect vehicles on a production line. The same thinking has served me well with all of them, and no two are exactly the same.

Thanks for sticking around. 🙂

<< Part 2: Domain-Driven Directory Structures