StepWood Games Development

Restricting Camera Movement & Invisible Generators

2011-08-27T03:51:00.003-04:00

There isn't too much in this release. I added a bounds check to the engine so that the camera won't leave the map. I've also put in 3 ghost generators that run a script to pop ghosts into the map every 2, 4, and 5 seconds respectively.

Besides the restriction on the camera, there was some general cleanup and bug fixes in the code which aren't obvious at first glance. For instance, the map was offset by 8 pixels (half of the block size of the map) due to some math errors on my part.

I want to give a big call out to the author of Orthello for a great product. In addition to a very good framework that costs nothing to get started with, the support turn around time has been incredible. I really am looking forward to the release of the professional edition of the tool and the later components as time goes on.

I'll continue plodding along on the game one day at a time. I hope tomorrow to smooth out my movement a bit (anyone notice that diagonal movement is faster than vertical or horizontal movement?) and maybe add an arrow you can shoot. We'll see what inspires me next.

You can find my "EnemyGenerator" script on the Free Stuff page of the blog.

As always, the demo can be found by clicking "read more" below.

Ouch, running into walls hurts.

2011-08-25T00:54:00.002-04:00

I decided to look into collisions again, and decided that for this game a true physics based solution was a bit of an overkill. So, instead, before objects move, they "Sweep" their collision volume ahead of them and try to see if it runs into anything. If it does, then they cut their movement short (or attempt to slide).

You should be able to run around and not leave the map area. The ghosts should also act as barriers to themselves (not likely to be seen) and the player.

It isn't much, but it's a start!

I've also noticed that my "TMX Map" solution is way too slow. It drops the FPS from ~500 to ~50. That's no good. I think it has to do with creating a GameObject per grid location in the map. I'll have to look into optimizing that next or the game won't be very responsive. :)

I've added a fragment of the code that does the static collision test. It isn't anything super great, but it gives you an approach to doing collision that is more in control of the scripting engine versus the PhysX engine. It's basically sweeping the collider ahead to see if there is a collision and then changing the walk vector apporpriately. I have a set of options that an object can do by overriding the "HitOther" method and returning a value from the enumeration.

It's not anything super, but I figured it might be of interest to someone that is struggling with their own collision code in a 2d game.

You can find the fragment of code on the Free Stuff page.

Enjoy the demo by clicking on the "read more" link!

Struggling with Collisions

2011-08-24T01:25:00.000-04:00

Just so that people don't think I've abandoned this project, I wanted to post on what I've been doing. Once I got the tile map up and in place, I wanted to handle collisions with the walls. I managed to modify my TMX parser to handle my "collision layer" and build the collision volumes for each wall. I got a collision volume on my main player, great! And then the trouble started...

I can get the "OnTriggerEnter" message (or the corresponding method from Orthello) to fire, but I'm having difficulty with the math that will stop the penetration from happening and back the sprite up.

In other words, I can detect that the wall was hit, but I haven't so far been able to get the player to not walk over the top of it. My last attempt was to avoid using rigid bodies and just start doing ray casts when I want to move. However, I think to do that correctly, I'd have to cast 3 rays (from the outside edges of my collision box).

It's getting late now, so I'm going to attack it again with a fresh pair of eyes tomorrow. Sometimes, you just have to claim defeat and rest.

The archer enters the dungeon...

2011-08-20T02:23:00.001-04:00

"Tomorrow seems like a good time to add a single enemy and a projectile." Or not to. I decided instead to work on getting the archer on a more interesting "map" than a purple dot. I didn't get quite as far as I would have liked. My goal for today was to have the archer be able to be placed into a map and walk around it with collisions, etc. I got the first part, but sadly, I didn't get to the collision detection routines.

The background is now built with a normal OTSpriteSheet and a TMX file created by Tiled. Marrying the two of them together was an exercise, but resulted in a new script for unity called TmxMap. It is in charge of creating the children sprites that make up the background map and associating the tile set in the TMX file with an OTContainer that satisfies that tile set.

That last part was a bit tricky for me, but I learned a bit about how to extend the Unity3d editor in the process. Now, during the processing of the TMX file, I build a list of the tile sets. The editor shows those to you and lets you associate a tile set in the TMX file with an OTContainer object. Ideally, those were both built using the same graphical image.

