Tag Archives: monogame

Jetboard Joust Devlog #58 – Music, Maestro!

Well, the background music’s finally done and it’s taken what seems to be an indeterminable amount of time.

It’s partly because I had to put a proposal together for some contract work in the middle of it – which made the process seem to drag on longer than it should, but also because I decided I had to sort out the ridiculous mess of cabling (of various varieties) that had overtaken my studio and was making it difficult to work. Each of those tasks took at least two days.

I guess 8.5 days total dev time isn’t too bad for the amount of background audio that’s in there but, even accounting for the aforementioned increased in elapsed time, it still seems to have been a rather lengthy and unnecessarily painful process. Here’s how it went down (and sorry for the crackling in some of this audio – seems to be problem with running Windows on a Mac)…

1. Main Theme
I knew from the get go that I was going to utilise the same approach for the background music that I had for the in-game FX, ie all analog synths for the sounds and as few software plug-ins as possible when mixing. I needed to have a rough idea of the style of music I was going for though so started by playing the game alongside a few different tracks to see what worked best. I tried a number of different electronic artists, eventually settling on the ‘Detrimentalist’ album by Venetian Snares as my favourite, with particular reference to the tracks ‘Kyokushin’ and ‘Bebikukorica Nigiri’, the latter featuring a bunch of ‘chiptune’ type sounds which seemed particularly appropriate.

Once I had a general ‘vibe’ in mind I started creating some drum patches and banging out some beats on The DSI Tempest trying to get something that worked, using a combo of the Moog Sub 37 and Mother 32 for bass and lead duties. As often as possible I’d try and listen to what I was creating alongside a recording of the in-game fx so I could try and create sounds that weren’t going to mask and/or fight against each other to much. I found this pretty difficult to be honest.

After about a day I had a simple loop that I was generally happy with and began to work up some variations on it. I probably spent a couple of days playing around with different variations, whilst running into various technical difficulties syncing up all my gear in the process (ah – the joys of MIDI and analog)!

Then I started trying to combine all these variations into a single cohesive piece of music and this is where I started to run into problems. It didn’t work. I think this was partly because my variations were all too different and didn’t ‘flow’ together, and partly because I was trying too hard (and with too little talent) to ape Venetian Snares and the result was too full-on and tuneless.

I was getting pretty frustrated by this point. Four days in and I still didn’t have anything resembling a main theme. Then I remembered a piece of music I’d written ages ago for a J2ME game called ‘Battle Snake’ that I had always been rather fond of. I decided to dust this off and see if it would work for Jetboard Joust – fortunately it seemed like it might!

The (as it stands) final theme is a mash-up of ‘Battle Snake’ (with new sounds) and some of the variations I originally created for ‘Jetboard Joust’. I’m still not entirely happy with all the sounds here, particularly some of the more distorted ‘guitary’ type synth sounds which seem to conflict too much with the in-game fx. I may well replace these with something less harmonically rich.

Thankfully I could also use some of my original variations for the other sections of game audio so that time wasn’t entirely wasted…

2. Baiter Theme
The player has approximately two minutes and twenty seconds to complete each level in Jetboard Joust before the pace is upped and the ‘Bastard’ enemies (equivalent to the Baiters in Defender) start to attack. I thought my original (rather full-on) loop would work better for this section of the game and so created a separate piece of music for this that’s more ‘high-tension’.

3. Lost Life / Level Complete
These are short sections based on the repeated section of ‘Battle Snake’ that now forms the ‘hook’ of the main theme. An ascending progression for ‘level complete’ and a descending progression for ‘lost life’.

4. Planet Ambience
OK so this isn’t a piece of music as such but I wanted some kind of background audio during the ‘quiet’ periods of the game such as at the start of each level before enemies attack and at the end of each level once all enemies are destroyed. I’ve gone for a sort of retro sci-fi spooky ambience here with analog wind effects and vintage ‘sample and hold’ type noises that trigger seemingly randomly. I also added a weird interference loop which was the sound of some of my gear accidentally wired up incorrectly that I kind of liked. I think the planet ambience gives a nice contrast to the more full-on background music.

5. Upgrade Theme
One of the variations on my original theme was a type of minimal ‘spooky’ loop with bell-like synth effects and a lot of vintage delay. In the end this didn’t work as part of the main theme (it was too downbeat) but it seemed to work really well over the upgrade screens. I also added the wind noises from the planet ambience in here too.

