Tunnel Lords on the Windows App Store

Summary:

Porting Tunnel Lords for use on the Windows App Store and adding touch screen input.

Tunnel Lords on the Windows App Store

Brett208 29 Jan 2017 09:15

Overview

My entry is porting Tunnel Lords to the Windows App Store. Tunnel Lords is an existing game that I started during Competition #4 and completed during Competition #7 (Work occurred outside the competitions as well). You can check it out at TunnelLords.com.

I plan to create builds of Tunnel Lords for tablets (touch enabled), PCs, and the Xbox One. The Xbox One build depends on getting accepted through ID@XBOX. To complete these goals, I'll have to make Tunnel Lords touch and mouse input enabled, port it to MonoGame, and properly interface with Windows Universal Platform (UWP). Our target date for completing the port is 29 March, 2017.

Tunnel Lords is already available Xbox 360 for and for Windows PC through itch.io.

Tunnel Lords trailer

---

Background

Tunnel Lords has been available on Xbox 360 Indie Games since 7 January, 2016. I’m very pleased with the results, with a ranking of 4+ out of 5 stars. She was programmed over the course of 1 full year (Jan 2015 – Jan 2016). I worked part time consistently the entire year. For content, my brother composed the music and half of the sounds. My wife drew about 80% of the graphics. I did all the programming and the remaining sounds and graphics. The game was completed on a shoestring budget (unless you include our time costs, which were very high), with us spending about $200 outside of purchasing the XBOX 360 for testing and deployment. Tunnel Lords was programmed in C# using XNA 4.0.

Development History

• Competition 4: Project start through first demo
• Competition 6: The long slog of game improvements and balancing
• Competition 7: Completing Tunnel Lords and publishing on Xbxo 360 Indie Games
• Competition 8: Porting Tunnel Lords to itch.io

Initial Tunnel Lords screenshot from first month of programming

Current Tunnel Lords screenshot

The Challenge

Unfortunately, the Xbox 360 Indie Games Marketplace will cease to exist in September of 2017 and we would like the game to live on past this. Because of this, we ported Tunnel Lords to itch.io for Windows PC. Unfortunately, we see very little traffic through itch.io, and still receive the most all of our downloads through the Xbox 360. So, in general the itch.io port has been a bust. However, I did learn A TON about how to properly bundle compiled code into an installer, handle multiple screen resolutions, and where/how to save user data properly on a computer.

We did attempt to publish on Steam Greenlight, but have not received a warm reception. If interested, you can check it out here: Tunnel Lords on Steam Greenlight.

We kept searching for where we wanted to try and port Tunnel Lords. After considering the Razor Forge TV, or a Linux port, we settled on the Windows App store. It has the benefit of not requiring porting Tunnel Lords to a different operating system while still expanding availability to tablets and hopefully the Xbox One.

---

High level Road Map

• Add mouse control
• Add touch screen control
• Redesign the intro screen to allow selecting touch, mouse, keyboard, or controller as primary input
• Port to MonoGame 3.5.1
• Mate game with Windows Universal Platform (must run in a special environment)
• Determine/comply with Windows Universal Platform specific release requirements like game content ratings, E&O insurance. Some may only be required for Xbox One.
• Design/format new box art, screen shots, video trailer (if needed?), etc
• Port to Xbox One through Windows Universal Platform (if approved)

Last edited on 29 Jan 2017 09:28 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 05 Feb 2017 19:43

Sprint 0: Mouse Input & Musing on Solution Reorganization

For sprint 0, I implemented mouse input for Tunnel Lords. Previously, only an Xbox compliant controller or keyboard was supported. Now the game can be played with just the mouse (or a combo of the mouse and keyboard).

I updated the initial input splash screen to allow indicating touch, mouse, keyboard, or controller as primary input means. Other forms of input are fully supported no matter which primary input the player chooses, but the on screen input cues are only shown for the input device chosen. This can be changed later with the options screen.

Older Input Select Screen (Ver 1.4.4)

Newer Input Select Screen (Ver 1.5)

Mouse handling woes

Initially making the menus support mouse input smoothly and quicker than I suspected. However, refining mouse input to accept things like left + right button releases without triggering a left button release by itself took longer than expected. I had a lot of trouble debugging the MouseManager. Everything appears to be working properly now. I’m very close to being ready for final mouse gameplay tests (IE sitting for 30 minutes to an hour and just playing Tunnel Lords using the mouse).

