SyntaxHighlighter

Saturday, 17 December 2011

Tumbleweed

Well, what a surprise! Yet another massive hiatus in updating my blog.

For the last few months I've been in something of a rut. I started designing maps for the-game-formally-known-as-Sphero, and found myself lacking motivation. I was clear in the experience I wanted to player to have, but I was struggling to convert that into what I thought would be compelling puzzles and an interesting environment to traverse. I'd also stopped programming, which is the bit of game development that I enjoy more than anything else. 

As a break I decided to work on a side project. I started off by starting work on a 2D lighting engine, based very loosely on the same principle as the one described by @CatalinZima here: http://www.catalinzima.com/2010/07/my-technique-for-the-shader-based-dynamic-2d-shadows/ 

I had some innovative ideas to improve the approach, and I thought it would be a good short break from designing. Also, I've always wanted to play around with shaders and write some from scratch based on my own ideas, so this seemed a great place to start. I also thought it would give me the coding fix I needed, and let me recharge my batteries for a fresh run at designing Sphero levels. 

Unfortunately, I encountered a few tricky hurdles, and ended up with some very stubborn bugs in my shader code that left me stranded once more, mid-project, with no momentum. Rather than persevere, as I should have, I let myself get distracted by Ludum Dare.

For those of you who don't know, Ludum Dare is a quarterly, 48 hour game development competition. There are no prizes, just prestige. Participants vote on the theme in the run up to the competition, and the theme is announced at the start of the competition. I'd been toying with a new, very simple, mobile game idea for a while, and this seemed like the perfect opportunity to prototype it, if the theme fit. The theme that particularly fit with my idea was 'Escape'. So I up-voted escape and decided that I would only compete if that ended up being the theme. I'm not sure whether I expected it or not, but when I awoke on the morning of the competition, low and behold, the chosen theme was 'Escape'.

So I stuck to my guns and dived head first into creating the game idea that had been brewing in my head for a week or so. The premise was simple. You have balls falling through space, and by tapping on the screen you create small black holes, the gravity of which alters the ball's path, the goal being to alter their path so that they hit an 'exit' portal. When all of the balls have been deposited in the exit portal, the player has passed the level. Any balls that get sucked into one of the black holes reappear at the top of the screen again. 

In my head, this seemed like a pretty simple game. I decided to use XNA and Farseer for Ludum Dare, with the intention of porting to IOS later if I liked the game. 

Even using APIs I was familiar with, I failed miserably to create anything playable in the time limit. There were other distractions, but the main reason was that I completely underestimated how difficult it would be to code everything from scratch. 

Despite this, I still thought that the game had potential, so I carried on with it after the competition. Some readers may have noticed a pattern emerging at this point, but I won't spoil it for those that haven't figured it out yet!

I ended up spending over 2 weeks creating something approaching a basic playable prototype. It took a lot of tweaking of physics values to create a system that let the player actually influence the path of the balls with any degree of control. But eventually I got there. There was a lot more that I had planned for it, but the core of the game was there.

And it was BORING! I realised very quickly that there was no way I was going to come up with an interesting game based on this mechanic. It was almost impossible to come up with level designs where the solution wasn't immediately obvious, and then it became a game of trial and error playing with the placement of blackholes to get them just right to solve the puzzle. In order to come up with interesting levels they would have had to be massively more complex, at which point they no longer leant themselves to the limited screen space of a mobile device. 

Deflated, but determined not to stall yet again, I ploughed on half-heartedly trying to implement another feature, portals, which I thought might make the game a bit more interesting. 

Then came the Microsoft Build conference, which was the last time I posted to this blog. Microsoft released the developer build of Windows 8, and the XNA community immediately noticed that something was missing: XNA! 

