The official blog of Ragmjol Entertainment

Entity or not part 2

So after a lot of toying around I kind of got longer than I thought I would when I wrote my last blog post. I managed to reduce my moveComponent down to a few fields, an Awake function that just references the character controller attached to the gameObject that has a moveComponent and a OnPathComplete function that I pass to the Pathfinding as a delegate which simply saves the path to my component when path has been calculated.

namespace ContentLibrary
using UnityEngine;
using System.Collections;
using Pathfinding;
using System.Collections.Generic;

public class BasicMovableUnit : MonoBehaviour

    // List of target objects
    // Current target
    //public GameObject currentTarget;

    public bool Moving;
    public bool ReadyToMove;

    public CharacterController controller;
    public Path path;

    public float speed;

    ////The max distance from the AI to a waypoint for it to continue to the next waypoint
    public float nextWaypointDistance = 0.1f;
    public float lastWaypointDistance = 0.1f;

    ////Current waypoint (always start at index 0)
    public int currentWaypoint = 0;

    public void Awake()
        controller = gameObject.GetComponent();

    public void OnPathComplete(Path p)
        path = p;
        ReadyToMove = true;
Whenever I move a unit I put the moveComponent in a list that my movementManager keeps tabs on. The movementManager loops through the list every frame and moves the object like this.

namespace ContentLibrary
public static void MoveUnitTowardsGoal(BasicMovableUnit mover)
        // Check if the mover has a path, if it doesnt have a path and there are still targets left in its target array then calculate a new path. Otherwise add it to the clean up list and return
        if (mover.path == null)
            if (movers[mover].Count > 0)
                mover.ReadyToMove = false;
                GetPath(mover.gameObject, movers[mover][0]);
                mover.currentWaypoint = 0;
                mover.currentWaypoint = 0;

        /// If waypoint number exceeds number of waypoints in path then target is reached, check if there are more targets in the list and if not return. Also null the path to ensure it will be cleaned up by the logic above in the next frame
        else if (movers[mover].Count > 0 && mover.currentWaypoint >= mover.path.vectorPath.Count)
            if (movers[mover][0].GetComponent() != null)
                pointerManager.RemoveChaserFromDictionary(movers[mover][0].GetComponent(), mover);
            mover.path = null;

        if (!mover.ReadyToMove)
        //Calculate direction of unit
        Vector3 dir = (mover.path.vectorPath[mover.currentWaypoint] - mover.gameObject.transform.position).normalized;
        dir = dir * mover.speed * Time.fixedDeltaTime;

        mover.controller.SimpleMove(dir); // Unit moves here!

        //Check if close enough to the current waypoint, if we are, proceed to next waypoint.
        if ((mover.gameObject.transform.position - mover.path.vectorPath[mover.currentWaypoint]).sqrMagnitude < mover.nextWaypointDistance && mover.currentWaypoint < mover.path.vectorPath.Count - 1)
        else if ((mover.gameObject.transform.position - mover.path.vectorPath[mover.currentWaypoint]).sqrMagnitude < 0.5f && mover.currentWaypoint == mover.path.vectorPath.Count - 1)
I am not quite sure what exactly I have accomplished by this but at least there is a fair amount of separation between movement logic and component data now.

Now I have started looking at collisions and I am not sure how to proceed here. I would like to have a collisionManager that loops through all colliders and conduct actions based on what is colliding with what. This idea doesn't quite mix with how unity manages collisions by having OnCollisionEnter and similar methods in a script attached to the gameObject with the collider. I can't think of any convenient and reasonable way to separate data an logic in this case. I guess I will go with having the gameObjects call the collisionManager whenever something happens and let the collisionManager deal with it so that I at least have all the important logic gathered in one place. That however calls into question my effort to separate data and logic for movement, maybe it would have been saner to stick with having a A* seeker on each gameObject to do movement and just having the object call movementManager whenever a target is reached.

Gahhh in trying to avoid spaghetti code at all cost it seems like I am making things less comprehensible because I end up being inconsistent. There is a logic to having logic and data completely separated and there is a logic in Unitys entity system as well, not sure if there is any sense in mixing the two though.

Entity system or not

I have been reading a bit about the Ash entity system, especially these two articles by Richard Lord