6. Title Theme
I quite liked this being underplayed as well so stuck to just using the ‘planet ambience’ here with a bunch of samples of the ‘bell’ sounds from the ‘upgrade theme’ triggered randomly (all part of the same minor scale though so not entirely random). Again this has a kind of ‘vintage sci-fi’ feel which I liked. I also added spot fx for ui actions on the menu.

Now that I’ve written all that up it seems like rather a lot of work so I don’t feel quite so bad about it taking eight days or so to complete – bearing in mind I had to code all these into the game as well and managed to fix a couple of other bugs whilst I was at it. I’m bloody glad to be moving on from it though…

Dev Time: 8.5 days
Total Dev Time: approx 109 days

previous | next

mockup_3x
And This Is After I Sorted Things Out…

mockup_3x
The Original Loop – Way Too Loud For The FX!

mockup_3x
Main Theme – Jetboard Joust / Battle Snake Mash Up

mockup_3x
The Baiter Theme – High Tension Using Original Loop

mockup_3x
Upgrade Theme – Minimal And Spooky

mockup_3x
Main Menu And Planet Ambience
Advertisements

Jetboard Joust Devlog #30 – Crossed Platforms

Porting From Mobile To PC with MonoGame
This week I was supposed to have started on the initial gameplay testing for Jetboard Joust but I came up against a rather nasty snag.I develop using Xamarin Studio on a Mac and had been using the GenyMotion Android emulator for my main testing platform. This probably seems strange given that my main target platform is PC, but GenyMotion generally runs extremely well and I don’t want to have to buy another machine just for development purposes. Unfortunately I discovered a problem with GenyMotion in that it seems to just ‘miss’ some keyup/keydown events. The problem is intermittent but bad enough to make serious gameplay testing on the platform impossible – no response from their support either.

That means I need another platform for testing. The iOS simulators are hopeless for graphics performance (and don’t respond to keyboard control as far as I’m aware), Google’s stock Android emulators take an age to launch/install builds and the Xamarin Android Player, though fast, is still pretty flaky. That left Xamarin.Mac as the only ‘native’ Mac option but there’s a hefty additional licence charge for that (or at least there used to be – I couldn’t quite work out what’s going on with Xamarin.Mac since the Microsoft buyout).

As a result of this tragic state of affairs (remember when Apple used to take x-platform development seriously in the initial OSX days?) I decided the only option would be to ditch Mac native and move to running Windows under VMWare Fusion (at least for any development that requires serious gameplay testing). Quite a change. I’ve done this before for ‘Attack Of Giant Jumping Man’ though so was optimistic that it should be a workable solution, plus I’d have to do the PC port anyway at some point – may as well get on with it.

So I started with a brand new Windows 8.1 VM and a fresh installation of Visual Studio 2015. I’ve been using MonoGame 3.2 up to this point but this was as good a time as any to update to 3.5. Installation of the various components was a breeze. I chose the DesktopGL target as it was most similar to the target I’d worked on for ‘Attack Of Giant Jumping Man’ (so hopefully the few bits of platform-specifc code I’d had to write could be re-used) and it didn’t take too long to get my project to compile. The only problem I ran into was that references to the Microsoft.Xna.Framework.GamerServices namespace couldn’t be resolved. For some reason the reference to the assembly that contains these wasn’t included in the MonoGame template project and had to be added manually (Add Reference->Extensions and then choose the appropriate MonoGame.Framework.Net assembly for the platform you are targeting, its a bit confusing as all the assemblies are named the same in the list so you have to click on each one to see more info).

I’m using the ‘shared folder’ feature of VMWare Fusion to share my source code directory between Mac and Windows – if I import the source files as links then both my Xamarin Studio projects on MacOS and my Visual Studio projects on windows both remain perfectly in sync – nice!

Next step is to import all the content – unfortunately I can’t figure out a way to keep all these files in sync as importing a file as a link from a shared folder doesn’t seem to work in the MonoGame pipeline tool. This is a bit of a bummer but not to much of an issue at the moment – hopefully I can figure something out eventually.

Only issue with the content was that I was getting an error when compiling my custom shader files due to a missing DirectX component (‘d3dcompiler_43.dll’) despite having DirectX 11 installed. I followed the instructions to fix this here (using the second method, not the full install) and all was fine.

