Restricting Camera Movement & Invisible Generators

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.

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

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...

"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:

1. 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.  
2. 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.
3. 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.
4. 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!

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

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

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.