First time I read it I didn't quite grook it completely but it stayed there in the back of my mind as a good idea and I have slowly gotten around to thinking it is something I really want to implement. Unfortunately it turned out to be another form of Nerd sniping for me. I am still working on pathfinding and mouse selection of units on the simple rts I am working on and I got to work trying to rewrite it into more of an entity way.

I am using Aron Granbergs pathfinding project and it is great and very easy to work with. The base examples given and all the youtube tutorials suggests one adds a seeker component to game units and use that for individual units to find paths to targets. That doesn't quite match the entity way of doing things so I dug around until I realized I can just call the static method ABPath.Construct() to get paths instead. I put this into a unit manager class (which could be thought about as my movement system) and it works splendidly to create and assign paths to units.

The next step was to take out the movement logic from the gameobjects and put it into the unitmanager. Here I hit an obstacle, I really don't care for writing all the movement logic myself so I want to use as much as possible what is built into unity. That means using the Character Controller and preferably the simplemove method of the controller. But here the breakdown between system and data begins, there is no way to extract the character controller from the gameobject so either I have to write my own movement code or simply accept a "half entity" way of doing things.

Right now I am contemplating what I will do, but I will probably not fight with the Unity way to much. Going against the thought and idea behind the engine would probably in the long run involve as much work as simply making an engine out of an existing framework like Mono instead. The productivity gain from using Unity would be lost. I think I will take it as far as is simple to do and then accept that I wont get all the way. I can put all game logic I write into system like classes and accept that the entities will have some logic on their own that mostly consists of things that is included in Unity. One can probably see it as going halfway through Lords "What is an entity system" article and be satisfied with that.

Unity love stories

My love relationship with Unity just goes on and on. I am really enthusiastic about the new licensing terms for Unity 5, especially to have access to the profiler. The tools are fantastic and the amount of free tutorials both in text and video form is remarkable, not to mention the amount of add-ons developed by the community.

It just amazes me that I can follow along with a series of free tutorials like the RTS tutorials by http://www.unitychatchannel.com/http://www.unitychatchannel.com/ and within a few hours have a working prototype of an RTS running. Being a game maker has never been easier. The drawback with that of course is that instead of hundreds of game makers in the world there are now millions, but then again if the tools didn't exist it is doubtful I would be able to create something decent on my free time anyway.

The last few weeks I have been in a bit of a slow period, I started working on a puzzle kind of game based on electromagnetic particles. The idea was to have a game where everything is controlled by one button (or one touch) that changes the polarity of the player particle and with that one gets pulled or repelled to other particles. The idea is neat and I think it can be made to be fun, but these kind of causal games just doesn't resonate with me and I have trouble keeping motivation when working on it. I never play things like angry birds or flappy bird myself, it just doesn't interest me much. What interest me are detailed and huge RPG's, clever strategy games and the likes.

The problem of course is that it is pretty much close to impossible to create a huge RPG on my own with a normal full time job taking up the majority of the day. Just making one question in a RPG could take months. So what is the solution? Hang up my amateur game dev hat and start knitting instead? Not quite, I have come to the realization that I should work on something that resonates with me, which implies larger gameplay than just a puzzler, but content creation is way to time consuming so much of it must be procedural and gameplay challenges must come from game mechanics rather than scripted events and story. That rules out most of RPGs but strategy and open world type games are doable. In strategy one can "easily" have procedural generation of levels and the challenge is derived from beating an opponent via the game mechanics.

So what I have started working on now is kind of a Dungeon Keeper in space type of game, perhaps combined with a bit of strategic overlay. Think XCOMs split between strategic and tactical game elements. I am aiming for the same type of indirect control over units, I am going to make procedural generation of levels and I hope I can make something I find fun to play by myself. I have no clue how I will sort out assets, maybe the unity asset store will save me. The big challenge will be AI for units, it is especially important when units are indirectly controlled. Time will tell if I can manage it but at least my tendency to dig into to much depth will at least be constrained to unit behavior within a strategy context. Right now I am just building up the basic mechanics like selecting units, click and drag and so on.

Book review: Microsoft Visual C# 2012 Step By Step

I spent last week working my way through Microsoft Visual C# 2012 Step By Step by John Sharp. I spent Christmas in Czech republic at my girlfriends parents place, they don't speak English at all so that leaves me with plenty of time to kill, no wifi in the apartment either so I got no excuse other than to dig down in some book I want to get through. I have dabbled with C# now for something like a year, first through Monogame and now with Unity. My previous experience with Java made it possible for me to jump straight into C# without much fuss but I have all the time been meaning to go through a solid book to really learn the foundations of the language. Now I finally got the time and I picked the perfect book.