So now everything would compile and run. Imagine my joy when, on launching, all I got was the garbage you can see in the GIF on the right. Complete gobbledegook. Spirits totally crushed. What. The. Hell.

I had absolutely no idea what was going on here and no idea where to start debugging. Nothing I thought of initially had any effect. Jetboard Joust runs on MEAT, my own (originally Java-based) 2D gaming platform that has been over ten years in development. MEAT is another layer of abstraction above MonoGame and fairly complex making it difficult to strip things down to MonoGame basics and do a few simple tests but this is clearly what I needed to do.

I decided to run a few simple MEAT tests first and see if I could get anything up and running…

1. Load image and draw sprite
2. Load image and draw sprite with clipping (as if from sprite sheet)
3. Load image and draw sprite with crop (MonoGame ScissorRectangle)
4. Load image, render to offscreen buffer (RenderTarget2D) and then to screen.

…all of these worked fine which was encouraging to an extent but didn’t get me any closer to a solution. However the next test produced some very strange results.

One of the MEAT classes is a graphical font class – a bitmap font and associated metrics data are stored in a single file which can be used to easily render bitmap text to screen. When I tried a test render using one of these graphical fonts the text would appear OK and then mysteriously disappear after around 30 seconds on screen. Bizarre. This mysterious disappearance only happened when my game template code (that handles all the main menus and stuff) had been executed at startup, ie at least 30 seconds before the problem occurred.

So all I could do was to comment out chunks of the game template code, launch the app, and then run a timer for approx 45 seconds to see if the font disappeared – an incredibly tedious process reminiscent of debugging on J2ME handsets. Eventually I narrowed it down to the line of code that was causing the problem – I was reassigning the property originally assigned to the graphical font that was drawn to screen to a different graphical font. Even though this was a mistake on my part there is absolutely nothing ‘wrong’ with this and it wasn’t causing a problem on any other platform. I had to test and retest several times to convince myself that this line of code was the problem but it was – as soon as I didn’t reallocate the property once the font was drawn to screen the test font didn’t disappear and the entire game ran perfectly!

All I can think of is this had something to do with garbage collection of graphics memory. Reallocating the property meant that the garbage collector (incorrectly) thought the memory should be freed which resulted in some kind of graphics meltdown. This would explain why it took around 30 seconds for the problem to appear – it only happened when the garbage collector kicked in. I create the font images using Texture2D.FromStream() rather than the Content.Load() methods in MonoGame which is slightly weird and could be something to do with it as well – I doubt this is as well tested as the Content.Load() methods.

Anyway, one can’t really blame the MonoGame team for missing such an obscure issue and even with the amount of time I wasted over this it was still a pretty fast cross-platform port so kudos to them. Android/iOS to PC in around a day with about 99% of the codebase consistent – not to be sniffed at! Nice to see the issues with the XBox controller fixed in MonoGame 3.5 too!

Dev Time: 1 days
Total Dev Time: approx 32.5 days

previous | next

mockup_3x
Where On Earth Do You Start To Debug This Shit?

Got There In The End – PC, Full Screen, XBox Controller

Animated GIFs of Gameplay Footage for Twitter on Mac OSX

I’ve been asked how I do this a few times on Twitter so thought I’d write a post about it. Haven’t done a ‘tutorial’ style post in a while. My bad.

Posting animated GIF images on Twitter is a very good way to get retweets and likes and build awareness of your game, but if you’re using a Mac there aren’t that many tools out there for the job. Most people seem to use GifCam on PC but there doesn’t seem to be a Mac equivalent.

In a nutshell I use Apple’s Quicktime Player to screen capture followed by a process in Photoshop to crop and convert to animated GIF. I tried a bunch of different tools and processes before deciding on this as by far the best way.

Make your GIFs 506 pixels wide by less than or equal to 506 pixels tall so that Twitter doesn’t resize them and make them all blurry (especially important for pixel art).

Photoshop has a stupid 500 frame limit for animated GIFs but you’ll probably hit Twitter’s 5mb size limit before this becomes a problem. It is, unfortunately, a problem sometimes though.

So, in detail…

