Coke and Code

In my day job the term “mashup” comes up a lot. I mean loads! A mash up for anyone who doesn’t know is the idea that you can take a bunch of library code, mash it together with some glue code and end up with a new solution. This is extremely popular on the web but happens in most languages and domains to a greater or lesser extent. Games for instance, very similar approach - take some graphics code, add some sound library, a bit of networking, a pinch of path finding source, mix in some custom glue game play logic - pop out comes a game. 

Alright, it’s a bit more complicated than that, but you get the idea. At work we traditionally write server side code in Java. The hard thing about server code is it’s hard to test every path, it’s hard to re-deploy once it’s live and above all it’s multiuser, so if the server breaks, you break everyone. With all that in mind there are a set of software development best practices that are applied to make things easier to test and more reliable in the long run:

• Encapsulation - everything related to one topic is contain in one class (or set of classes). This tends to mean small bits of code spread out very thinly.
• Information Hiding - don’t expose anything to the outside unless they absolutely need to know it.
• Decoupling - try to make sure most relationships are done via interface not via real dependency. This helps with information hiding too.
• Decomposition - every problem is built of N reusable parts that I want to separate so I can change one part at any time.

All of these things are great for building nice flexible, reliable and testable code. However, as with most things in software theres a trade off - for every level of protection I put in to prevent the uneducated programmer making a mistake, I take away an option for the educated programmer to use in a mash up. For instance, by hiding that one internal variable I prevent the developer setting it to something I didn’t plan for! - on the flip side, by hiding that one internal variable I prevent the developing using it to do something new!

This trade off is really bears considering when you’re writing your software. Who is your target? Are you sure you know everything about how someone else might want to use your code? This isn’t a one way fits all thing.

For me, the choice is about where it’s deployed, what culture the language programmers have and how easy it is to test. So, if I’m up on the server, in Java, where it takes hours to setup and configure the system, I’m probably going to err on the side of protecting everything. If I’m on the client, in Javascript and I can test it by just fiddling with a script - I’m going to err on the side of mashability (just made that word up!).

Change any of the variables and the answer may change. As always it’s all about thinking for yourself and considering the options. Blindly following is the way to fail.

Wizards of Yore made it on to the Apple Store!:

https://itunes.apple.com/us/app/wizards-of-yore-free/id635658993?mt=8

https://itunes.apple.com/us/app/wizards-of-yore/id635659572?mt=8

Also the prototype board game version arrived, had a quick play, some printing issues but pretty good so far:

Wizards of Yore is now on Google play here:

https://play.google.com/store/apps/details?id=org.newdawn.wizards

https://play.google.com/store/apps/details?id=org.newdawn.wizards.paid

It’s still in development but I thought the best way to get feedback is to put it out there. The price and approach to charging may change too depending on what people want from it.

Wizards has also been submitted to the Apple App Store so it should be available on iOS real soon now.

Been asked a couple of times why I keep calling my rendering style recently “pseudo” voxels - it’s because it’s not a real voxel rendering. There’s a fairly significant restriction that you can only view from a fixed single angle.

The game world is actually voxels, i.e. theres a huge 3D array that maps out where each single “cube” is in the world. However, the renderer doesn’t do what you might think - it doesn’t march cubes and optimize the mesh in any way. It doesn’t in fact render anything in 3D at all. 

The rendering uses a second buffer, almost like a Z buffer. As cubes are added or removed to the world a ray is cast out along the known view angle - to keep this fast the view vector is always (0,-1,-1). If the new cube is not blocked by another it’s added to the buffer, along with it’s depth, whether it’s shadowed and whether it’s top is show (easily calculated by looking at the surrounding blocks). When a block is removed, the second buffer is checked to see if it was the visible block - if it was then scan back from the old cube position to find the new visible block.

Then when rendering scan through the almost Z buffer and rendering the blocks that have been deemed to be visible as simple sprites (of blocks). Take into account whether a block is shadowed and whether it’s top is showing and thats it.