I am not sure I would recommend the book for someone with no previous experience with an object oriented language, but if you know a bit of Java or something similar then it should be a breeze. Many of the chapters can be skipped if you have previous experience and new stuff is presented in a succinct manner. The book never loses the point, never gets to verbose and I never failed to understand an explanation. That is the highest grade I can think of giving a technical book like this. It is excellent in all respects, I could even follow and test out concepts without having access to the book source code (no wifi remember) and the lack of the prepared files never bothered me.

I wish I had gone through this book a year ago, just like I wished I had gone through Sams "Teach yourself java in 21 days" before I made my first android app (I don't even dare looking at the source code now...). The clear explanation of what makes reference and value types different and heap and stack memory is by itself worth the book (in case one is like me and is a bit fussy on the topic).

All in all this book does the job in an excellent manner, it lacks nothing that I can think of and after going through it I feel I understand what I am doing a lot better. It is a solid 5 stars out of 5!

Book review: Nine Algorithms That Changed the Future:

Yesterday evening I started reading Nine Algorithms That Changed the Future written by John MacCormic. For someone with a computer science degree I guess the book probably doesn't contain anything new (just like a pop sci book about quantum mechanics probably doesn't give much to a physicist), but for everyone else it is a true gem. 

Compression, encryption and other methods that underlie everything in the computer world has always been total black boxes for me, sometimes I have read some half ass explanation that didn't make much sense to me and I never dug further. MacCormic on the other hand explains it all with a clarity I have never encountered before, suddenly all those things are utterly understandable. I would even stretch it far enough to say that anyone with some programming habit could implement some basic version of the algorithms after reading the book even though the book doesn't contain a single line of code, that is in my opinion the hallmark of clear explanations!

I take my hat of for this excellent book, it gets 5 stars all the way through!

Nerd sniping hits again

I once again got hit by a self inflicted nerd sniping. In the game I am working on there will be a fuzzy border kind of section where particles are supposed to bounce, instead of just having a slow gradient of a color I wanted to make something prettier and turned my eyes on fractals. Result of that is that I have now spent about 1 week on trying to make some clever Mandelbrot and Julia set zoom. It is rather a waste of time since there are already so many excellent apps that can do that on all platforms, but no app has as far as I seen captured the feeling of diving down in Mandelbrot space like all the excellent youtube videos show (probably because the computational resources needed to do that to any magnification in real time exceed what phones and pads can handle).

Naively though I don't see why its not possible. Each point is iterated separately from all others, so if for each magnification one only iterates on what is currently visible then the only limitation should be the floating point precision used (which is unfortunately limited to float32 in Cg shaders as far as I know) and diving deeper should not be harder than rendering the original view. But I am sure there is something I don't understand.

Unity 1.5 weeks in

I have been fooling around with Unity now for a few hours here and there for about 1.5 weeks and I got to say I like it a lot so far. I bought "Pro Unity Game Development with C#" and I find it a very good introduction to Unity (even though the author specify one should have some Unity experience before jumping into the book).

It feels kind of weird not to have complete control of everything through source code, using the Unity editor instead of doing everything in source feels like letting go of control. Letting go of control a bit is the whole idea though so no problem there. I am amazed by how quickly one can prototype things in Unity. Yesterday I got an idea for a twitch based kind of game and within 3 hours I got a working prototype running with some simple assets bought in the Unity store and together with the built in physics engine. It is rather remarkable, doing the same from scratch in Monogame or LibGDX would likely have taken me days. The asset store in particular is brilliant and will save me countless days and weeks of work.

I have a persistent itch to start doing my own lower level stuff though but like I wrote earlier, it is just too time consuming for a single developer to do everything and I want to create games much more than I want to create physics engines. Productivity when using ready made stuff is just incomparably higher. If my itch to do lower level stuff becomes overwhelming I guess I should rather take a look at contributing to some interesting open source project.

Anyway I am really stoked for Unity so far and I see very few drawbacks, amazing product!

Book review day

I am an avid reader and I thought I might as well throw up some book reviews here along with the game making stuff.

