Xerra's Blog

Drunken coder ramblings

The evolution of iDef —

So, almost two weeks on from the last posting, here’s where Dexterity Design are right now.

 

Aaron has stopped messing with maze testing and tinkering with asteroids to help out with my little project. He’s now neck deep in iDef code again doing the conversion into SpriteKit. This is being done because conditions can be set in Swift source code to compile certain sections of code only if compiling for a particular platform which gives all sorts of power to bring it to more people.

 

As an example Swift, at present, has the ability to develop OSX applications (not something we’ve even looked at, as yet), create IOS games (be it Ipad or Iphone / both) but the platform is now open source. This means it’s likely in future that someone will bring out exporters for Xcode to compile binaries for other platforms such as Android or Windows. I’ve touched on it before but I’m skirting over it again so I can explain a bit better about the compiler directives I mentioned earlier.

If you write a game from scratch and decide you want to use it on say both an ipad and run it on your Mac desktop then now it’s possible to do something like:-

 

#IF OSX

run code which displays the game screen in a format which is Mac friendly.

read the keyboard and process the game flow accordingly.

#EndIf

 

#IF IOS

run code to display the screen in a format which Ipads/Phones work.

we don’t have keyboard on our ipad/phone so run code which pops up the screen keyboard instead and takes input from that. Or look for touches in areas to read controls from the player.

#EndIf

 

It’s not exactly like that but it gives you an idea how the system actually works. So your one project is all you need to work from when you’re doing stuff later on such as bug fixing, adding new features, or whatever. All the specifics for each machine is handled in structures like this. A huge time saver when you don’t need to do the same fix in all of the source code for each platform. Which may or may not have been the case as each one might have been written from scratch and have different things to fix otherwise, as well.

 

Now it’s not saving you all the work because you still have to write the code that needs to be written to get it running for all the platforms but how much code would you not need to rewrite as it works for most of your project? Maths functions are a good example, as are AI routines possibly. It will obviously depend on what the game is all about and how much has to be wrapped in directives accordingly, but it’s something that will be used more and more as we go on.

 

It probably actually already has by others but I wanted to post about it as it’s pretty new to me. All those games out there that you’ve played that you know have been on mobile first don’t look much different on your flashy PC, right? Maybe because they’re reusing a lot of the code and just a different graphics engine that will work on that machine. SpriteKit will work for both Mac and IOS but not for something like Windows and it may never do that. So a different graphics system is needed for both those platforms if we release for them. And that’s still assuming that Swift does get some kind of exporter to shunt the code across even without SpriteKit.

 

As for what I’m up to then I’ll update on that later on when I’ve got a little bit further on with the project so I can go over my development process on the new language a bit better.

 

Thanks for reading and, as ever, please keep an eye on the website for updates.

Tony

 

Share your thoughts

Swift 2 – The future of IOS development. —

With iDef up on the appStore with no – aparent – bugs found as yet, Aaron and I are both looking into Swift for future development of our games. iDef was written completely in Objective C, with the use of Cocos2D as the framework for all the funky stuff.

We started tinkering with Swift in it’s V1.2 build and have now had to adjust to the shiny 2.0 that has just been released with the new XCode build. This coincides with the switch to open-source (A seriously cool decision) as well as also letting developers build to devices rather than be restricted to just the IOS simulator if they didn’t have a developer licence.

As a development team we’ve paid for a joint licence to be able to work on projects and test direct on devices but there’s no bitterness here because it was always going to happen at some point. With this change people can now write their own software and put it onto their Iphones or Ipads as they wish. Or they can even have other people link their devices to the development machine and give their work away as well. Apple obviously don’t get a sale out of this but who’s to say that the app would have gone to appStore anyway? People do develop stuff just for themselves and Apple have hopefully twigged that it’s unfair to expect that everything developed on any machine that’s been built by them should get them their slice of the pie. Common sense. You couldn’t imagine the OSX or Windows market ever surviving if there was only one store that you could get software from. Piracy concern or not.

But, I digress. Back to what we’re up to at Dexterity Design now. The new game we had in mind to start work on is still a focus point but it’s on the back burner for now, as we’re both tinkering with prototypes to work out how to use SpriteKit and Swift 2 to good effect. It’s pretty simple to knock up funky particle effect demo’s and small stuff like that, but the whole game building process with both a new language, and a framework, isn’t going to happen overnight.