It’s pretty low cost to render but it’s not incredibly efficient to update. The mechanism to determine whether blocks are visible correctly and work out which ones are shadow is a bit fiddly but outside of that it’s really very easy to implement. 

So yes, it’s not real voxel. No it’s not as cool. I still like the style of things that come out tho. :)

A sensationalist blog title is worth 100 good posts. Your first thought, this guy is just bitter. Well yes a bit for probably not for the reasons you think.

How about some background first. I got contacted by Google a couple of years ago, would I like to come for an interview. WOW! It’s Google right! They then put you through some phone interviews that make you feel like you’re begging for a job. Ok, not nice, but still. It’s Google right! Then you visit a local site for a face to face interview - and you will be blown away by their facilities. My god, it’s Google right. I failed by the skin of my teeth, and you’re think I’d be annoyed. Well like most of us geeks out there thats not the case - the first question that went through my mind was “ok, when can I apply again?”. I mean, it’s Google right!

Fast forward to now, I’ve considered applying again but just never had the right moment and I was back to thinking about again recently (for various reasons that I’ll explain one day, honest). As I was thinking about it I realised I don’t actually want to work there any more. What?!? It’s Google right!?

As I thought about applying again and going through the hoops to get what used to be my dream job I started thinking about Google as a company. Why are they so good? Why do we all want to work there?

Google’s foundation is it’s image. Ok, they have the cash cow in searching but the rest of their products run on their image. For years we’ve all loved them. Even if sometimes their products fail and don’t provide the experience we want we’re all thinking it’s Google, their nice, they do things for free. They don’t act like your normal business, we don’t feel like we’re being ripped off. That’s exactly how Google have been for years - they’ve been producing services and concepts because “they can”. Investing money in products that we all love and use, that work (mostly) pretty well. If anything goes wrong or anything isn’t quite right we all feel like we have a vested interest in them getting better … because it’s Google right? 

The long and the short of it is Google has done very off the good feeling they’ve generated in the user community at large. The vision of the philanthropic behemoth doing things for the people. Not acting like a huge faceless corporation and doing things “the right way”.

Looking at it now though, you can see the chance. Google are starting down that slippery path to the dark side. Reader is the obvious case but if you look a bit deeper you’ll see a general tend towards money first - people second culture. It had to happen eventually - they’re turning into a “real” business. Unfortunately for Google they aren’t going to keep that wonderful relationship with their users if they go that way.

So, why would I want to work for Google now? I could choose any big company with a big chunk of cash and a whole bunch of crazy ideas. There’s plenty of them around and Google is heading rapidly toward being “just another”. It’s Google right? Wrong.

Well, I told Mario over at badlogicgames that I’d write up my experience using the wonderful LibGDX to port Legends of Yore and get it back on iOS - finally!

So, first up, have to set the scene. Legends of Yore is a large RPG/Roguelike with a very simplistic graphical style. It is available on iOS, Android, Desktop, Playbook and Touchpad - all from the same code base. I developed against an abstract API I created before there was any decent way of getting on to iOS - the Touch API. This API meant that all uses of images, sounds, network connections and everything else was already abstracted away from the game code. 

Unfortunately it never performed very well on iOS - that was due to the method of getting it there, XMLVM which while extremely cool uses a method of compiling the byte code into C code then recompiling. As you imagine those layers make things pretty slow. Worse still, when iOS 6 came out it broke my code in a way that I couldn’t fix without rewriting chunks of XMLVM - something I wasn’t able to do, at least not well.

LibGDX

So, enter LibGDX - an API I’ve been aware of for many reasons. First I know some of the folks working on it from past java gaming projects. Second, Slick (my game library) got compared to it regularly as thought there needed to be some competition between the two. Finally, I was hearing great things about how it worked. Then came the new it could now get to iOS via a much smarter method than mine (more on that later).

