Ask me a question
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.
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 on App Store
Wizards of Yore made it on to the Apple Store!:
Also the prototype board game version arrived, had a quick play, some printing issues but pretty good so far:
Wizards of Yore on Google Play
Wizards of Yore is now on Google play here:
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.
Pseudo Voxel Effect
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. :)
LibGDX, Legends of Yore and getting to iOS (again)
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.
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 orthe 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.
All I can really say is thank you LibGDX Team, you really do rock!
New Game: Wizards of Yore
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