1. Decide On An Emulator
I’m developing cross platform with Xamarin/MonoGame and have found by far the best emulator to use is GenyMotion for the Android platform. I use this for general development and for all screen capture. The iOS emulators are way to slow and grabbing video direct from iOS device is also too flakey and produces too many compression artefacts. The GenyMotion emulator is very fast and can be reliably run at 1:1 ration for pixel art – only downside is that the 1:1 function requires a ‘paid for’ licence.

Xamarin’s free Android Player is pretty good but at the time of writing there are bugs in the handling of key events which means I can’t use it for my purposes.

2. Capture
I use Apple’s Quicktime Player for this. I was using Snapz Pro but it only seems to capture up to 30fps. To screen capture from Quicktime Player just click ‘done’ on the first dialog that pops up then go to File->New Screen Recording. From there it’s self-explanatory.

3. Edit
This step is optional as you can do it in Photoshop. I find it much easier to crop the video to the section I want using Apple’s outdated but incredibly useful QuickTime Player 7 Pro. This is another paid app I’m afraid but it really makes the process a lot less painful.

4. Import Into Photoshop
Open your video in Photoshop and crop it to size. You can ‘scale up’ later when saving as a GIF so you could crop to 50% of your final size (or even less). This can look good for pixel art. Then I do the following procedure…

5. Adjust Colour Profile
– Edit->Assign Profile->Generic RGB Profile
Your mileage may vary on this but I find that screen captures from Quicktime always seem too dark when importing into Photoshop. This alleviates that issue to an extent.

6. Create Layers
Open the animation window (Window->Animation) and in the menu at the top rioght of the animation window select ‘Flatten Frames Into Layers’. This may take some time. Once this is done select the original movie layer (it will be the bottom layer in the layers palette) and delete it.

7. Create Frames
Back to the animation window menu now – this time select ‘Make Frames From Layers’.

8. Save As GIF
You are now ready to export your animation. For some reason I’ve found that Photoshop often does something weird with the first frame, like it’s assigned a different colour profile or something. You can check this by moving the timeline marker in the animation window and seeing if everything looks OK. If it doesn’t you can more the ‘start’ marker to just beyond the problem frame (you can also use these start/end markers to crop the timeline if you didn’t edit your video as described in step 3).

Use ‘Save For Web’ to export and you will have to mess around with the colour settings to get your animation under 5mb. Even if your image contains no transparency keep ‘transparency’ checked as without it file size jumps up dramatically (maybe photoshop uses this to only update areas of each frame that change). Note that you can scale up your image at this point – be sure to select ‘Nearest Neighbour’ scaling for pixel art.

I’ve found that the ‘loop’ setting keeps getting set back to ‘once’ when other parameters are changed so make this the last thing that you do. Changing colour options and the like can result in a lengthy ‘beachball of death’ depending on the size of your GIF so when you see this don’t panic just wait it out.

It’s easy to set up a Photoshop Action to cover steps 5 through 7.

That’s it. Any questions or comments please contact me here or on Twitter.

Playing MP3 Background Music In MonoGame Windows

The process of porting ‘Attack Of Giant Jumping Man‘ to Windows Desktop has been generally painless. One of the things that has given me the most issues though has been getting MP3 background music to play correctly. For some reason the WindowsGL version of MonoGame doesn’t support MP3 files as XNA Song objects to play via MediaPlayer.Play().The solution, as usual with these kind of issues, is to go native. Unfortunately just doing something as simple as playing an MP3 file on Windows is much more convoluted than would seem necessary if you want to avoid including additional dependencies (DirectX, Windows Media Player etc) into your project.

So, here’s some code that will play MP3 files without the need for additional dependencies by hooking into the winmm.dll. Import your MP3 resources using the MonoGame pipeline tool and just set to ‘copy’ with no pre-processing. Code could probably do with tidying up a bit but it works!

#region Using Statements
using System;
using System.Text;
using System.Runtime.InteropServices;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Media;
using Microsoft.Xna.Framework.Input;
#endregion

namespace com.bitbull.meat.platform.windows
{
    public class WinmmMp3MediaType
    {
        [DllImport("winmm.dll")]
        private static extern long mciSendString(string lpstrCommand, StringBuilder lpstrReturnString, int uReturnLength, int hwndCallback);
        private string filename;
        private string command;
// Expects a name like 'yourfile' WITHOUT an extension (just for consistency with Content.Load)
// Expects files to be stored at root of Content directory with no pre-processing 
        internal WinmmMp3MediaType(string name)
        {
            filename = "Content/" + name + ".mp3";
        }