My customers are/were needing an iOS 6 update so I decided to port Legends over to LibGDX. Things really couldn’t have been much easier. Screen setup is pretty much done for you by the sample code provided. SpriteBatch is wonderfully simple to use to splat sprites from textures onto the screen. Sounds are a very simple API and all that worked flawless straight off the bat even when I ported to iOS. 

Lets talk more about that, compiling to iOS, how does LibGDX do that? It builds the Java, then uses IKVM to get C#, then finally uses MonoTouch to get to iOS. Now, you can go as far as the iOS simulator with just your Mac and the trial version. However, the minute you want to actually get to the device or the AppStore you need to fork out $300 to get a MonoTouch license. For me, that was a no brainer, Legends has paid much more than that over the years and my customers deserved to have it back. Re-invest some cash and get the license.

EDIT: Mario informs me that the trial version of MonoTouch actually lets you deploy to devices too! Just need the license for the App Store.

Does it work?

I had one, yes read it, one problem with LibGDX. The HTTP API wasn’t working correctly on the iOS backend. It was simple enough to fix and thats now been worked back into the code base.

Other than that, yes it works! It works damn well. I have a Java project that I change how ever I want. Once my changes in Eclipse are complete I move to MonoDevelop - hit clean and build. Run on the simulator and I’m testing! Round trip from code change to simulator is around 20 seconds. This is close to perfect for me!

Ok, there are some limitations on which bits of Java API you can use and you want to try and make use of the GDX API as much as possible since that is intended to be portal. However, you can read all that on the LibGDX Wiki. 

That said, Legends is a pretty code base for a pretty complicated and expansive game and it ported straight over. 

I’m sure there will be problems to resolve that come up once people start playing it again - but without further ado - Legends of Yore is back on the AppStore here and here.

All I can really say is thank you LibGDX Team, you really do rock!

I wrote a game called Wizards of Yore before Legends. It never really got anywhere but a lot of folks did like it on Android. At that time I just wanted to remake “Chaos” that classic spectrum that everyone loved so dearly. 

The reason the game didn’t go well the first time - at least from my point of view - was there was very little of me in it. I know that sounds “arty” but thats really how I’m starting to feel about games. My games are my games because they have a feel to them (yeah, I know, because they’re crap).

So… I started again. I’ve tried to learn to pixel and all the art for this new version is mine. I written the game rules as a board game (see the PDF on the website) so that while it’s inspired by Chaos for sure - it’s really how I’d like the game to play. As with legends it’s intentionally design to be a drop in and play game - not one that uses up all your time, but one that fills the time you have spare.

It’s coming together slowly and you can expect a release on iOS, Android, Desktop and anything else I can get it running on within the next month or so. 

Check out the game’s website for more details http://www.wizardsofyore.com

In other news, some of you are aware I had to pull down Legends of Yore from the Apple Store when iOS 6.0 came out. The OS update broke my game and I didn’t have a way to get round the issue. My apologies for the problems caused and I hope I’ve responded quickly enough to those effected.

Thanks to the wonderful LibGDX it looks like I’ve got another way to iOS that will be much more reliable. Since Legends was intentionally written with a view to being cross platform it actually only took me 2 hours to port the whole code base across to LibGDX. Small bug in the iOS backend for LibGDX which I’ve pushed the fix back for - and badam boom! Legends of Yore is submitted for AppStore review again.

No news as to approval yet and I’ll let you guy knows as soon as I do. As a bonus the game runs about 10x faster in it’s new form!

Thanks for the patience guys!

Reading my twitter recently I saw Mario over at BadLogicGames had posted this article on the viability of the JVM for cross platform games. In this case when he says cross platform, he’s not just being Linux/Windows/OSX but rather a full set of gaming platforms - Desktop (Linux/Windows/OSX), Mobile (iPhone/Android/PSP/etc) and Consoles (XBox/PS/Wii). 