Right now I am in the middle of The Dark Defiles it is the third part of the series "A land fit for heroes". I have read one or two of Richard K Morgans sci-fi books and they always felt like run of the mill standard sci-fi, entertaining but nothing to write home about. His fantasy is right up there with the best though. If I had to compare it to anything it is quite similar to Joe Abercrombie and that is almost the best praise I can give any book. Morgan and Abercrombie writes dark and gritty fantasy that is as rough and brutal as G.R.R Martin but much more concise and with more elements of magic. I like Martins bible thickness books but sometimes it is also nice with books that are only 300 pages and keep a break neck pace all the way through. The big difference between Morgan and Abercrombie is that Morgan feels more "serious". Abercrombie has a fantastic sense of dark humor and his books belong to the few that can make me burst out in laughter. Morgan doesn't have that kind of humor but that doesn't diminish the quality of the writing one bit.

It seems like Morgan instead wants to shock people so he decided to make the main hero gay and wrote in a lot of explicit sex scenes, but if one doesn't get bothered by that the rest is top notch.

This book hits all the fantasy sweat spots, excellent world building, great characters and great story. Might be my favorite book this year right up there with Butchers latest Dresden book and Abercrombies Red Country.

The life of a hobbyist

I started this blog, wrote one post and them promptly stopped writing. As always ambitions are larger than what one can honestly achieve, especially when all of this is a hobby on the side of a full time job. The biggest thing though is that my life has turned upside down. I got offered a very interesting job in another city and the last months have been all about preparing to move, finding a new place to live etc. Coding has unfortunately not been on the top of the priority list.

A few weeks away from it all does give some perspective though. I love details, really love them. This xkcd strip summarizes me perfectly. Dangle an interesting problem in front of me and I drop everything and jump on it. That is not necessarily a bad idea but as a one man developer it is a constant obstacle. Game development encompasses a crazy width of interesting topics, any single one deep enough to consume entire careers. The life cycle of my projects are usually something like:

Get Started -> get some rough test running -> fall down into detail trap -> bang head in frustration

Step 3 takes pretty much all of my time, as for the project I am working on now step 3 was first writing a collision engine and then it warped into writing a multiplayer client. I spent ridiculous amounts of time reading up on both topics and messing around with coding but I still have zero to show for it and I doubt I will anytime soon and I am getting no closer to finishing my game. Its time to break up this cycle. The main problem for me is that working with a framework like Monogame or LibGDX means I have to write a lot of things like collision detection myself or mess around with some side engine. It worked well with LibGXD + Box2D for my first small project but the temptation to start messing with the details myself are always there. It's time to drop the pretense of wanting to create most aspects myself and instead give a full fledged engine a try, I enjoy c# way more than any other language (except python) so the natural choice is Unity. So now its time to dive into unity land and see what will come out of that! Hope I will have some time to mess around with it the coming 2-3 months and that the move and new job wont be to crazy.

How to use a custom type reader/writer in Monogame

I recently went out on a nightmarish search of the dark corners of the web in my attempt to understand how the he** one uses custom content with the content pipeline used by XNA and make it work in Monogame. I had to read through a lot of different tutorials to get a grasp of it and the one that saved me in the end is this excellent post on the Software 7 blog. The tutorial is in the form of a video though and I have always been more fond of written tutorials so I am gonna take a stab at explaining how I solved the problem. The main complication is that I use XNA to process content and Monogame for the rest, if you use XNA for everything you don't need to read this post.

If you are completely unfamiliar with the XNA content pipeline (in the sense that you dont even know what it is) I suggest you google a bit on it first.

A strong disclaimer is that I am a complete noob when it comes to everything written here, I haven't used visual studio much, I am no c# wizard and I am just dipping my toes in Monogame and I am not even a experienced programmer in general. There is likely to be some smoother way to make all of this work but maybe this will help someone anyway,

What you will need to follow these steps are:

What we want to accomplish in this tutorial is to extend the XNA content pipeline model processor, add a custom object to the model tag and import it all in Monogame and read the tag there. To tell the content pipeline how to compile the custom object it needs a typewriter and Monogame needs a typereader to know how to retrieve the data from the compiled object. We will create a custom class, extend the built in ModelProcessor and finally create a content type writer and a content type reader.

