If you’ve been around game development for any length of time, you have probably heard of the Tiled Map Editor.  It is a great open-source editor that supports orthogonal, isometric, and hexagonal maps. I’ve been eyeing it for a while and considered using it for HackBotZ but ended up settling on Ogmo Editor instead. That was a while back, and since then I’ve moved to Unity3d which does not natively support loading Tiled maps. I looked around a bit and found a lovely Tiled2Unity framework but it does not support loading Tiled maps at run-time. Instead, you import your Tiled maps into the editor and it makes prefabs of them. I however want the ability to simply open up a map in Tiled, change it, run the game and have the changes just show up. With that in mind, I began the process of coming up with some code that would parse a native Tiled .tmx format into some data structures I could work with.  The .tmx format is really just an xml file with specific elements to describe map configurations, so I started on Saturday to write some simple C# to parse it. I had things going pretty well until I hit the data section of the layer element that describes exactly which tiles go where. There are several tile layer formats supported for this data : base-64 uncompressed, base-64 zlib compressed, base-64 gzip compressed, CSV, and XML.  I took one of the example maps that comes with Tiled and changed the format to CSV, then XML, then the compressed formats.  The difference in file size, as you might imagine, is significant. CSV and XML formatting make the files much too large for my purposes.   I could have compressed the whole file, but that would not allow me to edit it in Tiled without decompressing it, so I set about looking into the two base-64 encoded compressed formats.  Unfortunately, my cross-platform solution for compression in Unity3d, 7-zip’s LZMA SDK, does not support either gzip or zlib compression.  I didn’t want to write compression/decompression code (although it would have been fun), so on Sunday night, I set about looking around for some C# implementations of either gzip or zlib. I found a few but ended up settling, at least for now, on ZLIB .NET which has a BSD license. When compiled, you end up with a 64kB dll that will compress/decompress zlib data. I will probably go back later and setup my 7zip helper shim to work with either library but for now it all works rather nicely. By Monday afternoon I had a solution that would pull in a .tmx file, parse it, and instantiate tiles in the correct locations in Unity3d.

tiled
Level 1 of Buggers recreated in the Tiled map editor
unity3d
Level 1 of Buggers loaded from the level1.tmx Tiled file

 

The next thing to do is refactor the game code for buggers to utilize a single unity3d scene instead of loading a scene for each level, and that along with modifications/fixes to my Tiled loader is what I will be working on today.

If you haven’t read my previous blog post I suggest you do so. This month’s game will be a remake of a game called Buggers! which I did for Ludum Dare 26.  My plan is to convert the existing code over to my new framework, update the graphics, add joystick support, more game play elements, a high score list, more levels, and investigate a 2-player mode. This month is a bit of an exception since I started working on this remake before I came up with the idea of 6 games in 6 months on 5 platforms (6-6-5). My first commit of the new Buggers was Jan 26, but I think I started work on it around Jan 24 or so. I have done a first pass at updating the graphics and have already ported most of the old code to my new framework. Here is a before/after comparison graphically:

Buggers-pre-remake
The original Buggers
Buggers! Remake
Buggers! Now in color!

As you can see in the remake screenshot, I’ve also started working on getting some controls ready for a mobile version. I was fiddling with different ways to implement touch controls and only today settled on using Unity’s Cross Platform Input package with a few tweaks (check out this video for a tutorial).   One of the things I worked on for quite a while for my previous two commercial releases (Terra Forma and Roboticon) was UI sizing/scaling.  I’m hoping to get the same or better results with less complicated code and setup. So far things are looking OK, but I have yet to test on any of my Android devices proper or on iOS/Mac in general.  I’ve added “check UI scaling/sizing” to my monthly todo list so I’ll be looking into it more.  Hopefully I can find a set of general practices that will make the UI scaling/sizing easier each time I do a new game. Until tomorrow…

In an effort to make Pixelbyte Studios more visible and to challenge myself,  I’m announcing the game-a-month plan. Kind of like the meal plans at school, only tastier.  Between February 2016 and July2016, I will be releasing one free game every month. I have some rules for this experiment:

  1. The latest non-beta version of Unity3d must be used.
  2. Announce the next game and its idea at the beginning of the month (Except for February which I’ll announce today).
  3. Release games at the end of the month (some platforms might release later depending on store approval times).
  4. The games will be released on PC, Mac, maybe Linux,  Android, and iOS (iOS will be dependent on how well Unity’s IL2CPP works).
  5. I can only use material/ideas from my 20 previous Ludum Dare competition entries and any other unfinished prototypes I have laying around.
  6. I can optionally put Ads and/or In-App purchases  in the games if I have the time.  (I probably won’t)
  7. Each game should somehow advertise the availability of the previous ones for marketing purposes. Hopefully I can come up with something good here, but this may be difficult.
  8. Weekly (or maybe daily Monday-Friday) text or video blogs about the progress. I might also do some twitch streaming of development too if there is enough interest.
  9. Daily tweets on the current game project or unity-related tips/tricks.
  10. The game content must adhere to the Pixelbyte Studios family-friendly policy.

Some notes:

  • I may have trouble with the iOS and Mac store releases since they are more time consuming than the others. Plus, Mac OS is not something I use daily (I am installing El Capitan as I write this).
  • I’m going to keep the option of releasing the Mac builds directly on itch.io if the Mac App Store takes too long.
  • I suspect that gathering screenshots and other media for release to stores will be quite time-consuming. Hopefully through this I can come up with some time-saving software utilities.
  • Yes I do know about the One Game a Month initiative, but it doesn’t fit for what I want to do.
  • One of my other goals will be to come up with a way to do in-game polls asking users what extra or different things they would like to see in the games. This might be too much for my constraints but I still want to try it.
  • I will be participating in the Ludum Dare game jams, but I’m not sure how that will look. I’ll cross that bridge when it comes.
  • I will keep a Google Keep TODO list of my daily tasks and also one for my monthly tasks (mainly releasing the binaries to various stores). Ideally I would this to be publicly-viewable so I’ll look into alternatives like Trello.

Well, as I’m finishing up this post, El Capitan has downloaded and has begun installing on my Mac. Oh man. I have to download and install the new Unity3d tools on it too. So much to do and so little time.

Social media & sharing icons powered by UltimatelySocial