Saturday, April 18, 2015

MODEXngine Development Log Part 1

Introduction

Taking 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 MODEXngine is 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 Details

A 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.

Modability

Even 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 to

Those 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.


Friday, April 03, 2015

How to add EntityFramework 7 to a non-ASP.NET 5 project

Continuing my work deep diving into ASP.NET 5 (vNext), I started going down the path of EntityFramework 7. Which similiarly to ASP.NET 5, is like a reboot of the framework itself. Readers interested to dive in, I highly suggest you watch the MVA Video called What's New with ASP.NET 5 that goes over all of the changes in pretty good detail (though I have a running questions list to ask at BUILD in a few weeks).

Noting that EntityFramework 7 beta was included in my ASP.NET 5 project, I hit a road block into finding it through the usual method in the NuGet Package Manager. As of this writing, only 6.1.3 was available. In looking around, the answer is to add another NuGet Package Source. I had done this previously as I setup a private NuGet Package Server at work to host common libraries used throughout all of our projects. For those unaware, goto Tools->NuGet Package Manager->Package Manager Settings.

Once there, click on Package Sources and then the + icon, enter a descriptive name and for the source and paste the following url: https://www.myget.org/F/aspnetvnext/ and click Update. After you're done, you should have something similiar to this:



You can now close out that window and return to the NuGet Package Manager and upon switching the Package Source dropdown to be ASP.NET vNext (or whatever you called it in the previous screen) you should now see EntityFramework 7 (among other pre-release packages) as shown below.



Hopefully that helps someone out there wanting to deep dive into EntityFramework 7.


Thursday, April 02, 2015

bbXP and a deep dive into ASP.NET 5 Configuration

Per my announcement on Sunday, I'm working on making bbXP (my CMS that runs this site) generic to the point where anyone could just use it with minimal configuration/customizations. Along this journey, I'm going to be utilizing all of the new ASP.NET 5 (vNext) features. This way I'll be able to use my platform as a test bed for all of the new features of ASP.NET 5 and then apply to production products at work, much like what Version 1 was in back in day when I wanted to deep dive into PHP and MySQL back in 2003 and MVC in general almost 2 years ago.

Tonight's deep dive was into the new configuration model. If you've been developing for ASP.NET or .NET in general you're probably accustomed to using either the app.config or the web.config like .

And then in your app you would do something like this:

var siteName = ConfigurationManager.AppSettings["SITE_NAME"];
And if you got a little fancier you would add a wrapper in your base page or controller to return typed properties for booleans or integers.

With ASP.NET 5, configuration is completely new and extremely flexible, but with the same end result. I will assume you have at the very least downloaded and installed the Visual Studio 2015 CTP in addition to launching the ASP.NET 5 template to at least get somewhat comfortable with all the changes. If you are just starting, I highly suggest watching Daniel Roth's introduction video.

To dive into the configuration specifically, you will want to open the Startup.cs. You will notice at the top of class is the Startup constructor. For bbXP I wanted to add my own json configuration file so my constructor looks like:
public Startup(IHostingEnvironment env) {
	Configuration = new Configuration()
		.AddJsonFile("config.json")
		.AddJsonFile("bbxpconfig.json");
}
Knowing I would not have the same ConfigurationManager.AppSettings access as I am used to, I wanted to make a clean method for which to access these configuration options and go one step further to make it strongly typed and utilize dependency injection. So I came up with a quick approach to dynamically populate a class and then use DI to pass the class to my controllers. To get started I wrote a quick function to populate an arbitrary class:

private T readConfig() {
	var tmpObject = Activator.CreateInstance();

	var objectType = tmpObject.GetType();
	IList props = new List(objectType.GetProperties());

	var className = objectType.Name;

	foreach (var prop in props) {
		var cfgValue = Configuration.Get(String.Format("{0}:{1}", className, prop.Name));

		prop.SetValue(tmpObject, cfgValue, null);
	}

	return tmpObject;
}
And then my arbitrary class:

public class GlobalVars {
	public string SITE_NAME { get; set; }
}
Scrolling down to the ConfigureServices function also in the Startup.cs:

public void ConfigureServices(IServiceCollection services) {
    services.AddMvc();

    services.AddWebApiConventions();

	var options = readConfig();

	services.AddSingleton(a => options);
}
In this method the first 2 lines are unchanged, but the last 2 add my GlobalVars to the DI list and initialize it with the options from my file. Now to see it in action inside a controller:

[Activate]
private GlobalVars _globalVars { get; set; }

public IActionResult Index() {
	ViewBag.Title = _globalVars.SITE_NAME;

	return View();
}
Notice how clean the access to the option is now simply using the new Activate attribute on top of the GlobalVars property. Something I'll be adding to this helper method going forward is type inference so the readConfig method would typecast to the type of the property in your arbitrary class.

Hopefully this helped someone out there in diving into the next version of ASP.NET, more to come for sure.