        internal override void Play(int loopcount, float volume)
        {
            StringBuilder retvalue = new StringBuilder();
// You need to stop and close and currently playing files otherwise it doesn't work properly
            command = "stop Mp3File";
            mciSendString(command, null, 0, 0);
            command = "close Mp3File";
            mciSendString(command, null, 0, 0);
            command = "open " + "\"" + filename + "\"" + " type MPEGVideo alias Mp3File";
            mciSendString(command, retvalue, 0, 0);
// I've commented out the code for setting the volume as it's specific to the way I do things but basically this command expects an integer between 0 (min volume) and 1000 (max volume) 
            // float master_volume = MEAT.Platform.MediaInterface.MusicVolume / 100.0f;
            // mciSendString(string.Concat("setaudio Mp3File left volume to ", (int)volume*master_volume*1000), null, 0, 0);
            // mciSendString(string.Concat("setaudio Mp3File right volume to ", (int)volume*master_volume * 1000), null, 0, 0);
            command = "play Mp3File";
            if ( loopcount<=0 )
            {
                command += " REPEAT";
            }
            mciSendString(command, retvalue, 0, 0);
        }

        internal override void Stop()
        {
            command = "stop Mp3File";
            mciSendString(command, null, 0, 0);
            command = "close Mp3File";
            mciSendString(command, null, 0, 0);
        }
    }
}

Going Full Screen In MonoGame Windows

One of the things that caused me some issues when porting ‘Attack Of Giant Jumping Man‘ to Windows was getting the game to run full screen at the correct resolution.

Unfortunately the MonoGame calls that should return the dimensions of the primary display don’t seem to work correctly on all hardware. My system was OK (a Mac Pro running Windows 8 via VMWare Fusion) but on @PVBroadz Surface Pro 3 MonoGame would, for some reason, insist the primary display was only 720 pixels wide.

My solution to this was to use native calls to return the width and height of the primary display, the following in my Game.Initialize() method seems to work just fine when placed after baseInitialize()…

GraphicsDeviceManager.PreferredBackBufferWidth = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width;
GraphicsDeviceManager.PreferredBackBufferHeight = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height;
GraphicsDeviceManager.IsFullScreen = true;
GraphicsDeviceManager.ApplyChanges();

…don’t forget to add a reference to the System.Windows.Forms dll!

Windows Phone Development On A Mac With MonoGame

This week I have been porting ‘Toss The Floppy Frog’ (my first Android and iOS title with MonoGame) to Windows Phone 8 – and it has been painful. Very painful. So painful that I though I’d write a simple step-by-step guide to the process of porting iOS and Android MonoGame titles to Windows Phone. Hopefully this will ease the pain for others.

Part of the suffering has, no doubt, been due to the fact that I am a complete Windows noob. I have been developing on a Mac since around 1995 and have barely touched a Windows machine since then – I even wrote my own JavaME emulator (running on J2SE) so I could do JavaME development on a Mac! Windows, and all its terminologies and conventions, is very much uncharted territory for me.

The largest chunk of pain has, though, been due to what are in my opinion three key deficiencies in the Windows Phone implementation of MonoGame. These are…

1. The Project Templates Are Broken
The MonoGame project templates provided with the 3.2 install don’t work with Visual Studio 2013 (which is the latest version at the time of writing). I don’t know about previous versions. The basic template doesn’t launch the game correctly and doesn’t get to the ‘cornflower blue’ screen we so long for. No errors are given, it just doesn’t work. This issue caused me around half a day of tearing hair out before I found a post on the MonoGame forum that gave a solution (see the ‘step by step’ guide below). If these templates could be fixed I’m sure it would save a lot of developers a lot of grief and avoid casting MonoGame in an unnecessarily bad light.

2. The Content Pipeline Requirement Sucks
I understand the requirement for a content pipeline, really I do. Optimising your assets for use on different platforms is a great idea, but it should be exactly that – part of the optimisation process, NOT a requirement for getting a basic game up and running. The fact that ‘raw’ image and sound assets can’t be loaded in the Windows Phone implementation of MonoGame but can in the Android and iOS versions kind of makes a mockery of the whole ‘Write once, play anywhere’ mantra. Many developers (myself included) will have games that run perfectly fine without the need for content pipeline optimisations and the requirement to use one is just an unnecessary barrier to ‘getting stuff done’.