Reorganizing the Tunnel Lords Solution

Currently Tunnel Lords is organized into 7 projects within the solution. There is a Content project shared by Xbox 360 and PC. Then there are duplicates of three projects, one for Xbox 360 and one for PC: Game Utilities, Data (structures shared with the game and the content project), and the primary Tunnel Lords namespace.

I need to rework the projects moving forward to support the Windows App store. There is no reason to keep the Xbox 360 code around anymore since the Xbox Live Indie Games Marketplace is no longer allowing new submissions or even updates to existing submissions. I could still build the game for use on my personal Xbox 360, however I don’t know if this is even supported by MonoGame, which I will be porting Tunnel Lords to soon.

Xbox360 was the first platform Tunnel Lords was published on, so it has a really special meaning to me and I’m loathe to chuck the Xbox 360 code moving forward. However, my code is currently riddled with preprocessor directives to separate the Windows and Xbox code (#if WINDOWS / #if XBOX) since the version of .Net framework on the Xbox 360 is not the same as the one on PCs among other reasons. So removing it would simplify things.

The setup going forward should probably be the following projects:

• Game Utilities (basic code that is applicable to any of my games)
• Shared Data Structures (between content and the Tunnel Lords Core project)
• Content
• Tunnel Lords Core Project (Not able to compile into an executable on its own)
• Windows 7 Tunnel Lords (build for outside the Windows App Store)
• Windows App Store Tunnel Lords (Maybe set preprocessing properties based on Tablet vs PC)
• Xbox One (If approved…)
• Xbox 360 (Sigh)

I plan on placing as much code as possible in the non-platform specific projects. Code that is very specific to a platform (like where to save data) will exist in each of the platform specific projects. This should reduce the duplication required and hopefully keep everything straight.

There is a way to create projects that mirror all code as their parent project but allow for different settings. This is how my Xbox 360 projects are currently setup. If I create a new class/file in the PC project, Visual Studio automatically references the new class/file in the Xbox project. I’m unsure how this works or how to set it up though. XNA handled it all when I pressed a button to create an Xbox 360 copy.

Sprint 1 Goals

• Add basic screen touch input to game
• Stretch Goal: Create artwork for a dedicated instructions screen
• Stretch Goal: Reorganize projects to align with supporting more platforms

Other Commitments

I’m going to commit to making a new demo release of Tunnel Lords available at the end of the competition for people to check out if they wish. It probably won’t include everything the Windows App Store demo will have since I won’t be ready in 30 days.

Last edited on 07 Feb 2017 19:10 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 07 Feb 2017 19:08

Denied for Xbox One

Yesterday I received an email from ID@Xbox saying they denied Tunnel Lords entry on the Xbox One. Unfortunately, the email was generic and didn't give any clues as to why Tunnel Lords was denied. It did state the we could re-submit Tunnel Lords after it has been live in the Windows App store for at least 30 days. (I'm assuming they would reconsider allowing the game if it ranked well and downloaded well in the App Store.) I suspect it was denied because the graphics are not polished enough, but not really sure?

So, for now we are pressing forward with releasing on the Windows App store for PC and Windows tablet. If sales and reviews look great, perhaps we will make another bid at the Xbox One.

I was hoping things would go differently since Tunnel Lords has been ranked fairly well on the Xbox 360, at least in my opinion.

Well, I hope everyone else is having more success with their game development!

Last edited on 07 Feb 2017 19:10 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 14 Feb 2017 01:14

Mouse/Touch Input Cues and Porting to MonoGame

This week I completed basic touch screen input controls and ported Tunnel Lords to MonoGame 3.5.1. I was pleased with how smoothly the transition to MonoGame went. While touch screen code has been added, it has not been tested since I do not currently have easy access to a touch screen device.

Mouse & Touch Input Cue Graphics

We generated a couple of icons to represent mouse and touch input. I’m pleased with how they turned out. We may take another pass improving them before the final release. While playing Tunnel Lords, the input cue graphics change based on which input device is selected as primary.

New Touch and Mouse Input Cues