There was a lot of noise about XNA being dead, which led me to write my last post on here. Incidentally, my confidence in the future of XNA has actually slipped further in the months since, but that's for another time. In light of the fact that, at least initially, it was clear that XNA games weren't going to be a viable option in Metro style apps, and therefore the Windows marketplace, I decided that there was a gap in the market for a new API. 

For a while I'd been toying with the idea of throwing in my current day-job/ career when I finish my part-time CS MSc course and trying to get a programming job in an established game studio. For that I need real-world C++ coding experience, and I'd been looking for a chance to use C++ in a project. 

These two events collided, and I decided I could kill two birds with one stone by writing a C++ version of the XNA API, written in DirectX 11 so as to allow XNA devs to port to C++ easily and use the new Metro UI. Even at the time I knew it was massively ambitious, but my fall back position was to write enough of the API so that I could port Alta, and so Sphero, to give me a new motivation to work on Sphero - get it done as a launch game for Windows 8. 

I set about the task, and actually got pretty far, completing a number of the smaller XNA classes in their entirety. Then I hit the real meat of the Graphics classes and started struggling. I wouldn't be in a position to properly test any of them until I'd written more, and without knowing DirectX 11 properly I could be heading in completely the wrong direction, but might not realise it for weeks. Still, I persevered (again).

Then a few things happened at once. Work got very busy. I was leaving for work and hour and a half earlier than usual and leaving at the same time. I was averaging maybe 5-6 hours sleep a night. I'd started lectures again for my MSc, which was taking up a lot of my time with assignments. And then Steve Jobs died.

It's strange. I'm not a huge apple fan. I have a macbook, but spend most of my time on MS products. I have an iPod touch, but my phone runs Windows Phone 7. I'd always seen Steve Jobs as an impressive leader and a good salesman, but I would never have considered him an idol. 

Yet when he died, I felt sad. Even now, months later, I have no idea why. But I did. This was before all of the media hype surrounding his death, before watching his famous Stanford address, or reading his sister's eulogy. When I heard the news I felt sad. And, as it played out in the media for the next few days, I, like tech enthusiasts and wannabe entrepreneurs everywhere, started re-evaluating my life.

I started making changes. I took up running. For reference, at school I could never finish the 1500m without stopping to walk at some point. I started following a program recommended by the NHS called Couch to 5k, which aims to get you from doing no exercise at all to running 5k over the course of 9 weeks. I've just finished week 8, and my last run was 4.9k, 28 minutes. I'm literally running further and for longer than I ever have in my entirely life. Why? To prove to myself that I can.

I knew I needed to work some exercise into my routine, but I never feel that I have the time. I knew running took the least time and would burn a lot of calories quickly, that I could do it in the park next to my house so there'd be no travel time built in, but I ruled it out because 'I can't run long distances'. In the aftermath of Steve Jobs' death I started questioning any and all assumptions that started with 'I can't'. 

As you might expect, I also applied this approach to my game development. By this point I had 4 projects on the go. That was at least 2, maybe 3 too many, so I started by questioning why I had so many. I wasn't ready to throw in the towel on Sphero, I still believed it was a genuinely fun game, I just had to get the level design right. My lighting engine was maybe 70% done, but the bugs I'd hit had made me lose momentum, and I'd let them beat me. My mobile game was just not any fun, and my native XNA port was horrifically over-ambitious. 

So I started cutting down my projects. My lighting engine was the closest to completion, I was genuinely learning a lot about shaders, and so it was fulfilling it's goals. The best way to get that project off of the books was to finish it, so that would be my first priority. 

My mobile game was DoA. The only reason I hadn't written it off was that I didn't want to give up on a project. But in this case, it was dead weight. The whole point of prototyping was to weed out the ideas that are no good, and this was one of those. Holding on to it would do me no good. So I declared it scrapped, with no intention of ever returning to it. 