3. The Content Pipeline Itself Sucks
I couldn’t get any of the MonoGame content projects to load correctly in Visual Studio 2013 and I was unable to find any information online as to how to get the Monogame content tools to work correctly without these. the MonoGame content tools were completely useless to me. Fortunately someone on the MonoGame forums pointed me to an open-source XNB compiler that I was able to edit (ie hack) to convert all my assets to XNB (see the ‘step by step’ guide). That’s at least a day of pain right there. Frankly, if I hadn’t have been pointed to this tool I probably would have given up (and I hardly ever give up).

Now I have the greatest respect for the MonoGame project and team – they have given and continue to give their time for free to provide an awesome product for the IndieDev community. The criticisms above are given in the hope that these areas of MonoGame will be improved which will lead to more developers adopting the platform and more fun/revenue for all of us. Hopefully they’ll be taken in that spirit.

And, once you’ve got past the pain, there is one gigantic plus to all of this, and that is…

100% code re-use!!

Yes, you read that right. Once I was able to iron out a couple of quirks I was able to get 100% resuse of my game code across Android, iOS and Windows Phone. That’s pretty much the holy grail of cross-platform coding and an extremely big upside! The only platform specific code is in the app-launcher stubs and about three lines in my image loader. Nice.

So, without further ado, on to the step by step guide to porting iOS/Android MonoGame titles to Windows Phone using a Mac…

1. Prepare Your Code For Windows Phone
If, like me, you’re more familiar with a Mac and Xamarin Studio than Windows/Visual Studio it’s easiest to get this out of the way before you even touch Windows. Here are the issues I came across:

System.Collections.Hashtable is not available on Windows Phone.

References to this class can be replaced easily by references to:

System.Collections.Generic.Dictionary<Object><Object>

Note that there is a slight ‘gotcha’ here in that Hashtable will return null when trying to retrieve a value for a key that doesn’t exist whereas Dictionary will throw an exception. Your code may need to be altered to account for this.

System.Collections.ArrayList is not available on Windows Phone.

References to this class can be replaced easily by references to:

System.Collections.Generic.List<Object>

System.Runtime.Remoting package is not available on Windows Phone.

If you use this package you will have to work around this somehow. I was using it for dynamic class instantiation and could quite easily replace it by hard-coded calls to instantiate the relevant classes.

The following MonoGame properties return incorrect values on Windows Phone:

GraphicsDeviceManager.PreferredBackBufferWidth
GraphicsDeviceManager.PreferredBackBufferHeight

GraphicsDevice.DisplayMode.Width
GraphicsDevice.DisplayMode.Hight

If you are using any of these to get display width/height the following alternative seems to work:

GraphicsDevice.Viewport.Bounds.Width
GraphicsDevice.Viewport.Bounds.Height

Texture2D.FromStream() is not implemented in MonoGame for Windows Phone.

Bummer. If you are using this (as I was) you will have to work around it. I caught the System.NotImplemented exception and loaded the relevant asset(s) using the content manager instead. I really hope this gets implemented soon as it’s an important function.

Assets are loaded without the file suffix.

On Android/iOS you will probably be using something this:

Content.Load(“myimage.png”)

to load assets which will have to change to:

Content.Load(“myimage”)

on Windows Phone. Ideally write code that catches the exception and tries the alternative method if the first attempt fails.

2. Install Some Kind Of Virtual Machine
You probably want either VMWare Fusion or Parallels. I used Fusion which seems OK though it took quite a bit of farting around to get the ‘shared folder’ feature (which allows you to access files on your ‘host’ mac from the ‘guest’ PC) to work.

3. Set Up The Virtual Machine And Install Windows
Set up an x64 virtual machine and install a 64bit version of Windows otherwise the Windows Phone emulators won’t work. I’m still running a 32bit version of Windows which means I have been unable to launch the emulators so far – I’ve been using an actual device for testing. I believe it must also be the ‘pro’ version of Windows in order for the emulators to work.

4. Install Visual Studio 2013 Twice(!)
From here. You want both the ‘Windows’ version (for Windows Phone) and the ‘Windows Desktop’ version (for the content pipeline stuff). Fortunately both will reside happily side-by-side (unlike my children).

5. Install MonoGame 3.2
From here. May well have been updated since this was written.