So Aaron is tinkering with a simple maze-game kind of Pacman-ish – but not enough to risk being sued. And I’ve been looking at converting the last game I completed onto the iPad instead. It’s not likely we’ll throw out Aaron’s work due to the risks of legal issues but if I get Gravity Force into some kind of state where we’re both happy with it, then we might have a tinker with the appStore again and just give it away for anyone who wants to have a play. It’s mainly if we think the quality is up to scratch wether we do that or not.

The idea to do this as a starting project was because of another idea we considered, which would potentially bring iDef onto OSX at a later date. Unlike Gravity Force (which was originally written in Blitzmax just for Windows), iDef was written specifically for IOS devices and uses a proper framework for just this. So a conversion to Mac would mean a new engine for all the graphic stuff at the very least, even if a lot of the background gameplay code could be relatively easilly adapted for the big screen. Possibly the whole game could be emulated direct into an OSX window with a bit of clever coding but this would feel a bit hacky to us. And if we were looking at selling it on OSX (and potentially Windows at a later date) then it needs to be done well. We’d be opening ourselves up to the issue of piracy then, just like every other bit of software that’s ever been released, but it’s a small price to pay for possibly another slice of the pie. Demo distrubtion on it’s own could end up being a big incentive to potential buyers just for starters.

Gravity Force, on the other hand, was written in a language that can cross-compile direct to either Windows or OSX. So, when I bought myself a Mac for the first time, one of the first things I wanted to do was get the games I had written working on that platform as well. Indeed, just like the language promises, I could just recompile the project and have it running on my new machine. I put both the Windows and OSX versions up for free download in my first post of this blog as a result.

Since this I have gone back to both builds once just to fix a very minor bug and update the OSX build to work better with bigger screens. It’s not perfect even now, because I had other things to work with, but the project was developed on a crappy small screen monitor on my PC and I now work from two huge monitors with massive resolutions available to me. Originally Gravity Force was hard coded to work on 1024 * 768 only, and there was no option to rescale anything.

Naturally the fact I used to write games like this and hard code resolutions really disturbs me, now that I’m taking game development more seriously.

Where I might use something like this in Blitz:-

Graphics 1024, 768,32

Draw Image Logo, 600, 200

 

I would be more likely to use something like this in Swift:

earth.position = CGPoint(x: size.width * 0.5, y: size.height * 0.1)

addChild(earth)

 

CGPoint is the part of spriteKit which knows what device you’re running on, and what size of pixel display it has available as a result. So calculations of where to put things are all relative to that. On an IOS device the cordinates for 0,0 are also at the bottom left, rather than the top, so that also makes it more interesting to work with. Today I have been playing (and failing) with the XCode .SKS system for setting up a scene with images before doing it the old fashioned way, just like I used to do it with Blitz actually. Perhaps that’s why it made more sense.

I could also mention that I spent twenty minutes trying fruitlessly to work out why I couldn’t use a line like: Println(“Display initialised correctly”) anymore. Reading the patch notes finally told me that the command had been merged with Print now to make things easier.

Yes. Easier if you read the manual, I suppose. I’m sure there’s a lesson to be learnt here.

So, to sum up. We’re both working. More like tinkering, I suppose, but there’s some semblance of productivity, and we’re hoping for great things when we kick off on a new project. Exciting – and hopefully – productive days to come.

Thanks for reading and please keep an eye on the website for proper updates from us, rather than just my ramblings.

Tony.

You can click here to jump straight to the website.

 

Share your thoughts

iDef gets released. What’s next for Dexterity Design? —

iDef finally went on sale on the IOS store a couple of days ago which meant that, as a live project, we’ve finished actively working on it. Providing there’s no patching needed – which shouldn’t be needed due to all the testing we’ve done – then we’re concentrating now on getting it out there. The main hurdle with releasing any kind of Iphone or Ipad game now is actually getting it visible. There are so many products competing for attention on IOS that it’s really, really hard. We could have hundreds of people who would really like to buy and play the game but they’re never going to hear about it. In fact, in some ways, it’s even more work making people aware of the game than it was in the final stages of development, getting Apple to accept, and agree to sell it.

Dexterity Design is two people – Aaron and I. We’re just programmers who are adapting to the other areas of game development rather than getting other people involved, because it gives us complete creative control, which is what we need to work to our vision. We don’t have capital for marketing stuff such as magazine adverts, You Tube play-through’s, in-game adverts, web site promotions or stuff like that. The one thing we can influence is obviously social media so that’s where we have started. And for a company that’s completely unknown, iDef is our first game as a partnership, this is going to be a huge task.