So lets begin with creating two projects. First start Visual Studio express 2013 (I am using Visual Studio Pro in case you wonder why there is some slight difference in look) and create a monogame phone project (I apologize for the small images, I am new to blogengine.NET and haven't figured out how to make clickable images, below each image there is a link to the full picture).

You can all the project whatever you want, I will call it TestExtendedModelProcessor.

In the newly created project right click on the solution, select add and then new project. Select Class Library as project under the store apps menu and name this project ContentLibrary, the naming is important for a reason that will become clear later.

VS2013library.png (183.9KB)

Now expand the view of the project and right click on references and add reference. Select your MonoGame.Framework.dll (likely under C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows8\ if you installed like normally).

Now you have the projects you need in VS2013, we wont do anything there right now and instead turn our eyes to XNA. So start up Visual Studio Express 2012 for Windows Phone and create a new empty content project. I call it "TestContent".

Right click on the solution and once again add a new project, this time a Windows Phone Game Library project. The name of this library has to be the same as the name of the library we added to our VS2013 project (in this case ContentLibrary). 

VS2012LibraryProject.png (223.3KB)

Then right click solution again and add a final project, this time a Content Pipeline Extension Library, I call it TestPipelineExtension.

VS2012PipelineProject.png (194.4KB)

We will start our work in the content library project. Below I will add a bunch of code snippets, for some reason the syntax highlighter is not completely reliable so I will also add the source code file below each snippet.

So lets start, first delete the file "Class1.cs" that is automatically created. Then:

  • right click the ContentLibrary project
  • select add new item
  • then go to code and select class
  • Add the class and lets call the class CustomData. 
  • Open up the file, change it to a struct and add a vector 3 and a string to it like so:
namespace ContentLibrary
    public struct CustomData
        private Vector3 vert;
        private string myString;

        public Vector3 Vert
            get { return vert; }
            set { vert = value; }

        public string MyString
            get { return myString; }
            set { myString = value; }

        public CustomData(Vector3 vert, string myString)
            this.vert = vert;
            this.myString = myString;

Now we want to tell the content pipeline how to process a file like this, first we need to add a reference to the ContentLibrary from the pipeline extension:

  • Right click on the pipeline extension references
  • Select add reference
  • Select Solution and then Projects
  • Mark ContentLibrary and click OK
Now we need to create a typewriter so the content pipeline knows how to process the CustomData. So do the following:

  • right click on the pipeline extension project
  • select add new item
  • go to XNA Game Studio 4.0 and select content type writer
  • Add it  call this class CustomDataTypeWriter. 
Below is the code for the typewriter.
namespace TestPipelineExtension
    /// <summary>
    /// This class will be instantiated by the XNA Framework Content Pipeline
    /// to write the specified data type into binary .xnb format.
    /// This should be part of a Content Pipeline Extension Library project.
    /// </summary>
    public class CustomDataTypeWriter : ContentTypeWriter<CustomData>
        protected override void Write(ContentWriter output, CustomData value)

        public override string GetRuntimeReader(TargetPlatform targetPlatform)
            return typeof(CustomDataTypeReader).AssemblyQualifiedName;

The override Write method tells the content processor what kind of objects your custom object contains and the content pipeline already knows how to handle those standard classes (in this case Vector3 and string). The GetRuntimeReader gives the information on what typereader it will use to decode the object. Now we need to create the reader, make sure you name it the same as what you specify in the GetRunTimeReader method. 

We will add the type reader to the content library project:

  • Right click on ContentLibrary project
  • Add -> new item
  • Select Content Type Reader under the XNA Game Studio 4.0 menu, name it CustomDataTypeReader
Below is the code for the CustomDataTypeReader

namespace ContentLibrary
    /// <summary>
    /// This class will be instantiated by the XNA Framework Content
    /// Pipeline to read the specified data type from binary .xnb format.
    /// Unlike the other Content Pipeline support classes, this should
    /// be a part of your main game project, and not the Content Pipeline
    /// Extension Library project.
    /// </summary>
    public class CustomDataTypeReader : ContentTypeReader<CustomData>
        protected override CustomData Read(ContentReader input, CustomData existingInstance)
            Vector3 vert = input.ReadObject<Vector3>();
            string myString = input.ReadObject<string>();
            CustomData customData = new CustomData(vert, myString);
            return customData;

The reader simply specify what objects you will find in the compiled file and then uses those objects to create a new CustomData object which it returns. Add it and build the project.

Now its time to extend the model processor so we can add our custom object to the model tag:
  • Right click on the pipeline extension project
  • Select add new item
  • Under XNA Game Studio 4.0 select Content Processor, I name it CustomModelProcessor
Below is the source code for CustomModelProcessor.

namespace TestPipelineExtension
    public class CustomModelProcessor : ModelProcessor
        public override ModelContent Process(NodeContent input, ContentProcessorContext context)
            ModelContent usualModel = base.Process(input, context);
            CustomData data = new CustomData(Vector3.Zero,"Hello world");
            usualModel.Tag = data;
            return usualModel;
This is super simple, we extend the normal modelprocessor, use its Process method to give is a ModelContent object. We then create a CustomData object where we just insert a dummy Vector3 and the string "hello World". We add the CustomData to the Model tag and then we return the model.
Now we need an acctual model to play with so lets add one. You can use this simple box and add it and its texture to the TestContentContent project. Then build the project.

hr.fbx (88.7KB)
hrtexture.png (917.1KB)

  • Right click on TestContentContent
  • Add existing item
  • select the hr.fbx
In the TestContentContent you need to add a reference to your content pipeline project so do that
  • Right click on TestContentContent
  • Add reference
  • Solution -> Projects
  • Select TestPipelineExtension (or whatever you named the pipeline extension project)
If the reference shows a yellow triangle you need to retarget your pipeline extension project:
  • Right click on content pipeline project
  • Select properties
  • Select Target Framework as .NET Framework 4
  • build project
Now you can use your custom processor on the model:
  • In TestContentContent left click on hr.fbx
  • On Content Processor select CustomModelProcessor
Now you are ready to process the model. Just hit F7 to do so.

Now we need to turn back to the monogame project. First copy over the compiled file. You will find the compiled file under
"TestContent\TestContent\TestContent\bin\Windows Phone\Debug\Content"
Copy all of those files to your vs2013 project and its content folder

Now open the vs2013 project

  • Click on the "show all files" button on the top of the solution explorer, then expand the content folder.
  • Mark the grayed out xnb files 
  • Right click and select "include in project"
  • In the properties window select build action content
  • In the properties window select Copy To Output Directory Copy if Newer
Now the magic happens, you need to copy over the typereader and customdata:

  • Select your ContentLibrary (the one in the monogame project)
  • Right click and add -> existing item
  • Browse to your xna projects ContentLibrary project
  • Mark both CustomData.cs and CustomDataTypeReader.cs and click add
  • build the monogame projects ContentLibrary (if everything is named correctly this should work without a hitch)
Now you need to add a reference to the ContentLibrary in your monogame project (which in my case is named TestExtendedModelProcessor).

  • Right click TestExtendedModelProcessor
  • Add reference
  • Solution -> Content Library
If visual studio refuses to add reference you need to change build target of the ContentLibrary:
  • Right click on ContentLibrary
  • Select properties
  • Under library check "Targeting", one of the targets there should be the same as what is written within parenthesis behind the TestExtendedModelProcessor project, if not click change and add the correct target.
  • Rebuild and try to add as a reference again
Now open the game1.cs file under TestExtendedModelProcessor and modify the LoadContent() method to this:

             protected override void LoadContent()
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);
            Model testModel = Content.Load<Model>("hr");
            CustomData customData = (CustomData)testModel.Tag;

            // TODO: use this.Content to load your game content here

Here we don't do anything fancy, we just load the model. Then we cast the model tag to a CustomData object and finally we read the string we saved in that CustomData object. It is just a quick check to make sure all the importing and exporting worked as it should.

So there you have it, a complete way of getting custom content pipeline stuff from XNA game studio 4.0 over to Monogame. Like I said I sure hope there is an easier way to accomplish this but I am not familiar with it.

Someone might ask why I simply don't reference the ContentLibrary project under the XNA content project instead of creating a duplicate ContentLibrary in the Monogame project. The reason is that one gets some kind of dependency issues because the Monogame ContentLibrary project of course reference Monogame classes while the XNA Content Library project references XNA classes. They might have the same names (the Monogame classes are even in a namespace called XNA) but the compiler seems to get that they don't refer to the same anyway, I am sure a more experience programmer than me can explain it. 

Keeping two identical class libraries is a bit of a pain in the ass because one needs to copy files every time you change something, but it is the only way I have found so far to make all of this work.

No part of this post would have been possible without the Software 7 blog or the content extension chapters in the book XNA 3.0 Game Programming Recipies, I highly recommend both.