We needed a way to steer the drillship with mouse and touch screen. I decided to separate the screen into multiple arcs radiating from the center. When pressing the mouse/touching a particular quadrant, the drillship moves in that direction. So you are limited to driving left/right, flying left-up, right-up, and straight up, and drilling down. I thought about adding full freedom of movement (IE change the x/y vector based on exact screen position), but this would give you a control advantage when using mouse/touch/joystick over the keyboard or arrows on a gamepad. (It would also require a lot more work adapting the current input logic.)

I added a HUD graphic showing control quadrants. It works, but could probably use some polishing. I had to modify the game’s camera to actually put the drillship in the center. Turns out I was drawing the drillship’s top left pixel in the center which looked goofy with the HUD graphic overlayed. The magenta arrows don't actually mean anything. The green lines are the ones that denote the changes in movement.

Mouse & Touch Control Angles HUD graphic

MonoGame Port

I ported Tunnel Lords to MonoGame 3.5.1 and .Net 4.6.2 this week. The port went very smoothly. I think there are some lingering issues with screen resolution resizes not working properly in MonoGame. I’m going to wait until getting the game running in a UWP frame before worrying too much about it though because I’m worried UWP will require specific and different code to affect screen resolution changes.

When transferring all the content to the MonoGame content manager, I was getting a cryptic content build error. After about an hour of fiddling, I realized that when copying all the files in I had copied in Content.mgcb itself into the content pipeline. So the content pipeline was trying to build itself, if that makes sense at all. After removing it, most everything built properly.

I found a bug where spritefonts in MonoGame will not render as Bold/Italics properly. I managed to work around the issue by either building the spritefonts in XNA and transferring over the XNB file. Adding bold/italics directly to the Font’s title XML element as opposed to the style XML element also fixed it for some fonts but not others. It looks like others have already reported the bug to MonoGame.

New Development Environment

I’m currently developing on a non-touch screen Windows 7 computer, which I am very comfortable with. Even though I would prefer not to upgrade, it doesn’t appear possible to compile the source code for use with UWP without using a Windows 10 computer. It would probably be smart to get a new Windows 10 computer that also has a touch screen. So I’m looking at buying a new machine. It probably needs to be purchased in the next week or so to keep from slowing development. I’m running out of tasks I can complete on Windows 7 only.

Sprint 2 Goals

• Read through large chunks of the Universal Windows Program documentation related to Tunnel Lords
• Reorganize projects to align with supporting more platforms (Windows generic vs UWP)
• Stretch Goal: Start testing touch screen code
• Stretch Goal: Create a dedicated instructions screen
• Stretch Goal: Get a Windows 10 development computer setup
• Stretch Goal: Design code for saving/loading Tunnel Lords settings data on UWP

Re: Tunnel Lords on the Windows App Store

Brett208 21 Feb 2017 02:01

Sprint 2 Results: Universal Windows Platform (UWP) Build of Tunnel Lords

This sprint was productive with completing a clean install of Windows 10 on my development computer, re-organizing Tunnel Lords to support multiple platform builds (UWP and generic Windows), getting a partial build of Tunnel Lords working within UWP, and completing some class refactoring.

Additionally, I spent a lot of time reading on Microsoft’s UWP documentation and started on programming a nice game tutorial screen for Turnnel Lords, which is still far from complete.

Windows 10

After convincing my wife that I needed a new computer, we ended up just upgrading my current development computer to Windows 10. While I'd really like a shiny new machine, this one has a lot of life left and still works fast and reliably for my uses. So we saved the money. I did a clean installation of the new operating system and had to reinstall everything on the new machine, which took a lot of time. As always, there were a few hiccups with the upgrade, but everything seems to be running smoothly now. After spending the last year talking about how I dislike the way Windows 10 looks/feels, it hasn't been too bad using. It isn't noticeably slower than Windows 7, so that is nice. I'm turning into that guy that just complains about anything new related to technology since I don't want to spend the brainpower to learn it… :)

Building Tunnel Lords for UWP

Once everything was compiling on Windows 10, I took a stab at getting Tunnel Lords running within the Universal Windows Platform (UWP) framework. I came across several snags.