First let me say I totally agree with all the points made, and Java was specifically designed for this sort of cross platform job and it’s a damn shame that Oracle aren’t doing anything real about it. I don’t want this coming off as a blog arguing with Mario, he’s right there’s no doubt on that.

My response on Twitter was aimed at highlighting that the technology isn’t really the big issue with this sort of cross platform games development. If you’re talking just desktops, or just mobiles, or just consoles the technology is the core of the hard work. If I can just rebuild for different targets that saves loads of time! Wonderful! 

Why did I choose Java for games development? ‘Cause I know it and like it. That said, I’ve ported my games into Flash, C# and Game Maker and it’s not a great deal of effort to jump between the tools for specific jobs. They all support the game concept and since 80% of my game code is logic not rendering it’s not that big of a deal.

However, if I’m targeting different platforms as in Desktop/Mobile/Console then the big and complicate bit isn’t how I get there - it’s how I design the game so it makes any sense at all on the different platforms. 

Game Design for Different Platforms

I’ve written games for different platforms. For mobiles, for desktops and for consoles. When I wrote Legends of Yore I specifically started with a game design that would work across platforms - thats why the game is so simple. That’s why there are design choices all the way through to make it simple to play on all the different control systems (mouse, to touch, to controller) and other variations on platform.

Variation of platform isn’t just limited to hardware either, what about community, what about expectation, what about game play mode. I’m going to try and tabulate those things below. Obviously the quantification below is going to be based on my experiences and opinions - so you might not agree. The table isn’t really there to be *right* as much as it’s here to highlight all the possible differences:

I’m sure there are a tonne more facets that I haven’t noted, these were just the ones that occurred to me thinking back over legends. 

Conclusion

I’m not saying that cross platform tech isn’t really really cool and really really important. However, being able to rebuild your game for another platform isn’t just going to make it “work” as a game on that platform.

You need to consider a lot of factors in game design and marketing before you really do achieve cross platform games that are fun and hopefully successful. 

It’s been ages since I blogged! Why? Well I’ve just been ever so busy trying to fix a company culture, build new products and create something for my future. 

That’s done now ;)

So… back to games development and associated posts.

Of all the games I’ve made (or tried to make) there’s been one common issue - Art. Whether it’s in game sprites, 3d models, background art or marketing collateral I have to either beg, borrow or buy (note not steal) it. When I’m writing a commercial game it’s not too bad to pay for graphics but it still leaves us with the problem of updates and fixes to the art. That just adds up to slow down and administration - two things I hate.

So in the interest of being self sufficient I’m trying to learn enough to be able to create art for my games at a quality high enough to mean I don’t have to replace them. That doesn’t mean they won’t get replaced just that my hand isn’t forced. Anyway justification over, on to the art…

Sprites - I love retro SNES/NES style sprites. I’m generally moving in that direction in my games. Where to start? I found Tsugumo’s Tutorial really useful, specifically this page. It shows you in nice easy steps how to create a simple character sprite. Mine wasn’t very good tho - at least I wasn’t happy with it. I knew what to do but I just couldn’t get it to look right. So, how about basing it off something else. I’ve been using Oryx’s sprites for my games Legends of Yore, so I went for the warrior and tried to use it as a basis:

Pretty happy how that came out and now I had some basis to work on everything became easier. How about some animation? I need walk and attack to start with, this took a lot longer and a lot more iterations:

I was pretty astounded at how these came out. Once the basic character was in place it was trial and error to get to something reasonable quality that I could use. Trial and error took an awfully long time but it was very rewarding once done. Not sure how long I could stick at it! Next I tried some more characters and seemed to be easier now I had a style to work against, here’s what I came up with:

Pretty content with how they came back. However, as always I asked for feedback and some of the wonderful pixel artists on TIG Source came back with more tips and some examples on lighting - so I’m about to look at these next:

