Tag Archives: gamedev

Jetboard Joust Devlog #100 – Die and Try Again!

This blog should really have been Configuring Things Out pt. 2 but I thought ‘Die and Try Again’ was more appropriate really.

Now all the enemies and weapons are finally done I’ve been going back over the game worlds, playtesting and (re)adjusting all the various character/weapon stats and levelling rates. The only way of balancing the weapons is to simply play the game a lot, and if I feel I’m either avoiding particular weapon because it’s too weak, or that I’m constantly gravitating towards a particular weapon because it’s too overpowered, I tweak the stats as appropriate. It’s been a very time consuming process and I have to say I’ve been at something of a low ebb whilst doing it.

Unlike fixing a bug, you don’t ever get to the point where you think something is ‘done’, and I know I’m going to have to go through this whole process again at least one more time to refine things further before the game is complete. It’s really getting to me now.

The thing that’s made this phase so much tougher than the first configuration ‘pass’ is that I’ve been through every single boss and mini-boss fight in the first four worlds and attempted to adjust the difficulty for each. There are over fifty of these and, by nature, they are supposed to be tough, so this entails a *lot* of failure both in terms of dying in-game and in terms of setting the difficulty level either too easy or too hard.

Most of these challenges are mini-boss battles featuring the Guardian enemy and a new weapon unlock or upgrade. To maintain a certain amount of narrative ‘flow’ (and to stop me being lazy) I’m having the enemies guarding the unlocks armed with the same weapon they are protecting. The strength of the enemy is heavily dependent on the strength of the weapon, therefore a tweak to the stats of said weapon (because I think it’s too weak or too strong in-game) has a knock-on effect in every single battle that features it. It’s a cyclical process and one that I’m starting to think could go on forever, like painting the Forth Bridge. On a good day though I see it more as a kind of gradual ‘whittling down’ with every pass getting me nearer to the ideal balance.

It also makes a difference what weapons are available to the player during these battles. I was choosing these weapons completely randomly (but based on a consistent seed) though towards the end of the process I realised this wasn’t working and I needed a better balance of weapon choices. Consequently I’ve divided the weapons into four categories – long range, short range, wide range and explosive, and I make sure a balance of weapons from each category is chosen. I think I may ditch the consistent seed as well so each time you enter a level the weapon choice is a lottery, albeit a balanced one.

There’s also been a myriad of bugs and other gameplay tweaks I’ve made along the way though at this stage I’m trying to restrict myself to fixing bugs/tweaks that actually affect the balance of gameplay and noting everything else down on Trello cards for later attention. There’s currently around fifty of the Trello cards (groan) and there’s at least another ten things I haven’t noted down yet!

I’ve also been back through the first four major boss fights and made a proper attempt to balance the difficulty of these with the (rough) stats the player should have achieved by that point in-game. If you’ve been following this blog you’ll remember how much time I’ve spent on these boss fights already, so it’s been doubly demotivating having to go back to them, debug them again, run through the fight procedure again and again AND again whilst discovering yet more bugs and issues that need fixing. On a positive note though, it’s been nice to revisit them in different colour palettes.

Lastly, and I know this is going to sound like archetypal first-world moaning, I’ve been surprised how physically exhausting this process has been. Basically playing (often ludicrously difficult) boss fights for eight hours a day for eight or nine days straight takes its toll. I try to be as careful as I can be about posture but my shoulders ache, my wrists and elbow joints ache, and my back is fucked. Yes, I know it’s not exactly working down a mine, but being physically in pain doesn’t do wonders for one’s motivation. I can’t wait to finish this game and take a break from this shit.

Oh yeah – one thing that’s kept me going through this process is the fact that I can just turn the game sound off and listen to music. I’ve finally succumbed to subscribing to Spotify and have been listening to a lot of Tangerine Dream. Strange coincidence – I finally got round to watching Netflix’s enjoyable Bandersnatch interactive movie at the same time and what does that feature? A ZX Spectrum game developer slowly going insane trying to finish a game whilst listening to lots of Tangerine Dream! Weird…