At first, I didn't understand that UWP uses a different version of .Net framework than conventional desktop applications. It uses .Net Core, which actually compiles into native code as opposed to using the JIT (Just In Time) compiler. This should give it a nice performance boost, and I actually like this over using the JIT (I think?). The problem is that if I build my class libraries leveraging .Net 4.6.2 (or any .Net outside of .Net core), they cannot be used by the UWP build of Tunnel Lords. Besides compiling into native code for Windows, .Net core can be used on Linux and MacOS and is open source. Sounds very awesome indeed! .Net Core is updated in your projects through Nuget, which is a little different as well.

I ended up solving the mismatch between .Net Framework 4.6.2 and .Net Core by making a second project for each of the class libraries. There is now a GameUtilities project that compiles with .Net 4.6.2 and a GameUtilitiesUWP project that compiles for UWP using .Net Core. The UWP version just links to all the source code files and doesn't actually contain anything unique. This is basically how I handled compiling code for both the PC and Xbox 360 with XNA. The benefit of XNA was it would automatically link any files I created for the PC build to the Xbox project, saving time. I'm unsure how to make this hook happen on my own and am doing the work manually. This isn't a big deal though since Tunnel Lords is mature and I'm not adding many new code files anymore. It would have been a real chore earlier in development.

I managed to link the MonoGame content project to both the UWP and generic Windows build, so I only have to add new content in one place and MonoGame will handle building it for either environment. Not much different between the environments in this case, but it works the same for Linux or Android or MacOS. Nice work MonoGame!

I had LOTS of problems with the MonoGame UWP template project. I ended up using the C# UWP app project from Visual Studio, and then manually adding the references to MonoGame. This took a while since I've never integrated MonoGame (or XNA) into a project manually before. I even tried using the current non-stable build of MonoGame (ver 3.6), but it didn't work either. I think it is buggy, but there could also be some operator error since it is my first time working with UWP.

I have a MonoGame running within a UWP frame. Important step forward!

The current problem is MonoGame failing to properly read my custom XML data when calling Content.Load on the UWP build; When I read in XML data that only contains C# types (like Dictionary, string, int, etc), it works fine. When I try reading in my own custom data class (like Dictionary<string, MineData>), MonoGame throws an error. The content processor appears to be writing the XML content properly as .xnb files, but cannot read the .xnb file into the game. It throws the error on Content.Load. I think the problem is the ContentTypeReader is unable to understand my custom data types. However, I don't know why the non-UWP build of the game is able to read the XML data and the UWP version is unable. Perhaps I messed something up when adding the MonoGame references to the UWP project?

An exception of type 'Microsoft.Xna.Framework.Content.ContentLoadException' occurred in MonoGame.Framework.dll but was not handled in user code

Additional information: Could not find ContentTypeReader Type. Please ensure the name of the Assembly that contains the Type matches the assembly in the full type name: Microsoft.Xna.Framework.Content.DictionaryReader`2[[GameUtilities.Input.InputCommands, GameUtilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null],[GameUtilities.Input.KeyList, GameUtilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]] (Microsoft.Xna.Framework.Content.DictionaryReader`2[[GameUtilities.Input.InputCommands, GameUtilities],[GameUtilities.Input.KeyList, GameUtilities]])

If unable to solve it soon, I'll probably post on the MonoGame website asking for help.

UWP .Net Framework compatibility issues

Beyond causing all the headache of creating multiple projects due to .Net Core, .Net Core does not contain everything available within .Net Framework 4.6.2.

• The Console class does not exist on UWP. I was using Console to write output data when certain errors occured. I had to switch these to .Net Debug, but I think it will work close to the same.
• The StringComparer class does not include the properties InvariantCulture or InvariantCultureIgnoreCase. I just switched to using OrdinalIgnoreCase when comparing strings instead of InvariantCultureIgnoreCase.
• UWP does not contain the class System.Diagnostics.Process. I was using System.Diagnostics.Process.Start to open the player's browser to Itch.IO when they selected purchase game. This will be handled by a different mechanism on UWP anyways, so no loss here.

So while .Net core framework is missing some parts of the traditional .Net framework, the issues were easy to workaround.

GameUtilities Refactoring & Instructions Screen