Marketing Art - this is one thing I’ve definitely learnt through trying to sell games, there’s an awful lot of art that you need to be able to advertise, publicise and distribute your game. This includes banners and promo images, not to mention all the art you’re going to need to satisfy the App Store, Android Market, Blackberry App World and Steam.

This type of art needs to be bigger, more refined and fill larger areas. On the bright side it shouldn’t need animation - so I’m thinking just some set pieces would be great. I love the manga art style so I picked myself up a how to draw manga book and a set of ProMarkers. The book is fantastic it gives you a set of examples to work against and also some details about how to create your own characters and styles. My first attempt came out like this:

This was ok, until my girlfriend (an artist) did a much much better one. I had trouble with precision inking, too much messy edges on the black. Got a better inking pen and tried again, here’s the stages:

Much much happier with this one, though it was as with the ghost it was a follow along from the book. Next step? Try creating something myself:

Well as proud I was of it, the colouring sucks and the character just looks really really stoned. Right, I have a lot to learn and I’ll probably bore the hell out of your blogging about it. Anyway, next steps are to ink a character, scan it in and colour it using Inkscape rather than with pens. Hopefully this will get me some better results.

In summary, art is really really hard but if you spend long enough trying, get enough sources of information and ask for help you can get somewhere. Hopefully I’ll eventually get good enough, I’m pretty pleased with progress so far.

Most of my games aren’t amazing. Most of my games aren’t revolutionary. Most of my games don’t get lots of press. What my games do get is done. Now and again I’ll get a tweet that asks how I produce stuff quickly - is massages my ego a great deal. So, here’s a few suggestions that I try to follow and I’ve found it helps me get things done.

Getting Started

1. Focus - don’t keep changing your mind. When you’re starting out the choice of language, tool, framework or engine doesn’t really matter that much. They all teach basically the same thing and they all have communities to get involved with. Choose one, GameMaker, Unity, Java, XNA, Flixel. It doesn’t really matter but stick with it. Don’t get tempted to change when you get stuck. All that happens is you waste time and get stuck again when you reach that point in. 
2. Persistence - you’re going to get stuck. You’re going find it frustrating and it’s going to seem impossible. Given time you will make it through. Don’t give up because it’s hard even though you may well want to throw the computer at the wall by the end of it. Take a break, step back and then come back and beat it. It’s all part of development and it’ll always be there.
3. Start Small - and work up. If you try to take on a 3D multiplayer physics based game with distributed AI processing as your first game you’re likely to fail - quickly. It doesn’t have to be stupidly small but try to stick to one thing at a time. Simple 2D fun games are a great way to start (and continue if you’re me).
4. Ask for Help - you’re going to want to ask for help, but you need to be careful how you do it. Most experienced developers in the communities related to the technology are willing to help out. However, you need to be polite. You need to listen and take the time to try and understand the answers. Most important, don’t expect an answer. Everyone is busy. Everyone has limited time. If you get an answer great, if you don’t then go back to step 2. Keep trying to fix it yourself, post your progress. People are more willing to help someone that is trying to help themselves. DO NOT get angry and shout and stamp your little feet about people not using their time to sort out your issues.
5. Be Proud - show other people what you do finish. Always be proud of anything you achieve. It may not look like much to you but other people may find it interesting. Get your stuff out there on twitter, tubmlr, facebook (if you have to). Get it on the forums and get screenshots of what you’re doing visible. Every time you achieve something you should be massively proud of yourself. Every time you get a game running, get people to try it, the feedback will probably help you grow as a game builder more than anything else.

Getting Things Done