Very soon we will be moving on to actual development of our next game (which is a far bigger job than iDef) and will need to concentrate on that, rather than visibility of what we have done up until now. Anything we learn from getting iDef out there is obviously vital. Of course we both knew that this is going to be a tough side of the business and we don’t expect instant success. We’re both realistic enough to know that iDef is too niche to just hit a global warm-spot with a huge market and get massive visibility from the start. Our games are games that we wanted to play and hope that other people will like, so this is more of a post to show what we’re doing now it’s finished, rather than a moan at all the problems we will now be facing getting it out there.

It’s way too early to start counting sales and pondering if it’s been a success or not, right now. I’ll likely do another blog post a couple of months down the line to look back on how well it’s done on the store. There’s no option here for direct sales when it comes to IOS due to Apple’s own restrictions. You can’t even put games you’ve been writing on other people’s phone’s or Ipads unless you compile direct to them using your own developer certificate, so we don’t have any way of selling our game on the Dexterity Design website. We do seem to have an option to give away keys which owners can redeem on their own account so we’ll be doing some of that soon, no doubt.

So we now both have the new game in mind and are looking at the design aspect at present, especially from the programming side. We’re presently looking at using Swift to write it in – but still have to decide on Cocos2d, because we’re going to need a lot of maps and we’re not convinced of the practicalities of doing that as yet.

As before we’re looking at a retro game but not from the arcade this time. We’re taking influence from a couple of classic games from the eighties that many people will remember who actively played games back then. We’ll hybrid them both into one game and, we hope, come back with something amazing. I can’t really say any more than this right now, or Aaron will chop off my fingers. Our website will naturally be updated during development to show our progress so the cat will probably be out of the bag at some point next year regardless. I will say it’s Sci-Fi themed, however. But so are a lot of games so that’s not really a massive spoiler 🙂

 

Share your thoughts

Getting iDef to the people —

iDef is almost here. It’s a great game but I suspect it’s going to be a very niche market that really goes for it and appreciates the labour of love that it’s actually been. As far as I recall, Aaron has been working on it for at least two years. We’re talking coding from scratch, and then recoding certain parts as the engine and OS changed. Not to mention rewriting entire chunks of it much later on to incorporate the time-saving features of SpriteBuilder. Ironically, this made it an even longer project, but it’s all about the learning-curve, so it was very helpful to approach it this way.

iDef is a hard game. It’s designed and written that way. Game design is a thankless process where you’re never going to please everyone, no matter how hard you try. Games will either be too easy or too hard, depending on the player so, in this case, Aaron has set his goal post right from the start and be done with it.

Casual players with slower reactions – exactly the person I have become – may not like it because it’s quick, it’s tough and it’s pretty unrewarding, all things considered. However, it’s playable, and fun, once you embrace it, but, the fact is, some people will not, and that’s the market we will get the flack from, should they try it.

I’m currently 46 years old and I consider myself an “old-school” gamer. I’ve been messing with home computers and consoles since I was 13 years old so, I would like to think, I know what I’m talking about. I came on-board as a business partner with Aaron late into iDef’s development so I’m just helping in whatever capacity I can while it’s completed. One of my first tasks was the testing and I was extremely vocal about the difficulty of the game from the outset.

“It’s too hard. I can’t really get any points or test it properly because my reactions aren’t good enough.” is what I said.

“Play it a bit more” Aaron replied. “Practice makes it easier. It’s hard at first but once you get into it then you’ll get much further.”

He’s right, I did.

I can rack up pretty good scores now, work out viable strategies, pull off moves that I know are going to trigger achievements when they are coded in, and, hopefully, make a respectable presence in game-centre tables once it goes live. And I’m 46 years old with pretty poor eyesight, and reactions that probably would let you know that there’s a football heading for my face about 15 minutes after it hit me.

Conclussion: iDef will not appeal to everyone. There are haters who are going to hate. But this is true of all games. I would like there to be some kind of system on the appStore to show how long a purchaser has played the game before he writes their damning, or favourable, review, but it’s probably not going to happen.

However, I also look forward, with great satisfaction, to hearing from the guys who’ve given it a decent run, racked up some reasonable scores, and accepted that it’s a hard game and they need a bit of practice to get any good at it. There are too many throw-away games out there that are designed purely to be easy as anything and just bleed you with in-app purchases, so the developers can cash in on the suckers who believe in buying their way through a game.

