Intimidation_screenshot

Morgemil Part 2 – A Technicality

About five years ago I almost made a video game. I say “almost” because I got bogged down in constant rewriting while searching for perfection so that project lost momentum and was never finished. Not to mention that I hardly knew anything, as this was the summer before I started college. A bit of digging in the history banks turned up the old Google site created for it. https://sites.google.com/site/intimidationgameproject/

I remember learning a lot during that project: Python, Panda3D, a ton of search algorithms, and a little linear algebra. All of that knowledge served me well as a springboard to further concepts. Just as importantly, it helped reinforce some concepts of software development I was taught later: the language doesn’t matter, results matter, and to focus on working software as the perfect code will never be reached, no matter the iteration count.

Having said all that, I have a different unit of measure for this project than perfect code. Don’t misunderstand me now, the better the code, the less long-term technical debt. So I won’t be making hasty calls of “I’ll fix that later” without good reason since new code builds upon existing code regardless of correctness. I just won’t be iterating as much without perceived value from doing so.

To keep me on track and progressing, I’ve committed to updating this blog once a week on average. Furthering backing any future claims of progress will be my https://github.com/DanielOliver where I will be publishing all source code under an MIT license.

I feel that I should mention that my new project’s name “Morgemil” and explain why I chose that. I have a story sketched up as an optional feature planned and that is the name of a central character. Another reason is that it is one of my preferred game account aliases (not much of an alias if I give it away). Perhaps a more practical reason, is that I already have http://morgemil.com which will just point to the github page for now as there is no media to show off yet.


Now back to the topic as defined by the title: The technical details. I will be writing the core game engine from scratch. I have not found a library that meets all my requirements satisfactorily. Re-inventing the wheel is often a bad decision, but I will be gaining some value here: I will know exactly what that code does and why, I will have more comprehensive test coverage, and I will learn more.

As for what languages and tools I will be using: the core game logic will be in F#, the graphics will be in C# with any of the game engines used purely for visuals, Visual Studio because it is amazing, and possibly the Mono Project for some Linux support. I do not know the testing framework yet, that is another thing I will need to research and learn about.

C++ is the traditional game development language purely for the reason that so much optimization is necessary to run in real-time. Morgemil will not have that problem, being a turn-based game (first hint). So I don’t believe that .NET will affect game performance. More important is developer time (my time) spent. My time is important to me, and the less time I spend optimizing every single memory allocation, the more time I get to spend making features that matter to the user.


There will be three separate pieces of software that will make the Morgemil system:

    1. The Single-player game.
      1. Rather obvious, the entire reason and end-goal of this project.
    2. The restful web service.
      1. This is an interesting bit. There will be the option to stay connected to this server to log and display player statistics, characters, and some other things I don’t want to spoil yet.
      2. There will be a system of checks to limit and hopefully disable cheating. I know that will be impossible to guarantee absolutely when the client is handling the computations but those who cheat should have abnormal data ratting them out.
      3. I do want to emphasize that this server will not be meant to enable a multi-player mode. I have not yet been able to reconcile the game mechanics with multiple players in the same game, and I’m not sure I can.
    3. The website.
      1. This is where various views of the logged data can be displayed: what characters perished on what level, player’s characters, hall of fame, etc.
      2. This is arguably my weakest point of knowledge and will certainly be a good thing to learn. But this will be developed last as it is not very useful without the two preceding pieces.

Catch me next time when I start coding and laying down more specifics!