6. Install XNA
You will need this for the content pipeline stuff. Follow the instructions and use the PowerShell script kindly provided here.

7. Install Windows Media Player
If it’s not there already – some versions of Windows install it by default, some don’t. You’ll need it for audio processing in the content pipeline and it can be downloaded from here.

8. Set Up A New MonoGame Solution
Launch Visual Studio for Windows and choose the ‘MonoGame Windows Phone’ project template uncder ‘Visual C#’ templates. If it’s not there you need to check MonoGame has installed properly. Call the project something sensible (e.g. the name of your app) and save it anywhere.

9. Update The MonoGame Packages
This is necessary to fix the broken MonoGame template issue and must be done with a solution open in Visual Studio. Launch the NuGet console under Tools->NuGet Package Manager->Package Manager Console and type in the following:

PM: Install-Package MonoGame

This will update the template. It asks if you want to overwrite a few files – click ‘yes’ to each one but ‘no’ to ‘Game1.cs’ as this file will have been altered to reference your app’s namespace.

10. Check For ‘Cornflower Blue’
Now you have done this you should be able to build/run the project and get our old friend the ‘cornflower blue’ screen on your chosen emulator or device. Well done! It took me about a day to get to this point!

11. Import Your Source Code
Having wasted a lot of time trying to get Visual Studio to reference files on my Mac I came to the conclusion that this is impossible. Unlike Xamarin Studio, Visual Studio won’t let you import files as links – they have to reside within the project directory, so the simple-but-far-from-ideal solution is to copy the files from your Mac to the host PC and import. Note that you can ‘copy’ directories from within Windows Explorer and ‘paste’ into Visual Studio which I found the easiest way to import a lot of files at once.

12. Compile Your Source
Hopefully if you followed the suggestions in step one your source just compiles at this point. If not you will have to fix any errors, unfortunately I can’t tell you what these might be as I covered everything I came across in step 1!

13. Convert Your Content To XNB
This should be possible just by using the MonoGame tools but I never succeeded. I had to download an open-source XNB compiler tool from here, open in Visual Studio Desktop, then compile and run to convert my files. It works OK, but the tool only appears to allow you to add one file at a time. Thankfully it was fairly easy for me to modify the code to allow all files in a directory to be added and I’ve included my edited source here. The tool successfully converted PNG, JPG and WAV files for me. If you get an error regarding a missing .dll whilst trying to covert audio you probably need to install Windows Media Player as described in step 7. Whilst MP3 files seem to convert OK I haven’t managed to get them playing correctly yet but I will update this post if and when I do.

14. Import Your XNB Files Into Visual Studio
These go in the ‘Content’ directory exactly as you’d have them organised for iOS or Android. Once imported select the files and under ‘properties’ set ‘build action’ to ‘content’ and ‘copy to output directory’ to ‘copy always’.

15. Change The Template Code To Start Your Game
In Visual Studio find the GamePage.xaml file. Click the little disclosure triangle next to it to reveal GamePage.xaml.cs. Edit this file to replace references to the Game1 with references to your Game class.

16. Run Your App
Congratulations, assuming you followed the tips in stage 1 about loading assets your app should now run on device or emulator. It took me almost three days to get to this point!

I hope this guide is of help to someone – any suggestions for improvement just let me know!

Toss The Floppy Frog – Feels Like My Life’s Work


cornflower
Not Since Yves Klein Has A Blue Square Seemed This Exciting

floppy
At Last – Frog Tossing On Windows

Creating App Promo/Demo Videos With Adobe Premiere

One of the things I’ve had to do with Floppy Frog is create a promo video for uploading to YouTube. I’ve made many promo videos for my JavaME apps and games but these were very simple and I’ve never had to do them in a YouTube-friendly format.

I used to use iMovie for promo videos until Apple changed it from a very simple, flexible and useable tool into the pile of arcane, prescriptive and utterly useless garbage that it is now. For the last few years I’ve been using Apple’s Quicktime 7 pro which, ironically, was much more suited to task than the ‘new and improved (read ‘ruined’) iMovie.

But, Quicktime 7 Pro was not going to cut it (pun intended) for this task so I decided to try Adobe Premiere. Overall I found it a good application for the task in hand though getting the settings right was somewhat time consuming, I’ll therefore detail the process here.


1. Capturing The Video