My business partner and I are commited to putting gameplay, and value-for-money, above anything, and everything else, when it comes to producing games. If we don’t prove this with iDef then our next game certainly will. That is a labour-of-love and nostalgia, with a game design that’s going to involve an incredible amount of work.

Here’s a Dexterity Design promise right now. iDef, on release, will cost 79 pence. The cheapest price we can put it up for. The only scenario there will be any kind of in-app purchase will be if we release a demo version, as you will be able to pay that price to unlock the full game within, and that will be it.

I’m confident, given time, iDef will be really well received. But it will be down to us to ensure that people will be made aware of it. There’s a huge amount of work in the game that is highly unlikely to even be noticed, but what will shine through is the amount of love that went into designing, and creating, the game from both of us.

iDef is coming soon. Please support us by trying it out. We have the utmost attention towards any constructive criticism, or praise, that people have for it. We are currently beta-testing with selected people right now so keep an eye on our website, or this blog, for release details.

 

Share your thoughts

Working with IOS as a new platform —

Once we had formed a company partnership and decided the route forward was to work with Ipad/Iphone then the tricky part of learning a new language came into play. Prior to this I’d been a die-hard PC user quite happily going the never-ending upgrade-route, and convinced I was doing the right thing throwing money to the wall to keep up with a constantly increasing demmand for better hardware to run even the simplest of games and software.

I got talked out of this and now primarilly work on a Mac. It was pretty expensive to get one but you’re buying a machine that has a very high build quality and is easy to use so it’s not all bad. I actually found it pretty painless to switch over and it was a completely obvious decision as I needed X-code and the emulation, server sharing and other cheaper options I tried just weren’t worth the time. So now I’m using a Mac mini which is pretty portable in that I just carry the small box, a power lead, wireless mouse/keyboard and plug into an available monitor if I have to work outside of base. Naturally, having the Internet means I don’t mean to do that much anyway.

So now instead of my trusty BlitzMax which offered me familiarity, if not solid competence, I’m literally back to the basics and almost learning to code from scratch. I did many things wrong with Blitz in all my time using it, and it’s an ideal time to learn it all again the right way now that I’ve moved onto something a lot bigger. Swift is Apple’s baby, and is shortly going open-source, so it’s almost a no-brainer switching over to it from a business side, but it’s going to take time and a lot of learning to master it. Luckily I no longer work on my own and have access to vast sources of information to make all this easier. It’s still a scarey prospect learning all the new ways to do stuff I’ve already been using in my own way for years as well as advanced stuff far beyond the scope of anything I’ve ever done before in the limited games I’ve written. And, at my age, this stuff doesn’t get any easier.

And so I’ve started with the books. I’ve got four to read, one of which is obviously sprite builder because we’re still commited to using Cocos-2d as our frame work and Sprite builder is going to make a lot of the background stuff a lot easier to code, once I get the hang of it. With a new language I’ve adopted the idea of reading everything and just writing simple examples of all the stuff I learn to attempt to make it all stick in my head. It’s good fun a lot of the time, until I encounter something particuarly tricky, but probably a lot of it won’t be needed at this stage, which is an unfortunate side-effect. With Sprite builder a fair bit may end up being play-as-I-read, so I’ll just see how it all goes over the next couple of weeks.

Aarons game is 95% done we estimate, so getting that finished and on the AppStore needs to get done before we’re both on the same page, because that baby is all objective C and I can’t help at all with that without learning that language completely as well. I went most of the way through a video course intending to try but now we’re moving to Swift there’s just no point.

The next game I’ll blog about once there’s some real progress and we know completely where its going. I’m not going to put up any info on the design, suffice to say it’s mostly mapped out in our heads, and some even in documents, but it’s looking likely to have something like 15 different AI systems and a lot of map design, so it will be major work even once the programming side is sorted. Suspect it will be long time before this one comes out.

Onwards and upwards…..

 

Share your thoughts

My first Blitz game in ages. —

I recently made the decision to stop messing about with Blitz and get into Swift so Aaron and I could start working on IOS development. However, because I got a Mac-mini to enable me to do all this by having XCode, I thought I’d put up some of the questionably better stuff I’ve done with it up here. The “Dexterity Design” website for our partnership should be left just for our collaborative efforts with Swift.

Luckily I made him a cup of tea so he consented to me hijacking our hosting for my own blog so I could actually put up this stuff myself. These links are now hosted directly via the blog so should always be available now.