I spent some time cleaning my class library code. Some of this code was written by me 2 years ago (or more) and it was written poorly. I can tell my coding style has matured over time. I spent time renaming a lot of the methods and cleaning poorly written algorithms. I noticed the poor code while building up the Instructions screen. I'm setting the instruction screen to show on first play through or when selected from the main menu. The screen still needs a lot of work in the coming weeks though.

Sprint 3

I have family visiting later this week and expect work to be busy before then. Progress will probably be slow.

• Fix Content read error for custom types serialized as XML.
• Read through more large chunks of the Universal Windows Program documentation related to Tunnel Lords
• Stretch Goal: Start testing touch screen code
• Stretch Goal: Finish the dedicated instructions screen
• Stretch Goal: Design code for saving/loading Tunnel Lords settings data on UWP

Last edited on 21 Feb 2017 02:45 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 27 Feb 2017 05:22

Sprint 3 Results: Reducing Project Clutter

This sprint, I reworked Tunnel Lords’ solution into less projects by leveraging Portable Class Libraries (PCLs) and solved the content type reader issues I was having when reading in custom XML classes (though a hacky solution). I didn’t have as much time as in past weeks, so progress was slow, but that is part of working on hobby hours.

Understanding the new .Net Framework Ecosystem

I had a conversation with RB over Discord about the changes in the .Net framework in the last 2 years. I’ve been out of the loop with the development of .Net Core and .Net Standard. This week, I researched both of these topics and Portable Class Libraries (PCL).

To reduce the number of projects associated with Tunnel Lords, I started using PCLs that target both .Net Framework 4.6.2 and .Net Core for Universal Windows Programs (UWP). Last week, I was creating 2 of every library project in order to compile it both with .Net 4.6.2 (for the PC version) and .Net Core (for the UWP version). Using PCLs, Visual Studio allows for dynamically changing which version of .Net is compiled against in the library project based on the need of the final compiled application. This is great news because it cut out all the redundant projects within the Tunnel Lords solution.

Tunnel Lords' Projects

I believe .Net Standard class libraries would serve to solve the redundant projects issues just as PCLs solve them. According to this article (https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/), Microsoft is actually moving away from PCLs in favor of .Net Standard. Even after reading through the article, I’m pretty fuzzy on what benefits are gained from .Net Standard over PCLs. I actually really liked that I can chose what platforms a PCL supports and then letting the compiler complain if I try and use features that are not supported on all the chosen platforms.

Even though Microsoft plans to move towards .Net Standard, there is no way to select a .Net standard class library template from Visual Studio 2015. Perhaps I’m just missing something?

Under the hood of MonoGame Content Builder (MGCB)

I learned the MonoGame content pipeline does not require referenced data classes to be contained in a third library that is referenced by both the content pipeline and the game project. This is a requirement for XNA games. Because of this, I was also able to merge the TunnelLordsData project with the TunnelLordsCore project. This removed the TunnelLordsData project.

I’m a big fan of the human readable text format of the contents of the Monogame.MGCB files.

I attempted to link the MonoGame content project between both the PC and the UWP Tunnel Lords projects. I had a lot of issues with the XML Content Type Reader not working for the UWP build of the game. I’m not sure why, but by creating a separate content project for the UWP version, I was able to get everything running in UWP. So, I currently must add content to both projects separately, which is not ideal. I may look into this some more in the future and try to solve it.

Launching Game in a Xaml window

TunnelLords contains an ISettingsSerializer for serializing and deserializing game settings. I was planning on passing the specific Serializer as a parameter to the Tunnel Lords game class constructor. Unfortunately, MonoGame’s method for creating the game within the Xaml window requires the Game class to have a parameterless constructor.

private readonly TunnelLords _game;
 
public GamePage()
{
    this.InitializeComponent();
 
    // Create the game.
    var launchArguments = string.Empty;
    _game = MonoGame.Framework.XamlGame<TunnelLords>.Create(launchArguments, Window.Current.CoreWindow, swapChainPanel);
}

Error CS0310 'TunnelLords' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'T' in the generic type or method 'XamlGame<T>'

Right now, the UWP version of Tunnel Lords is using a dummy SettingsSerializer while I work through an alternate way of passing the SettingsSerializer in. A workable solution would be to create a new Game class for each platform variation that inherits a base TunnelLordsGame class. This way I could set the Serializer in the constructor of each platform specific version of the game. I need to think through the implications of this solution a little more though.

