Saturday, April 18, 2015
MODEXngine Development Log Part 1
IntroductionTaking a break from ASP.NET 5 (and Visual Studio 2015 CTP6) until the next CTP release I've gone back to working on a project I started for all intents and purposes back in 1995, the
MODEXngine. As mentioned back on August 8th, 2013, the
MODEXngineis intended to not only being a game engine with the usual graphics, audio, input handling etc, but also a cloud platform. With cell phones and tablets establishing themselves as a viable platform to target the last several years, one can no longer simply focus on the PC (Win32/Linux/Mac OSX). With mobility also comes with things that a traditional "PC" developer wouldn't run into: vastly different platform APIs, network drops, "5 minute or less" gameplay and supporting an eco-system that crosses all of those platforms. Coming at this as an enterprise developer who actively develops on virtually every platform (Windows, the Web, Android, iOS, Windows Phone and Windows Store), I feel as though I bring a fairly unique perspective of how everything can exist and bring the experience to each platform natively, putting myself in the shoes of someone who wants to develop a game for every platform, but wants full native control over the platform as opposed to an "Apache Cordova" approach in which it solves the bigger problem of quickly delivering to multiple platforms, but stalls when you have a feature that needs more native functionality (let alone speed). Another advantage I hope to bring is the ease of use. Wrapping native level calls with generic wrappers across the board, it should cut down on the issues of "how do I do that on platform XYZ", similar to how Xamarin Forms has made wrappers for iOS, Android and Windows Phone, but hopefully with less issues.
With the introduction and overall goals out of the way, lets deep diving into the details.
Language and Tech DetailsA big decision (one that I am still not 100% decided on) is the overall language used for the platform. Keeping to just one language has the advantage that if someone knows the language I choose, he or she can develop againinst the entire platform. However, one language for a project of this scope goes against my "use the best tool for the job" principle. By utilizing my language of choice, C#, I would be committing people to utilizing Xamarin for iOS and Android deployments. For smaller projects, they could simply get away with the free license, but that would be putting an extra burden on the developer (or development team) which also has to incur the costs of simply getting into the various stores for iOS, Android and Windows. On that same breath, with Microsoft's big push for cross-platform development to Linux and Mac OSX this might be overlooked (hoping that one day that license is just bundled with Visual Studio so this point would be mute for the most part).
The bigger question that has been pestering me for quite some time is the graphics API to use. When Carmack gave his observations of Direct3D back in mid 90s when asked why there was only an OpenGL port of Quake, I chose to follow his path of using OpenGL. It made sense at the time and still does. It is supported by almost every platform and only being focused on graphics I appreciated far more (and still do) than the "I can do everything" model that DirectX followed. While it might be unfair now to continue that mentality almost 20 years later, the idea still holds true. I can utilize OpenGL on Linux, iOS, Android, Mac OSX and regular Windows desktop applications all in C#. The only platforms I would be excluding would be Windows Phone and Windows Store. Which for followers of this blog, know I love from both a consumer and developer's perspective in every aspect but Microsoft's stance on not allowing OpenGL natively supported like they have done since Windows NT. Doing some research into this issue, I came across the ANGLE (Almost Native Graphics Layer Engine) project which translates OpenGL ES calls to DirectX 9 or 11 calls for Windows Phone and Windows Store apps. As of right now I haven't dove into this library to see its full capabilities, but from the MSDN blog posts on it, this approach has been used in production grade apps.
For the time being, I think utilizing C# across the board is the best approach. Web Developers who know ASP.NET would find the WebAPI service and libraries accessible, while Windows Phone/Store developers would find the engine libraries no different than utilizing a NuGet package.
The area where I want to be a lot more flexible is in the CRUD operations on data locally and in the Cloud. In my mind, whether the data is on a device or on a cloud, during retrieval it should make no difference. Akin to how easy Quake III made it to download levels from the games' server without having to leave and come back (as was the case in other games of that era). Obviously if one isn't connected to the internet or dropped connection then handling needs to be in place to handle a hybrid situation, but for all intents and purposes the shock and awe of doing such an implementation really isn't a huge endeavor if one designs the architecture with that in mind.
Along those same lines a big question in my mind is the storage of user data, statistics, level and other game content. A traditional .NET developer approach would be to utilize SQL Server 2014 and possibly Azure File Storage for the content (textures, audio files etc). Open source developers coming from Python or PHP might be drawn to use MySQL or MongoDB in place of SQL Server. My goal is to make the calls abstract so that depending on you, the developer, you can utilize whatever you wish. I more than likely will be using SQL Server for User Data at the very least, but planning ahead for potentially billions of concurrent users storing the rest of the data in that fashion would be extremely inefficient. Databases like Redis or ArangoDB might be a better choice for concurrent data. Or perhaps even my own distrubted key/value database jcDB. Seeing as I am still setting up the overall architecture, this will evolve and will be interesting to start doing simulated performance tests while also taking into account how easy it is to interact with each of the databases for CRUD operations.
ModabilityEven before my announcement in August of 2013, the year prior in August of 2012 I had seen a huge disconnect between mobile/console games and PC games: the ability mod. One of the things that for myself and I imagine others back in the 90s with the modability of Doom and Quake (among others), it expanded the games' community in a way. Whether it was as "simple" as a new deathmatch level or as extravagent as some of the mods like Quake Rally, it made a huge difference inbetween major game releases. To this day I am not aware of any cross platform games that support modding like id software had provided back in the 90s. Since coming up with that idea technology has changed dramatically, but the idea is the same. Instead of a WCF Service and thinking small scale, I would use a WebAPI service hosted on Azure using Azure Storage with containers for each game. Security being an even bigger issue now than it was almost 3 years ago, I would more than likely employ a human element of reviewing submitted mods prior to implementing a fully automated security scan.
Release and what to look forward toThose are the main talking points at this point in my mind, but as I get further in the development these more than likely will expand and the "features" list will need its own index.
I imagine at this point a big question on your mind is how soon this be made available in even an alpha state. Well the good news is that as I am developing the engine, I am committing all my code to GitHub under the MIT License (meaning you can use the code freely, but it comes without any warranty). Later on when it is further along and you do find it useful, a ping back would be appreciated especially if you have ideas for ways to make it better.
As for a specific release date. Knowing my freetime is extremely unstable and I still have to deep dive into OpenGL ES far more than I have, I would not expect to see this come to fruition until much later this year, especially with my bbXP project also competing for my free time (not to mention my masters program).
Any questions, comments or suggestions please leave them in the comments section below or email me at
jarred at jarredcapellman dot com.