1. Don’t Obsess - your code is your code and I know you love it but how beautifully shaped and how wonderful the architecture is doesn’t matter one bit to the end player, especially if the game doesn’t ever get to be playable. Do not obsess about your code. Make it work. Make it quick enough. Make it pretty. In that order. If you don’t have a lot of time you can just do the first step and apply the second two once they’re actually needed. The sooner you get a game working, the sooner you’re going to get player feedback and the sooner you’re going to feel motivated to keep working.
2. One thing working, is better than 100 half working - get something working as soon as possible. Even if it’s as simple as your guy walks left and right. The sooner you can see something, the sooner you’re feel the game and know whats needed. If you try and build the game on many fronts at the same time, apart from lacking motivation, you’re going to get confused quickly. Not to mention not being able to know whether anything integrates well until the last moment.
3. More than one way to skin a cat - there are many ways of approaching any problem in software. There are normally a set of “right” ways that are well explained in long tutorials on the web. You don’t have to do it the “right” way. Take collision, you go off and read the tutorials and you start implementing the perfect way that covers every possible collision response that any game could ever need. It’s hard and it gets buggy quick. You’re not entirely sure you understand what you’re doing, but you just keep going. WAIT! STOP! In your game the collision is much more simple, you just need one type of detection and one type of response. How about you just code it the “wrong” way for now, just make it work and if it doesn’t feel right later replace it. At least it’ll be playable and you can move on instead of getting bogged down.
4. Libraries and Middle-ware - nearly every problem you come across there will be a library that can do the work for you. Be careful! Dependencies and the bugs inside them are a big time sink. If you don’t need to use a library, don’t. If you’re not sure it’s going to save you time, don’t use it. That doesn’t mean never use any 3rd party code, just be sure you know why you’re using it.
5. Have a plan - a simple changeable one. I keep a text file with a list of TODOs in. Sometimes I even add categories like Bugs, Game, Infrastructure. Keep a list of everything you need to do and cross it off as you go, it’s a nice sense of achievement but it also keeps you focused. However, don’t overcook, you don’t need a big tracking framework and you want it to be changeable in a second. You’re coding away, you think of something, you stick it in the plan and keep going on what you’re doing.
6. Get Involved - talking to your peers, showing your work and getting feedback is key to staying motivated and keeping progress flowing. Helping out new developers, writing down how you’ve achieved stuff and building a network of developer colleagues can also be very rewarding, not mentioning as serving as a rest break between coding sessions. You never know who you might meet and end up teaming up with!

Well that’s it really, hopefully it’s a useful list for someone. It at least gives me something to post to people asking :)

It’s one of the most asked random questions on twitter for me, “how does dungeon generation work?”. I’ve written a few articles about it in the past on the old cokeandcode site and even put up some code. However, thats a very explicit example and maybe it can be expressed in more simple terms. So here we go:

Step 1: Randomly place some rooms. Best to start with simple rectangles. Generate a random width, height an position. The ranges for these values should be configurable - changing them will change the style of the dungeon you get out. Placement wise you can either just place them completely randomly (just make sure they don’t overlap) or you can “grow” a dungeon by placing each room next to another - apart from the first one of course. Either way you’ll end up with a bunch of rooms some of which are next to each other.

Step 2: Join some of the rooms up with doors. Scan through the rooms trying to find any edges that touch, join those up with doors. So now you’re going to end up with a few rooms joined together. Unfortunately not all of them are going to be joined up so you can’t really place anything and expect it to be found (other than an entrance of course). 

Step 3: Link up just enough rooms to make every room accessible. This is the tricky bit. The way I do it is with islands. I take the first room and mark it with an island ID. Then I mark every room that it’s connected to by a door with the same island ID. Then every room that they’re connected to and so on. Once you’ve finished select the next unmarked room and do the same but with a different island ID. Keep going to every room is marked. Then it’s a matter of creating a link between a room on each island with whatever makes sense for your map, corridors normally. So link a room with island ID 1 to a room with island ID 2 - one less island. Keep going until all the islands are linked up.

Step 4: Place features. Now you can guarantee that every room is connected to every other you can start placing features, like a exit and monsters. In addition you can start putting in details and reshaping rooms. One thing I used in Legends was merging rooms where possible which gives odd shapes and a different feel.