I really want to pull the game’s settings before initializing everything within the game and loading content. This way, things like the game’s resolution are set first and don’t have to be re-updated after all the content is loaded and classes initialized.

Using the Development Brach of MonoGame

I started using the newest build of MonoGame. Mostly because the MonoGame website asks developers to do so.

From MonoGame.net/downloads

When new fixes, features, or changes are merged into our development branch the build server generates new installers. It is extremely helpful to have the community install and use these builds when ever possible. We find these releases to be generally stable, but if you do run into a bug please report it to us.

Sprint 4 Goals

I have family visiting, so progress will be slow.

• Implement UWP specific content (like the UWP splash screen and Windows 10 tile graphics)
• Stretch Goal: Start testing touch screen code
• Stretch Goal: Finish the dedicated instructions screen
• Stretch Goal: Design code for saving/loading Tunnel Lords settings data on UWP

Re: Tunnel Lords on the Windows App Store

Icecream-Burglar 27 Feb 2017 17:44

I started using the newest build of MonoGame. Mostly because the MonoGame website asks developers to do so.

Personally, I just always use the pre-release dev-build nuget packages.

Re: Tunnel Lords on the Windows App Store

Brett208 01 Mar 2017 02:38

Icecream-Burglar,

I've stayed away from Nuget, as I'm not sure of the worth of the benefits/tradeoffs. I think continually pulling the dev-build is dangerous for the stability of a game in late cycle though. So I'll probably stick with the dev build I downloaded through release unless there is a reason to pull a newer one. I'm not sure how many new features you miss out on waiting on the long intervals between MonoGame stable releases, but that is what I've done in the past.

Everyone,

I realized this coming weekend is the last in the competition. I promised a demo build of Tunnel Lords' current progress. So I'm pushing back the original goals and instead working on updating my InnoSetup installer script to include MonoGame and .Net 4.6.2.

I found some typos in the installer text. There is also room to improve my Pascal functions. InnoSetup was updated last year to incorporate new features available for installers in Windows 10, so I want to do a little research and see what they are.

Plan on a demo release hopefully by this coming Monday. The demo will probably be for the PC version but include the mouse and touch input code. I wouldn't mind a UWP demo, but not sure it is mature enough yet.

-Brett

Last edited on 01 Mar 2017 02:39 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 05 Mar 2017 02:15

Sprint 4 Results: Tunnel Lords 1.5.0 PC Build Preview Demo

Besides cleaning up my installer script for MonoGame and moving to a .Net installer that downloads .Net 4.6.2 from online, not much progress was made in sprint 4. But this was expected as I had a lot of other things going on.

Since I switched goals a couple days in, none of my original goals were completed.

A demo including the partially completed code written this competition can be found here: http://tunnellords.com/content/Installer/TunnelLordsInstallerVer1.5.0Demo.exe

Known Bugs:

• Touch input system is completely untested.
• When selecting ‘open browser’ from the demo screen, nothing happens. (I still need to hook this in so that it plays nice with either PC or UWP versions of the game).
• The option to turn on/off instructions screen from the options menu does not affect the game (Instructions screen is incomplete).

Feedback

I would be very interested in people testing controlling the drillship with the mouse. Is gameplay natural? Do 2 button clicks work as expected?

I would also be interested in hearing how the installation goes for anyone that does not have .net 4.6.2 already installed or is kind enough to remove it from their CPU temporarily while checking out Tunnel Lords.

• Does the installer exit gracefully if you choose not to install .Net 4.6.2
• What the installer does if you are not connected to the internet when telling it you want to install .Net 4.6.2
• Finally, is .Net 4.6.2 successfully installed

Alternate Computer for Installer Script Testing

I used to test the installer on my dev computer by manually uninstalling .Net framework or XNA and then running the installer to ensure it could recognize missing pre-requisites successfully, warn the user before installing them, and then properly install them or exit gracefully if the user didn’t want to install the pre-requisite for whatever reason. The problem is that I was only testing on one operating system. I was uninstalling/reinstalling the developer version of XNA & .Net framework often from my dev CPU which was not ideal.

I would like to have a cheap extra laptop around to install/uninstall random prerequisites from as needed to installer scripts. I also want to continue testing the installer and game on Windows 7 to ensure everything remains backwards compatible.