Right, on to those Trello cards…

Dev Time: 8.5 days
Total Dev Time: approx 268 days

previous

mockup_3x
The ‘Spinner’ Boss In Colour

mockup_3x
The ‘Squirmer’ Boss In Colour

R.P.G. Guardians. Die and Try Again – and Again, and Again…

Advertisements

Jetboard Joust Devlog #97 – Creepy Crawlies!

No prizes for guessing the classic arcade game that’s the inspiration for this latest enemy – yup, it’s another of Atari’s masterpieces – Centipede! Working title for this enemy is the ‘Scuttler’ (I already have a ‘Crawler‘ and a ‘Squirmer‘)!

The mechanics of this enemy are pretty simple, I thought the hardest thing to get right would be the algorithm that makes the segments ‘follow’ the head (I’ve had to right similar code in the past and got myself into a right mess) but the code I came up with, unbelievably, worked pretty much right of the bat!

There’s probably a better way of doing it but my basic approach here is to ‘remember’ the direction each segment is travelling and to continue moving in that direction by default each frame. If the total horizontal and vertical distance between one segment and the next is less than the desired segment spacing no movement occurs. If the segment aligns horizontally or vertically with the segment in front we switch orientation (i.e. from horizontal to vertical or vice versa). This seems to work well enough for my purposes but if anyone has any better ways of doing this I’d be interested to hear them as it’s a gamedev problem I seem to run into quite a bit.

Unlike the Atari Centipede I don’t have any mushrooms to run into to initiate a change of direction so I had to improvise a bit here. Changing direction when it hits buildings was an obvious one, but I also have it switch direction when it hits the edge of the screen (i.e. camera area) and, with a certain amount of leeway, when it aligns with the player on the opposing axis. This approach seems to maintain an authentic ‘Centipede’ feel whilst working within the confines of the Jetboard Joust gameplay.

I also added a slight ‘sway’ to the segments as they move as a fixed horizontal or vertical movement just seemed too ‘static’ in context even though it would have been truer to the original game. I want to tip my hat to these classics rather than slavishly replicate them.

Of course I also had to have the centipede splitting into two when it’s health is reduced which means things can get pretty manic (in a good way, though I’ve toned it down a bit since this video as things were getting too out of hand too quickly).

I’ve also been working on a Centipede style retro arcade palette but have been running into a few issues trying to get this to look good across all sprites. The red outline you can see is used on some of the sprites in the original arcade game. I like the way it looks here as I designed the sprite around it but it looks terrible on many of the sprites I’ve already designed so I think I’m going to have to use a more generic approach. If I ever make another game I’m going to make sure I treat my outline colour as a completely separate part of the palette – lesson learned!

Dev Time: 2 days
Total Dev Time: approx 253.5 days

previous

mockup_3x
Close Up Of The Scuttler – Centipede Tribute Palette!

Jetboard Joust Devlog #1 – Overall Art Style

Looking back at my (frankly rather awful) ZX Spectrum title ‘Skateboard Joust‘ reminded me that there was always something pretty decent in the core gameplay concept of using your flying skateboard as a weapon when mid-jump.

As I need something else to work on whilst development on ‘Attack of Giant Jumping Man‘ slows down (hopefully temporarily) I thought about revisiting ‘Skateboard Joust‘ – almost as a penance for my sins in bringing such a dreadful game into the world into the first place! Maybe I can make a half-decent sequel and bring my gaming karma into alignment somehow?

I think I could get this mechanic to work as a simple two-button ‘endless scroller’ which might be nice for mobile and possibly even PC so I’ve been working on some visuals for the game with a view to making a prototype at least.

I’ve been going for a retro look in keeping with the game’s heritage, but rather than going for a full-on Spectrum emulation I’ve decided to keep to simple, restricted Gameboy-ish colour palette which I may change as the game progresses. The result is somewhere between Gameboy and Spectrum.