Gravity force is a simple hybrid of both Mission Command and Asteroids and the idea is to stop the meteor shower raining into Earths atmosphere as best you can. There’s no end to the game and it’s broken down into stages so, eventually, it’s all going to be over. However, our planet does have a primitive shield outside the ozone layer that will work for a while and deflect the rocks but once that’s gone then you’re going to be pretty lonely out in space. If the destruction of the planet does not wipe you out as well.

The game was written over a period of 27 days in a few sessions, allowing for my work schedule. I have documented further down how these were broken down. You can download the game from these two links, depending on what platform you are using.

The PC Version is here :- Windows Download

The OSX version is here :- Mac Download

I’m not really using the PC much, if at all, these days so I can’t really update that version but the Mac build does fix a couple of cosmetic bugs as well as fix the backdrop toggling while you’re entering a high score. No idea how that little gem slipped through.

As for the game itself, I could have done better and got it working with multiple screen resolutions – something that was glaringly obvious once I started using a Mac and a better resolution monitor – but that’s not really a priority right now. The game was written as a test-run for creating a mini-game a month as an exersize in improving my knowledge of Blitz and also focus on getting things completed, which I have struggled with in the past. I can’t really continue with the one a month format I set myself to do over a year now, but I’m still pretty proud of how much I learnt just from knocking this one out between the 4th to the 31st of March of 2015. I’m not likely to go back and work on this some more to improve on it as the exersize served its purpose of deadline programming and getting the job done. There’s plenty I can nab from the source should I ever go back to working on Blitz again, however unlikely.

What I actually learnt just from this game was:-

Using multiple objects in a game with a types structute so much better.

Actually having proper progressive difficulty as the game advances levels. It’s borked after around level six really but, for a mini-game, it functions well enough.

Using images much more effectively using MidHandle() and other new tricks I learnt. If I’d had more time then I’d have sloped the shield around the earth but it was only near the end I considered it and I’d run out of time.

Explosions using sprite images and basic particle systems.

Speech effects – all done by me using Audacity with a PC text to speech program. The echo on “You have a new High Score” I’m particuarly proud of.

And so many other things that I should have noted at the time in the worklog I wrote while creating this game. This was one of a couple of new things I tried with the game so I could get an idea of how well I was working or lazy I was on a particular day. This is the document pasted right into here for the curious…..

 

Wednesday March 4th. 2.5 hours
SFX/Music playback functions
Start of front end
Starfield (already had this and just merged in)

Saturday March 7th.. 2 hours
Voice effects and editing with Audacity
Half coded high score stuff.

Sunday March 8th. 3 hours
Much reworking of front end. Changing how stars work and debug sound/music.
Added scoring and graphics for the earth as well as new cross hair.
Merged in high score table code and reworked for this game.

Sunday March 15th. 1 hour
Implement Earth shield display and fire functions. You can shoot earth yourself if careless.

Tuesday March 17th. 3 hours
Asteroids are in and moving around. Need work to scale number based on level system.
New sounds added for shield bouncing and Earth destruction warning.
Implemented the shield. Asteroids will bounce off this until its depleted then you’re done.

Wednesday March 18th. 4 hours
Changed some sounds to be less annoying.
Collision detection implemented so asteroids can now be shot down.
Background asteroid movement on the title.
Much work on the main objects to make it easier to spawn new asteroids and have gameplay.

Thursday March 19th. 3 hours
Rewrite object handler
Fix collisions and reset image positions with use of AutoMidHandle.
New graphics for the asteroids. 3 different types so large ones can go on title screen and no need to use ScaleImage anymore which made collision detection tricky.

Friday March 20th. 4 hours
Temporary transition screens for game over and new level
50 asteroids per level set up.
Fixed large asteroids on title screen.
More work on collision detection for laser v asteroid.
Reworked scoring system.

Thursday March 26th. 2 hours
Rewrote sound system and changed some of the sounds to be less annoying as well as using more channels to eliminate the choppy fx.
Implemented a progressive difficulty into the game as the levels progress.
Fixed the asteroids moving off screen in-game which made them too hard to destroy.
Fixed the delays between transition screens so they aren’t accidentally clicked through in play.

Monday March 30th/Tuesday March 31st. 5.5 hours.
Final sprint to tidy up and optimise some of the bloated sections.
Implement Pause mode (how did I forget this?)
Tweaked the sound effects again. End of wave sound could induce heart failure previously.
Reworked the asteroids patterns – they no longer bounce off shields as it felt wrong.
Implemented explosion effects.
Put in proper game over and end level screens to replace the placeholder stuff.

Share your thoughts