I have an old, broken Windows 7 laptop that currently will not charge the battery. If I can get the computer repaired, it would make for a nice computer to wipe regularly and test installs on. I’m not much of an electrical engineer, so we will see how the repair goes. I might be better off buying a beater computer from EBay.

Way Forward

Even though the competition ends this weekend, I’ll be continuing work on Tunnel Lords in the coming month. I’m hoping to release on the Windows App Store by the end of March, but the date is becoming fluid as work is slow and I have to navigate the publishing requirements for the Windows App Store which I’ve never worked through.

Sprint 5 Goals:

Even though the competition formally ends this weekend, I’ll be continuing on for another sprint. Mostly, the goals remain the same. I’m hoping to find some time to work especially later in the week. I haven’t had enough time to really jump on the chat server and talk with anyone lately.

• Implement UWP specific content (like the UWP splash screen and Windows 10 tile graphics)
• Stretch Goal: Start testing touch screen code
• Stretch Goal: Finish the dedicated instructions screen
• Stretch Goal: Design code for saving/loading Tunnel Lords settings data on UWP

Good Luck!

I hope everyone else who participated is satisfied with what they learned or completed (or both!) during the competition. I’ll be happy to read through everyone else’s final posts and try out anything if demos are posted!

Last edited on 05 Mar 2017 03:13 by Brett208 Show more

Re: Tunnel Lords on the Windows App Store

Brett208 15 Mar 2017 08:06

Sprint 5 Frustrations

I've been continuing work on Tunnel Lords. Unfortunately, I've been plagued with compatibility issues dealing with .net core, .net standard, and Portable Class Libraries (PCLs). It seems like every time I work on a feature in the game and go to test it, another problem manifests itself within my projects dealing with references to the .net framework. I end up spending an hour or two (or more) tracking down and fixing each issue as they bubble up.

I've refactored my code for saving/loading games to work both within UWP and a more traditional windows build. While the code compiled fine, I had issues with Tunnel Lords being unable to load required assemblies. It produced messages as below for about a half dozen different .net assemblies when attempting to run the code.

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

I found that by adding all the assemblies via Nuget to the TunnelLordsPC project, allowed the program to run on PC. I thought on my PC build it would reference .Net 4.6.2 (or .Net 4.6.1). So I'm confused why the Nuget packages are required to make the game build. I thought perhaps upgrading the projects to .Net standard would simplify having to download all the assemblies via Nuget. Unfortunately, it didn't seem to change anything.

Unfortunately, after upgrading the class libraries from PCLS to .Net Standard, my UWP build no longer worked. So for now I had to just remove the UWP project from the solution while I troubleshoot the regular Windows PC version.

Trying to get Tunnel Lords to build on both UWP and Windows is turning into a bit of a nightmare. I'm slowly learning about .Net standard, .Net Core, and Nuget, but it is very painful. Work on Tunnel Lords has been slower because dealing with all the compatibility issues isn't 'fun' and I dread slogging through it most days.

Hopefully things will start clicking soon and I'll be able to hum along at a decent clip. There is a lot of work to do on touch screen and then plenty of cleanup work in many sections of the game.

UWP Packaging

Before having to remove the UWP project from the solution, I made good progress learning how to package/deploy a UWP application. Below are some of the tiles I designed when testing. They will probably get a cleanup pass later.

Re: Tunnel Lords on the Windows App Store

Brett208 07 Apr 2017 07:40

Hey everyone.

Progress sort of ground to a halt not long after the last post. My job has become pretty stressful for a couple of different reasons. I also sort of wanted a break from grinding through UWP (not that more work was the break I had in mind though!). I think work will be under control again in a couple of weeks??? Then early May we will be traveling for my sister's wedding.

So I may have some time near the end of April to work if I'm lucky. Probably more likely mid May though…

I'm waiting for more information on the XBOX One Creators program. It has hope of being a great way to publish Indie Games.

I've had a little bit of correspondence from fans of Tunnel Lords on the website lately. That has been fun to receive and reply to. I'm really glad to have thrown up the website so people could get in touch with me about the game. If anyone gets the chance to publish, I highly recommend making a way for players to get in touch with you.

-Brett