Things I learned after lots of frustration:

Xsd.exe has some serious limitations. Luckily, it creates source code, so you can edit the generated code when you are done. Not so luckily, when you edit it incorrectly, debugging XmlSerializer.Deserialize can be a very tedious and frustrating experience.
Dictionary won't be saved in Unity3d. It just won't do it. This saddened me, since my use case was a simple look up of name -> OTContainer which fits a Dictionary object perfectly.
List does save in Unity3d. Since the number of tile sets in a TMX should be small, iterating over the list isn't a huge issue. It just hurts my feelings to have to either do an O(n) operation or create a temporary Dictionary for look up purposes.
The GUI functions in Unity3d are odd. I'm not used to an 'inline' GUI system, so I'm still getting used to it. I am starting to see the light with it, slowly.

That's about it. If you want to walk around a "dungeon", click the read more link below and let yourself be magically transported into a land where walls have no substance and the bounds of the earth are limitless. (Meaning don't expect any collision detection, okay?)

Oh, and the Smurf movie was pretty good. Yup, I enjoyed it even as predictable as it was. It didn't destroy my childhood like some other reviewers are saying. I wouldn't give it a 10, but it was a fun 5 or 6 for sure.

The Archer Lives!

2011-08-19T02:31:00.003-04:00

Another fruitful day learning Unity has brought me to the point that we have player input! In the new demo, you can move the archer with the arrow keys and press left control to shoot. (There isn't a projectile yet).

The background is only there so you can see that the archer is moving. We are also using Orthello's really cool "camera tracking" trick to keep the archer in the center of the screen when we move.

I did a small update to the "Sparrow" package mentioned in other blog posts. I noticed that the FPS wasn't being set properly on the animations that were being created by the SparrowSpriteSheet behavior. It now has a FPS setting that it populates to the various animations it creates. You can find the links on the "Free Stuff" page.

May not seem like much, but we are making progress towards the game. Tomorrow seems like a good time to add a single enemy and a projectile.

As before, to see the demo, click on the read more link.

Fixed Sprite Positioning

2011-08-18T14:35:00.003-04:00

I've fixed the sprite positioning problem with my sparrow package for Orthello. It amounted to the fact that the pivot point was based on a -.5 -> .5 Cartesian coordinate system, and I was expecting it to be a 0 -> 1 system. Easy enough fix to do by just adding .5 to x and y. But, it was still jumping in the Y direction. I then realized that the offsets I had were in standard image coordinates which has the positive Y pointing "down the image". A simple negation later and everything was good.

In addition to uploading the new animation test demo showing it working, I've also uploaded the files in question. I've provided it as both a zip file and a unity package for you to import and use! I've licensed the files for this under the MIT license, so enjoy them.

To use the package, start with Texture Packer. Create a new project and import all your images that represent the various frames of animation to the project. Select "Sparrow" from Data Format and say yes to the Sparrow 1.2 dialog. Put in the data file name and then change any additional settings you want to (including the name of the resulting texture file).

Once you are done with that, save the project and then publish it. That will generate the 2 files you need (a texture file and an xml file).

Once in Unity3d, make sure you have imported both Orthello (available in the asset store for free) and Orthello - Sparrow into your scene. Copy the texture and xml file into the asset folder of your unity project. Then add a SparrowSpriteSheet to the scene. Change the "Sprite Sheet" to the texture that was generated from Texture Mapper. Set the "Sparrow Xml File" property to the text asset that is the Sparrow XML file. Now, add a SparrowGameObject to the scene and select the animation for it (which will auto select the proper container too).

Download "Orthello - Sparrow.unitypackage" by clicking here.
Download "Orthello - Sparrow.zip" by clicking here.

Once again, to see the demo, click on the read more link.

Demo of Orthello Modifications

2011-08-17T15:19:00.006-04:00

Seeing something is always better than reading about it, so I figured I'd start today by posting a web demo of what I've done so far. It's still very rough and you can see that the images are still "jittering" around during the animation playback. I guess my math is still off a bit on the re-positioning of the sprites.

Click the link to read more to see the demo page.

Thumbdrives and Code Generators

2011-08-17T15:06:00.010-04:00

For nearly nine months now I've been working on porting the classic rogue-like called Moria to the Android platform. During that time, I've kept the most recent code on a USB thumbdrive for the simple sake of development convenience. (Don't worry, I also kept it in the company's source control system.) This pattern worked very well and allowed me to work on nearly any computer I had available and with or without any network access... Until the thumbdrive died.

I spent a pretty serious day of trying to rescue the latest code off of a thumbdrive that no operating system or computer I could find would even admit was plugged in. What it got me was sadder and sadder about the code lost in the gap between my last checkin and what was on that thumbdrive. Eventually, including the disassembly of the thumbdrive and at one point the use of a soldering iron, I gave up. The data was lost and there was nothing I could do about it.

Naturally this left me thinking about what I had lost. I realized that most of what I'd lost I kept referring to as "monkey work" since it was repetitive and boring and involved a LOT of code. Having only missed a single day of coding lost me an amazing 40k of code and I wanted it back, but I didn't want to be the one to have to code it. This finally caused an "ah ha moment" that led me to the creation of a simple web page based code generator.

I chose to use HTML and JavaScript because it was simply the fastest way I could think of to get this generator done. After pretty close to exactly 4 hours of work, my code generator could read a list of class local variables and produce code for a complete constructor, a toString() method, the complete implementation of IMoriaSerializable (six functions, at least two of which represent the biggest part of the lost code), and a tester method for verifying the serialization worked as expected. This meant that what took me 8 to 10 hours to produce the first time, was now back in the code base with increased consistency and with an admittedly better set of tester functions, in less than 5 hours. Which was only really that long due to making minor tweaks to the generator.

Statistically speaking the benefits here are far more impressive than at first glance. The original 8 to 10 hours was to produce the additional functionality for a mere 4 classes out of the nearly 40 that will eventually need it. By that logic, it would seem I was looking at roughly 80 to 100 hours of tedious monkey work development to be complete. After the creation of the code generator however, and with a turn around time for each new class of less than 5 minutes, the entire collection of classes could be completed in something like 8 total hours (including the creation of the generator.)

Coding professors everywhere will tell you that if you need to do something more than once it's a good idea to turn it into a function. What they don't mention is that if you have to write dozens or hundreds of functions that follow a specific pattern, it's a good idea to write a code generator to do it for you instead.

Combining Orthello and Texture Packer

2011-08-17T03:23:00.003-04:00

After a day of futzing with things I have a very good start on using Orthello with Texture Packer. It isn't perfect yet, and the code needs some cleanup, but it's getting a bit late and I want to wrap it up for today.

The problem with using the two tools together is that Orthello requires (out of the box) that the frames in a given sprite sheet are fixed size and that the frame numbers are known so you can build animations from them. The advantage of a tool like Texture Packer starts to disappear under those conditions, so I wanted to marry the two tools together.

In order to do this, I needed a way to parse one of the multitude of data structures that Texture Packer writes to. I liked the look of the Sparrow XML the best, so I decided to use that one for my pairing of the tools.

I loaded up Texture Packer and generated a sprite sheet with a Sparrow format data output. After telling it that I was okay with "trimmed" sprites (which is one of the major reasons to do this!), I ended up with two files: spritesheet.xml and spritesheet.png. This was pretty cool, so now I had to devise a way to use the new XML file with Orthello.

I loaded the XML file into the MonoDevelop tool that comes with Unity and selected the Xml->Create Schema menu option to generate an approximate schema file for the xml data. I then proceeded to use the "xsd.exe" tool (located in your Unity installation directory under Editor\Data\Mono\lib\mono\2.0\xsd.exe) with the "/c" option to create a C# file that could parse the xml file. As expected, all the data members of the new C# class were "strings", so I changed a few of them to int so they were the correct data types. With this, I had the power to read in an xml file using XmlSerializer.

Now that I could read in the xml file, I needed some way to build the Orthello "container" that would hold the frames. I looked at how the OTSpriteSheet was doing things, and basically used it as a template to create my own SparrowSpriteSheet container object. It's job was to do 3 things:

Break the texture into the various "frames" that were available (similar to what OTSpriteSheet did) by using the data in the xml file.
Create a new set of OTAnimation classes that represented the animations in the sprite sheet so that I didn't have to do this by hand, and so that I didn't have to order the frames of animation in any particular order (more on this below).
Store some additional data from the xml file about frame sizes and offsets for later use when positioning and sizing the sprite.

Since Texture Packer has no clue about animations, I had to use a trick to be able to generate the OTAnimation classes. What I settled on was a naming convention for the files. Every source image file was named <AnimationName><FrameNumber>.png. The xml file stored these names, so I could pull that up when processing the frames. Once I broke apart the name, I could easily build animations from the xml data.

I went about renaming all the sources files (most of them already followed this convention, or something close to it) and then noticed another thing. Texture Packer doesn't handle converting background colors to transparent without the paid edition. I tried out the "Heuristic Mask" option, and found it to be lacking for my needs (and only available to me in a paid edition which is off limits for this project), so it was time to do some conversion. I started by loading the gimp and trying my hand at converting the background to alpha. While it was quite capable of doing the job, I was looking at over 1,000 source images to convert. That wasn't something I wanted to do by hand.

I pulled out ImageMagick and let it do it's thing. I wrapped the ImageMagick command to replace the color in the upper left of the image to a fully transparent color into a dos "for loop" and let it blast over all the files. If you are interested in the the ImageMagick command I ran, here it is:

convert sourcefile -alpha on -fill none -draw "color 0,0 replace" destinationfile

With that problem conquered, I ran the images through the Texture Packer again and worked on the SparrowSpriteSheet until it had the results I wanted. The only issue I had was that I had to track that the SparrowSpriteSheet "owned" the OTAnimation in question. With no way to do that directly, I extended the OTAnimation class (making a SparrowAnimation class) that could track that information.

Now, if parameters changed on the SparrowSpriteSheet, I could regenerate the animations intelligently and if the SparrowSpriteSheet ever disappeared, the animations would go with it.

I know had a working OTContainer to hold my frames, but unlike the previous version of OTSpriteSheet, the frames weren't the same size! Therefore, I had to modify the size property of the OTSprite every time a frame changed so that it didn't skew the sprite weirdly.

To do that, I created a new MonoBehavior called "ResizeSprite" that has a LateUpdate method. This method would call on the OTSprite component on the same GameObject and adjust it to match the new frames as they changed. This worked pretty well, and now I had sprites that were at least the right size approximately where they should be.

Why do I say approximate? Well, if you have sprites that are different sizes, then positioning the sprite gets a bit trickier. So, at this point, I had a sprite that "jumped" around a lot and didn't want to stick to one place. I decided to expand my ResizeSprite behavior to also modify the position of the sprite.

And therein I ran into a major issue. The only way I had to modify the sprite's drawing position was to either futz with the transform of the GameObject it was attached to, or rebuild the mesh with a new pivot point that would keep the relative position of the sprite the same.

I started to look at what it would take to do the second one, and decided to try my hand at the first instead. It wasn't too difficult, except that I noticed that while I was modifying the transform, so was OTSprite when you set the position of the sprite on the screen. There wasn't a good way I could find to have both of us control that transform for two different reasons and sort it all out.

In the end, I settled on a design decision. The GameObject with the OTSprite is going to be a "Child" of my real GameObject. Therefore, the position of the Player, Ghost, etc would be determined by the parent GameObject's transform, and the OTSprite transform is strictly my offset to keep the frames aligned.

I have this implemented, but I'm pretty sure I missed something in the math since there is a small amount of jitter I haven't gotten rid of yet. That's what I'll look into tomorrow!

Once I clean the files up a bit, I'll post them for other people to look over and comment on.

Learning Orthello

2011-08-16T15:31:00.001-04:00

Yesterday, I spent most of the day learning a bit about using Orthello in Unity. I did some trial runs and some work on various things and found out that there are some limitations to Orthello that will affect my pipeline.

The two main issues are that Orthello's sprite sheets are expecting that the sprites are all of the same dimension and that the animation definition uses raw frame numbers, requiring that I know exactly where a frame is in the sprite sheet.

These are issues with my pipeline due to the default operation of the tool Texture Packer. Typically, it trims the sprites to get rid of excess and then orders them in a manner on the page to allow it to optimize the use of the texture atlas.

My concept is to let Texture Packer do its work and export the data definitions into XML (using Sparrow's format). Then I'll parse the XML and tell Orthello where my frames where. Since I'm still working through the details of that implementation, I wanted to get this post up to explain the progress I've made so far. Hopefully, my next post will detail my solution to this problem.

Of Arrows and Bows

2011-08-14T23:00:00.001-04:00

Now that the artwork is decided upon, the monumental task of picking our tool set was upon us. This has been a major undertaking, and one that I spent months prior to starting this project looking over so I'd be prepared.

Summary of selected technology:
Unity Game Engine using Orthello as a 2D framework.
Tiled Tile Editor
Texture Packer
Gimp
ImageMagick

More details on my decision can be found by clicking below to read more.

Game Engines
There is always the option of writing a game engine from scratch. However, I decided against this option for this project, since the time required to get those things working would distract from the project itself. That doesn't mean there won't be issues using an "off the shelf" engine, but they are ones that I'm willing to work through.

I narrowed the list down to these engines:

Unity - This is a major rock star in the independent game scene. It handles porting your games to many platforms (including PS3 and Wii!) and has the power of an AAA game engine without the cost of one. They have a limited feature set available for free for the web, PC and Macintosh . That being said, it isn't a 100% free engine for all features or deployment options and if you are looking towards mobile, it will cost a pretty penny for a small development team. Other than that one small factor, it has a great support forum and a very active set of users willing to answer questions. This is the engine I've ultimately decided upon.
Cocos2D-x - This is a bit less of an "engine" and more of a C++ library for development of 2D games. I was willing to look at this one, but there was no clear way to develop the game for the web, so without removing that restriction I couldn't use it. However, for later projects that I'm mostly concerned with standalone or mobile games, this is a very strong contender.
Shiva 3D - I view this as the "big engine that could". It's a very versatile engine and lines up with Unity's feature set very closely. It also has a tremendous advantage - the price. For one cost, you get all the features of the engine and all platforms. The support forums aren't quite as active, but they are pretty quick to answer emails. They have a trial edition available for free, but no "100% free" option similar to Unity's. In the end, I had to discount them due to this fee since this project is a $0 video game project. However, I'd certainly look to Shiva in the future for projects I'm willing to invest in more.
Engine 001 - I was relatively excited about this engine. It is 100% free to start with and only a small subset of features are "subscription only". I know this engine would satisfy the needs of my game and probably make a game quicker than using the 3D engines above. The disadvantages were two fold. First is the subscription model. For a game that I'd like to have the ability to monetize on, a subscription model is not the best option. However, I was willing to overlook that and use the engine since they had a free edition. However, they have no web deployment option and that was something I couldn't live without.
Game Salad - Another 2D engine, and it got me very excited. Web development and iPhone development were available and it seems very easy to use. However, it was available only for Macintosh, and unfortunately I dont' have one of those at present. So, that threw them out.
Monkey - This framework for 2D games is a bit too lightweight at present to be of interest. There are a multitude of things that aren't supported as compared to its competition, but it is one to keep our eyes on. Created by the author of Blitz Max, it is certainly posed to become a very powerful system in time.
Game Maker - Decent game engine, and a trial edition is free. However there is no web option at present. There appears to be an HTML5 and even Android publishing option in the works, so it might be worth consideration later!
Flixel and Flashpunk - Both good libraries, but I didn't want to be limited to the flash platform.
AndEngine - Android specific library that looked good, but the LGPL makes it (in my opinion) all but useless on that platform for anything but free software (due to the lack of dynamic libraries)
E3Roid - Decent android specific library, but no web deployment option.

Many others were considered, but these were all on my top pick list at the time of selection.

2D Framework for Unity

With the use of a 3D engine that isn't optimized for 2D games, I decided that getting a framework that helps model 2D games would be helpful. I researched and found these options on Unity:

Orthello - A bright spot that was released very recently for Unity. It covers camera work, tracking 2D objects, 2D sprite displays, etc. 100% free for the basic functionality, and the author plans on releasing additional tools for the Orthello suite for small amounts of money. (Wish he had the tile map support already, but even if he did it looks like that will be included in the first "for pay" package for Orthello).
SpriteManager - The first 2D framework for unity that seems to have been developed. It was given to the community a while back and has basic sprite drawing functions (to drop the number of draw calls to one per texture atlas). A good option if Orthello doesn't work out.
SpriteManager2 - The grown up version of the free version. This has editors, tile map support, etc. Far more comprehensive than the prior two offerings, but with a price tag this project couldn't afford! Definitely look into this if you are looking at making a 2D game on Unity.
2D Toolkit - A very similar product to SpriteManager2 and at a comparatively low cost. But even it's cost is too much for a $0 project, so I had to overlook it.

Level Design Tools

I'm still working through this, but with the selection of Unity, I basically have two options:

Use the scene editor in unity directly.

Use Tiled Map Editor and write some C# code to bridge the 2D framework with the TMX file format.

I chose the 2nd one since it seems like the "right way" to do it, and I don't mind writing some C#.

Artwork and Image Manipulation

For free tools, ImageMagick and Gimp are hard to beat. I didn't really research beyond that, but if I was more of an artist then some of these might have been of interest: GrafX2 (Free) and Pro Motion (Commercial).

I'm pretty sure I'll use Microsoft Paint a bit too.

Spritesheet / TextureAtlas Generator

While you can use a normal image manipulation program to stitch together the images that compose animations for 2D into a spritesheet, having a program help you is much easier. I was surprised at the lack of these tools and examined a number of them. I won't comment on any of them since I found them all lacking significantly compared to the one I finally found: TexturePacker. There is no comparison unless you plan on writing your own. Once again, a free version of the tool is available and that is all we need for this project. The extra options in the paid version are likely worth it's very minimal cost for other projects.

And that rounds out my selection of tools.

Blue Archer's New Clothes...

2011-08-14T14:00:00.001-04:00

I spent a good part of yesterday looking over various pieces of artwork available for free on the internet that could satisfy the requirements of a Gauntlet clone.

My selections at this point in the project for the characters are from Reiner's Tilesets:

Blue Archer as the player character.
Ghost as the first enemy type.
Skel as the second enemy type.

For the dungeon walls and floors, I'm going to use various handpicked tiles from both Reiner's Tilesets and First Seed Material. (To be decided upon which ones during level construction).

Here are the other sites besides those two that I visited and looked over the resources. Any site that had dubious artwork or unclear licenses was ignored for this project. So, these all (as far as I can tell) have clear copyright licenses and legal ways of using the images in a project.

Sprite Works - Ignored since it was a paid library of images.
Various Artists Works - Ignored since most of those images were clearly marked "non commercial".

Here are some resources that aren't related to this project that might be of interest to people looking for video game art:

Svg Cards - This is a great set of playing cards we are using for another project.
Explosion Generator - This is a nice set of explosions and a generator to create more that could be used for something more space like, etc.

There are many other sites on the internet that have "sprite images", but many of those are ripped from games or are clearly copied art styles from copyrighted material. I've avoided them for this project and any others I work on, so I haven't listed them here.

If you are an artist and have another site where non copyrighted images are available for use for independent projects, feel free to contact me. I'd love to know about them!

Blue Archer Needs Coding Badly...

2011-08-14T12:17:00.001-04:00

I've decided to task myself with the development of a very simple version of the old Atari Classic - Gauntlet. To keep things small and interesting to others, here are the conditions that I've put myself under:

The development shouldn't take more than a month of on/off development, with an attempt to bring it together in a week or so of more concentrated development.
The cost of the entire project should be $0.
The project should be able to be sold commercially, but we are willing to allow additional fees to do this.
The project should be able to be run on the web for easy linkage to this blog.

A secondary concern would be a path to deploy the game on other platforms, especially Android. But that is outside the scope of this development effort, so consider it a bonus if the tools allow it.

Only one player type will be supported.
4 levels will be designed for some variety.
2 enemies will be battled against.

That's about it, stay tuned for details.