My Native XNA port was tricky. The reasons for starting it were based on conflicting objectives. On the one hand, porting Sphero assumed both that I'd finished it, and that I'd be staying an indie developer. On the other, I wanted to do it to get C++ experience to get into the industry. It was an embodiment of my own indecision over my future path in games development. So, reluctantly, I put in into a perma-hiatus. I may one day resurrect it, but only if I actually need a C++ XNA port.

That leaves me with 2 projects, my lighting engine, which I'd work on first, and then back to Sphero. It was important to me to get the lighting engine finished first. I wanted to prove to myself that I could actually finish a project that I'd designed myself from the ground up, not just a clone of an existing game. 

2-3 months on, and I've finished the lighting engine. The source is on codeplex, and I'm in the process of writing an accompanying tutorial series to guide others through how to develop their own. I'll be posting the series up here as I complete it.

And then, come the new year, it'll be back to Sphero. I had toyed with the idea of taking up a new project that would help me bring Sphero to more platforms than just the Xbox and Windows, and might also help speed up the process of developing Sphero, but I've resisted the temptation for now. Again, if the reasons are right, I might consider it, but I'm done with changing projects to try and get myself out of a rut. 

So, without further ado, I shall shortly be posting the first (and possibly second) tutorial in my new series on developing a 2D lighting/ shadow engine. I hope other people can get as much from it as I did developing it.  

Sunday, 18 September 2011

Opinion: Why XNA isn't dead (yet).

Its been some time since I wrote here, and hopefully I'll soon have time to fill you all in on what I've been up to the last couple of months, but before I do that, I want to comment on the current state of XNA, and my opinion as to it's future.

Background


Earlier this week, Microsoft kicked off it's BUILD conference, looking at Windows 8, the new Metro UI, and all of the new technologies that sit underneath it. As the keynotes and session videos started to appear online, there was one technology conspicuous by it's abscence: XNA. Naturally Twitter started to get worried.

On the second day of the conference, in a session on developing DirectX games for Metro UI, some brave attendee asked the question: What about XNA?

The response was essentially: You can't use XNA with Metro UI.

Later on Giant Bomb posted with an official statement from Mircosoft: http://www.giantbomb.com/news/the-future-of-xna-game-studio-and-windows-8/3667/

The statement said (reprinted from Giant Bomb):

“XNA Game Studio remains the premier tool for developing compelling games for both Xbox LIVE Indie Games and Windows Phone 7; more than 70 Xbox LIVE games on Windows Phone and more than 2000 published Xbox LIVE Indie Games have used this technology. While the XNA Game Studio framework will not be compatible with Metro style games, Windows 8 offers game developers the choice to develop games in the language they are most comfortable with and at the complexity level they desire. If you want to program in managed C#, you can. If you want to write directly to DirectX in C++, you can. Or if you want the ease of use, flexibility, and broad reach of HTML and Javascript, you can use that as well. Additionally, the Windows 8 Store offers the same experience as the current App Hub marketplace for XNA Game Studio, providing a large distribution base for independent and community game developers around the world.”

Why people are worried


The upshot of all of this is the following - XNA games can still be made for Windows 8, but only as Desktop apps, not Metro apps.

This also means that XNA games can be listed in the Windows 8 app store, but won't be sold through it, instead the listing will link to an external website of the developer's choice to allow users to buy the game.

This is an obvious barrier to people buying XNA games, especially when you consider that both casual games built with HTML5/ Javascript and high performance games built with DirectX 11 will have access to the Metro UI, and so can be sold directly in the app store. Why would someone click through to a site they might not have heard of, and fill out their credit card details, when the app store already knows their details and they can buy safely with a single click?

The final blow for XNA devs is that Microsoft have announced that the ARM version Windows 8 will only support Metro UI apps, not Desktop apps. So if you were hoping to bring your XNA game to a Windows-powered tablet audience, you're out of luck.

You'd be forgiven for thinking that this clearly shows Microsoft is abandoning XNA as a future technology for gaming on it's Windows platform. It also calls into doubt whether XNA will be supported on future versions of Windows Phone, and on the next version of the XBOX.