So thats, it. Obviously that’s quite a high level overview but it probably applies to most types of maps and most types of game. Place the spaces, join them up, make sure everything links up and fill with game specific items.

Oh well, hope this helps someone somewhere..

Ok, ok, I admit it, I forgot I had a blog. I’ve been enjoying twitter so much that I haven’t been posting and thats just not right (tm).  So, I’m going to try to change that and post a bit more often with a bit more detail and probably some technical stuff.

Not sure if anyone’s interested but I’ll do my best.

Right now I’m fuming about some one telling me to spend more time on a specific project so they can have more updates. While I always appreciate feedback lets be serious, if I wanted to be told what I should spend my time on then I would just be doing this as a day job - I’m doing games as an indie so I can control my own time and destiny. 

I’m doing the best I can, but I have to follow the method I’ve used for years. It fits, it works for me and it makes me feel like I’m progressing - which we all know is the only way to stay motivated.

It’s pretty simple way to work I think, before settling on a game to focus on I build set of prototypes. I’m not very good at choosing the “right” one so I produce a set, float them with anyone that will try them and let them feedback. Like everything else I do I rely on the feedback of players to make the decision. So, I’m half way through a prototyping phase at the moment. I have some tiny finish off details to do on Legends of Yore and while I’m letting those settle I’ve produced a 4 prototypes so far. By far the most popular so far is World of Yore, but I’m loving some new concept art I did last night:

So yes, I’m flitting about between projects at the moment, but it’s intentional! It’s what I do!

Well, that was an interesting day. I’m now asking for payment on all version of Legends of Yore. After level 20 the game prompts you to pay, reducing your XP and gold gains if you don’t. I was slightly terrified of upsetting people but so far I’ve had 100s of messages of support and praise. Thank you to you all!

The payment process was reasonably painless to set up, I’m using both PayPal and Google Checkout (so you have the option). Setting them up and integrating with the server seems to have been a success. Not to many fails so far and there have actually be a few sales.

It was a big decision to go this way, I’ve mostly done free games in the past. In this case though I had little choice as costs for the save server etc are going up, my time is getting used up and hosting costs come in - in general I had to charge. Which I guess is the nature of business. I would understand some negative reactions to me introducing charging a few months in, I know you would have preferred I had charged from start if I was going to. I can promise I’ve learnt my less and I’ll try to manage it better on the next game (yes, there will be another)

Legends development is pushing on, I’ve a list as long as my arm to implement. I’ll post more about those new features later.

Hopefully the way I’ve done things is fair and I’ll be able to buy pizza for the development process shortly.

I entered ludumdare this year with my entry The Cell. The results have just been announced and I got place 70 out of nearly 600 entries, so very very proud!

For those who don’t know, Ludumdare is a programming contest. You get 48 hours (over a weekend) to write a complete get from start to finish. You can use library and engine code as long as you declare it early on. All assets (music/graphics/sfx) must be created over the weekend. The game has to be playable on Windows but other platforms are appreciated.

It sounds hard, really hard… and you know what it is. However, it’s also absolutely brilliant fun. There is such a sense of community while the event is going on. You see literally hundreds of games coming together at the same time as you’re hacking away at yours. It’s also a way to “get something finished” which is something that alludes game developers all the time.

Finally, you get to try out ideas and it really doesn’t matter if they don’t work out - since you’re only losing a weekend. This leads to lots of weird and wacky games you never would see any where else. Kudos to the organizers.

Congrats to all those who took part - see you next time!

A long time on a site far far away I wrote up a dungeon generation algorithm that is essentially the same one I use in Legends of Yore today. However, it’s getting a bit tiresome so I’m currently working on adding a bunch of new features:

• Rounded rooms!
• Corridors
• Joined rooms
• Throne Rooms
• Multi-chest rooms
• Feature Rooms
• Hive Rooms

Hopefully it should make exploring the game dungeons just that little bit more fun!

There are of course a stack more dungeon features being added, but I shouldn’t give them all away I guess :)