I thought initially that I’d capture video from the iOS Simulator. Bad idea. It runs much too slowly. Next attempt was to run Floppy Frog on the iPad and capture using Reflector as an Airplay Receiver. Again, bad idea. Frame rate was OK but quality wasn’t up to scratch.

Third attempt was to run the Android version of Floppy Frog using the GenyMotion emulator and capture using the excellent Snapz Pro. Success! GenyMotion runs Floppy Frog just as fast as it would on device and Snapz Pro is a highly configurable and useable screen capture tool. It even captured the audio without a hitch. Had to purchase the full version of GenyMotion to get rid of the ‘free for personal use’ message but I don’t begrudge them that as it’s a fantastic piece of software at a reasonable price.

GenyMotion also has the benefit of being able to configure device display height/width so you can set up a virtual device that’s ideal for the video format you want to capture. In this case my video will run on YouTube at HD 1280*720. Floppy Frog is a portrait game so I wanted a device size that wouldn’t look too ‘squished’ within the HD landscape frame, therefore I set up a virtual device of 600*720 and captured at this size at 30fps which is the frame rate at which the game runs.


2. Import The Video Into Premiere

You’d expect this bit to be easy, and it is easy to simply import the captured video into Premiere. Where I ran into difficulties was that Premiere organises all video into a ‘sequence’ and setting up a ‘sequence’ that matched my video capture settings seemed impossible. All I could do was choose from a series of preset sequences and changing the preset sequence settings was not allowed for some reason. The key issue was that none of the preset sequences ran at 30fps, only 29.97 fps and when Premiere attempted to match my 30fps captured video to the 29.97 sequence settings I was getting horrible interlacing effects.

The solution was to start the Premiere project with any old sequence settings, import the captured video, then select the captured video and choose ‘New Sequence From Clip’. This creates a new sequence matching the captured video settings exactly. Only issue was my video was captured at 600*720 and I wanted a video running at 1280*720! Solution: capture a few seconds of random 1280*720 30fps video using Snapz Pro, import into Premiere, then create the sequence from this. The 600*720 video can now be dragged into this new sequence no problem and the 1280*720 capture can be deleted from the project.

Next issue (which most people probably won’t run into) is that my sound hardware runs at a 48khz sample rate whereas my video was captured at a 48khz sample rate. For some reason Premiere seems pretty flaky about converting between the two (whatever the project Audio settings) so I had to make sure my captured video was saved with the audio running at a 48khz sample rate.

3. Export The Video For YouTube

Once the video is comped together in Premiere it has to be exported at high-quality for uploaded to YouTube. I got and tweaked ‘export media’ settings from a YouTube tutorial and they might be slightly overkill quality-wise but I’ve added screenshots on the right…

4. Sit Back And Watch The Traffic Roll In

Or maybe not. But here’s the finished product anyway…

premiere_vid_youtube
Adobe Premiere YouTube Video Export Media Settings.

premiere_audio_youtube
Adobe Premiere YouTube Audio Export Media Settings.

Floppy Frog – Don’t Flap, Hop!

Recently it has become abundantly clear that the JavaME platform, from which I’ve been deriving a living for more than ten years, is no longer going to be viable platform for a mobile gaming company to support, let alone rely on for a main income stream.

In Spring this year I decided to take the plunge and port all of my library code to Xamarin/Monogame so that, going forward, I can (in theory) develop across the Android, iOS and WinPho platforms with pretty much a single codebase.

There were a number of reasons for choosing Xamarin over other cross-platform solutions such as Marmalade, but the key one was the ability to code in C# which would make the porting of my extremely large (you may read ‘bloated’) existing codebase significantly easier.

I can’t say the process has been easy – there has been much weeping and gnashing of teeth, but overall I am pleased with the Xamarin/Monogame solution. The ‘single codebase’ promise is working out in practice and I find C# a great language to work with.

My first game built ‘from the ground up’ for Monogame has just been released on the App Store and Google Play. Floppy Frog is a deliberately challenging endless jumpy platformer inspired by the likes of Frogger, Flappy Bird, Doodle Jump and Paper Toss, though without being a ‘clone’ of any of these. It’s available for free, currently monetized with AdMob ads. The game is very simple but I’m very pleased with it.

Give it a go – download for iOS or Android. Any positive reviews/ratings are of course much appreciated!