So that brings us to our next question:

Why isn't XNA supported with Metro Apps?


It seems to many that if Microsoft was serious about XNA as a technology then this was a prime opportunity to make XNA a first class citizen in their Windows eco system. Both large and small studios have been using XNA for their games on Windows Phone 7, and more and more successful indie titles on Steam are using XNA as well (Terarria, Magicka, and most recently Bastion, to name only a few). Surely allowing XNA developers to build games for a new generation of Windows powered tablets is a no brainer?

Turns out, it's not as simple as you might think. The reason? I think it comes down to one thing: DirectX 9.

XNA is build on top of DirectX 9. DirectX 9 is now a pretty old technology, and Microsoft has decided that DirectX 9 will not work with Metro UI. Personally I agree with this decision, DirectX 9 games are still built in order to reach Windows XP users, and more importantly, because it allows code sharing with Xbox 360 builds. However, the speculation in the gaming press is that the Xbox vNext is in development, and that we'll probably see an announcement at some point next year.

So if DirectX 9 doesn't work with Metro UI, then by extension neither does XNA. And let's face it, Microsoft was never going to spend time and effort supporting DirectX 9 with Metro UI just for XNA games. It would mean including a DX9 runtime in the ARM version exclusively for XNA games, and probably a million other headaches I've not even thought of.

Why I'm not worried (yet)...


Strangely, since finding out why XNA isn't supported in Metro UI, most of my fears that XNA was dead have faded away. I'm going to try and explain why.

Let's think about this another way. What would Microsoft have needed to do in order to support XNA with Metro Apps out of the box? The way I see it they had 2 options:

They could have supported DirectX 9, but there are plenty of reasons they wouldn't want to do that (see above).

Or they could have re-written XNA to run on DirectX 11 under the hood.

Lets unpack that second option for a second. The Xbox 360, and probably Windows Phone 7, use some form of DirectX 9. That means that either a DirectX 11 version of XNA would be Windows only, and we'd still need to use the current XNA version for developing on Xbox and the phone, or else the API would need to be static and a DirectX 11 code path would need to be put in place for Windows.

That would be a fair amount of work, but you might think that it's worth it if Microsoft is serious about XNA. Unless you consider the Xbox vNext.

Most likely the Xbox vNext will run on DX11 or some form of it. If Microsoft plans to put XNA on Xbox vNext (as I hope they do if they're serious about it), then it would make sense to do a full DX11 rewrite of XNA at that point. They can't do it now, because I doubt the software stack for the new Xbox is anywhere near being nailed down yet.

So in conclusion, I believe the lack of Metro support for XNA means one of two things. Either our worries are justified, and Microsoft plans to cut XNA loose OR Microsoft is actually really serious about XNA as a future technology, and is waiting until it can be rewritten for the Xbox vNext and Windows 8 at the same time.

Until we know if XNA is going to be on the Xbox vNext, I haven't given up hope.

Thursday, 28 July 2011

Design-time: first area map

It's been a while since my last update for one reason or another. I took some time out from working on Sphero to start-up a small side project. I won't elaborate on it here now, as I'm not sure if its going to go anywhere. If it does then I'll be sure to post an update :)

I started back on Sphero a bit over a week ago, and I've finally turned my hand to designing the map/ puzzles for the game.

The game is essentially a cross between a Metroidvania and a puzzle platformer. The world is split into 5 areas: the Forest, the Ice Wastelands, the Mine, the City, and the Core. In each of the first four areas there are one of the 4 totems which unlock one of the gameplay mechanics (double-jumping, turbo speed, wall-crawling and er, being on fire!).

The two images below show what I've designed so far. The first is a general guide for the 5 areas, and the second is the detailed design for the Forest area. The overlay with arrows/ words etc is just a guide so that I know when I need to design the puzzles in such a way that the player will need a certain ability to proceed:




You may have noticed the little yellow section marked 'ship' in the first image. You'll just have to wait and see what that's all about... ;)

The map might not look like much, but it's taken a lot, lot longer to design these puzzles than I'd ever expected. I seem to be saying this a lot lately, but design is hard! Given that a puzzle platformer lives or dies by the quality of its puzzles, its balance between being challenging enough and not being frustrating, and its learning curve, there's a lot to conisder, and I'd be very surprised it I don't have to make significant changes to all of the puzzles I've designed so far before I'm through, but its a start.

Anywho, that's all for now, I'll post again when I have the map for the next area finished.

Catch you next time.

Sunday, 12 June 2011

Updates part 2: Mode switching

And as promised, a video showing off switching mode with the right thumb-stick, Crysis style. It should probably be noted that all the artwork, including the interface for mode switching, is just place-holder art at the moment.

A quick note on what each of the modes are: Black is normal, Red currently is the same as normal (but will be on fire!), Grey allows a double jump (Air), Blue increases movement speed (Lightning), and Brown allows wall crawling (Rock).

You'll just have to use your imaginations until I get some proper art work in place!

Here's the video, enjoy!

Saturday, 11 June 2011

Updates part 1: Parallax layers

I have 2 updates to share, but the 2nd might have to wait until tomorrow, as it takes a while for new videos to show up on the youtube search.

I've been v. busy the past few weeks with prep for exams (I'm taking a Masters in Computer Science in the evenings alongside my day job), so haven't had a lot of chance to work on Sphero. What I have managed to do is to add parallax layers and a new way of switching mode (with the right thumb-stick, Crysis style).

Here's a video of the parallax layers (excuse the programmer art...)


I'll add in a video of the mode switching tomorrow when it appears on the youtube search.

So what's next? Well, its finally design time! I'm going to be designing the map in full over the next few weeks, from which I should generate a nice big list of features that need to be added to the engine and the editor, so that I can add the various features of the world to the maps.

I'll probably upload sketches of the map design during design to give you a flavour of what the finished game will be like, but otherwise its going to be quite quiet until I finish designing and start implementing features.

Sunday, 8 May 2011

Map transitions

Just a quick video of map transitions between world sections in Sphero, based on those you come across in the old SNES/ Gameboy metroid games.





I'm still working on the editor extension that will let me arrange world sections in a grid in my editor. Fingers crossed I'll finish that today.

That's all for now, hopefully I'll have time for an update next weekend! Have a good week!

Friday, 6 May 2011

Progress report...

Ok, so once again I didn't manage the promised update last week, mostly due to starting a new role at work, but also because I've been making steady progress on Sphero. I've added transitions from one section of the map to the next, which I'll upload a quick video of at some point over the weekend (fingers crossed).

I'm also adding a mode to my editor which will let me edit the map as a whole, as well as the individual sections. That will probably take me a little while, and I still need implement the ability to add and edit parallax layers in the editor, so looks like I have some more tools programming ahead of me! Fortunately I can build on the functionality I already have with my editor, so that should make life a lot easier!

After that I think I probably need to knuckle down to some actual designing of the game map, including hazards  obstacles  puzzles. From that I should be able to pull out a list of features that I need to implement in game code/ the editors. Then I'll need to actually create the basic map.

Then it'll be on to designing enemies and their abilities, before implementing them in code, and adding them to the maps. By that point I should have a working game, albeit with place holder art and no sound. Art will come next, including graphical effects/ particles/ shaders that will need to be implemented in code, along with scenery, backgrounds, and animations.

Then will come the sound/ music. And then the trimmings, UI, title/ start screens, HUD, along with any other features that I've thought of along the way that can be added with little hassle at the end.

So there we go, that's the rough roadmap for Sphero. Looking at it, if I have it ready for DBP 2012 (assuming there is one), I will be very, VERY impressed with myself... *GULP*