Game art is not my strongest suit and always takes me ages. I’d much rather be working with @PVBroadz but it this instance I need something I can crank out on my own. Pretty pleased with the result so far though – feel free to tell me what you think.

Dev Time: 2.5 days.

next


mockup_3x

Have I Got Any Better At Pixel Art In The Last 30 yrs?


mockup_3x

Test Animation For The Main Character


mockup_3x

Retro Revenge – Click For A Closer Look

Updating Legacy MonoGame Projects to iOS9 / Unified API

Just the moment you long for. Apple releases a new iOS update and that breaks something in your development platform of choice (Xamarin/MonoGame in my case) and all your apps no longer work. Great. Like I didn’t have enough to do.

And as with everything Apple nowadays – any kind of update seems to break everything else thereby creating a domino effect of pain and tedium as you wait for gigabytes of data to download over a shitty rural broadband connection. Oh, the joy!

So, without further ado here’s how to update your legacy MonoGame projects to iOS9 and the Unified API. Hopefully this will make life a little easier for someone.

If you have a crappy broadband connection buy a copy of ‘War And Peace’ or something suitable to keep you occupied.

If you’re running an OS earlier than Yosemite update to El Capitan. You’re going to have to unfortunately. You’ll need XCode 7 and that only runs on Yosemite or later. Apple aren’t big on backwards-compatibility these days.

Update to XCode 7.

Update everything Xamarin-related to the latest version. I’m currently running Xamarin Studio 5.10 which at the time of writing is on the alpha update channel. I was getting some issues with creating archives using the current ‘stable’ release.

Update any additional components you are using to the latest version – for example I was using the Xamarin Google AdMob component. Make sure to add the ‘unified’ version.

Open the solution you are updating and try to build it – you may get the following error:

/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets: Error: Error executing task DetectSdkLocations: Unknown TargetFrameworkIdentifier: .NETFramework

Remove the references to monotouch and OpenTK from your project and instead add references to OpenTK-1.0.dll and Xamarin.iOS.dll (these are visible under the ‘all’ tab when you go to edit references).

Try and build the project again. You will probably get a shedload of errors to do with it not being able to find the MonoTouch namespace. Just get rid of all references to MonoTouch, ie replace ‘using MonoTouch.Foundation;’ with ‘using Foundation;’ or ‘using MonoTouch.UIKit;’ with ‘using UIKit;’ etc.

Depending on how many of the native classes you referenced you may have some additional work to do here, probably involving changing ‘float’ references to ‘nfloat’. Hopefully you’re not referencing too many of these as the whole point of MonoGame is that we avoid the native classes if possible (I just had to change some of my ad-serving code).

Hopefully your code should now compile and the only remaining errors (if any) are due to an outdated MonoGame, for example:

Error CS0012: The type `MonoTouch.UIKit.UIImage’ is defined in an assembly that is not referenced. Consider adding a reference to assembly `monotouch, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065′ (CS0012)

Download and build the latest version of MonoGame from the Develop branch on GitHub. At the time of writing there are issues with the latest ‘stable’ build of MonoGame (3.4) with iOS9 so you will need the version from the Develop branch. Change all the MonoGame references in your project to the latest versions.

Hopefully you should now get an error free compile, however you may get something like the following:

Error MT0073: The minimum deployment target for iOS is 5.1.1 (current deployment target is 4.2). Please select a newer deployment target in your project’s Info.plist. (MT0073)

To resolve this simply change the deployment target of your iOS project to 5.2 (note: this setting is now in the info.plist file).

Try and compile again. Most likely you will now get the following errors:

Error MT0016: The option ‘–nomanifest’ has been deprecated. (MT0016)

Error MT0016: The option ‘–nosign’ has been deprecated. (MT0016)

To resolve this your .csproj file needs to be changed so that it’s building using the ‘unified’ settings. Bit of voodoo required here as you will have to quit Xamarin and edit the .csproj file for your iOS project using your text editor of choice. Follow the instructions in step one of the ‘Steps To Update Manually’ section here. In short:

Change the project flavor in your csproj files from ‘6BC8ED88-2882-458C-8E55-DFD12B67127B’ to ‘FEACFBD2-3405-455C-9665-78FE426C6842’. Edit the csproj file in a text editor and replace the first item in the <ProjectTypeGuids> element.

Change the Import element that contains ‘Xamarin.MonoTouch.CSharp.targets’ to ‘Xamarin.iOS.CSharp.targets’.

You should now, finally, be able to compile and run your project on a connected iOS device. If, on launch, you get the following error:

System.EntryPointNotFoundException: alcMacOSXMixerOutputRate
at at (wrapper managed-to-native) Microsoft.Xna.Framework.Audio.OpenALSoundController:alcMacOSXMixerOutputRate (double)
at at Microsoft.Xna.Framework.Audio.OpenALSoundController.OpenSoundController () in <filename unknown>:line 0
at at Microsoft.Xna.Framework.Audio.OpenALSoundController..ctor () in <filename unknown>:line 0
at at Microsoft.Xna.Framework.Audio.OpenALSoundController.get_GetInstance () in <filename unknown>:line 0
at at Microsoft.Xna.Framework.iOSGamePlatform..ctor (Microsoft.Xna.Framework.Game game) in <filename unknown>:line 0
at at Microsoft.Xna.Framework.GamePlatform.Create (Microsoft.Xna.Framework.Game game) in <filename unknown>:line 0
at at Microsoft.Xna.Framework.Game..ctor () in <filename unknown>:line 0

You are not running the latest MonoGame build from the Develop branch as described earlier. Unfortunately MonoGame 3.4 and earlier exhibit this problem with iOS9. Update all the MonoGame references in your project to the latest version from the Develop branch on GitHub.

If you’ve made it this far without losing the will to live your app should be running on iOS9. I’m afraid to say your problems aren’t over though. Once you have built your updated app and try and upload to iTunesConnect using the Application Loader you will more than likely run into the following errors:

ERROR ITMS-90086: “Missing 64-bit support. Beginning on February 1, 2015 new iOS apps submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK. Beginning June 1, 2015 app updates will also need to follow the same requirements. To enable 64-bit in your project, we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with both 32-bit and 64-bit code.”

To fix this under Project Options->Build->iOS Build->Supported Architectures select ‘ARMv7+ARMv7s+ARM64’

ERROR ITMS-90474: “Invalid Bundle. iPad Multitasking support requires these orientations: ‘UIInterfaceOrientationPortrait,UIInterfaceOrientationPortraitUpsideDown,UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight’. Found ‘UIInterfaceOrientationPortrait’ in bundle ‘com.bitbull.flappingbird’.”
ERROR ITMS-90475: “Invalid Bundle. iPad Multitasking support requires launch story board in bundle ‘com.bitbull.flappingbird’.”

To fix this add a setting’UIRequiresFullScreen’ to your project’s info.plist file and set it to ‘YES’.

Hopefully you should now be good to go and if you got this far without topping yourself – well done! It’s not exactly the most straightforward process in the world!

Enter The Junkyard

Yeah, it’s been quiet around here lately. Ooh look – there’s some tumbleweed.

Funny old game this #indiedev business. The bottom’s (finally) falling out of the mobile Java market and, let’s face it, it’s practically impossible to make any worthwhile cash from the AppStore or Google Play due to the woeful lack of curation and avalanche of sub-prime content therein. It’s all about the marketing these days. Fine if you have the budget or are a marketeer. I’m not – I just want to make cool games.

So myself and @PVBroadz have changed tack a little and have formed Joystick Junkyard. We’re not ditching mobile but are developing quirky, high-quality ‘future retro’ titles with a focus on more traditional gaming platforms such as PCs and consoles as much as phones and tablets. We’ve just completed a playable alpha-demo of our first title – ‘Attack Of Giant Jumping Man‘.

Check out the Joystick Junkyard blog here – or follow us on Twitter here.


jj_logo_420w

Tomorrow’s Retro Games Today