Seven Essential Elements of a Tile Based Rendering Engine

In looking over my old articles and attempting to determine just how to revamp them (they are in pretty sorry shape, sadly), I also wound up thinking about my first book (which covered the same topics and then some), and I came up with a rather distilled version of my first book: Seven Essential Elements of a Tile Based Engine.

Keep in mind that when I’m talking “engine” here, I’m strictly speaking of a RENDERING engine.

The first essential element is image management. It is absolutely essential to be able to refer to every image (sprite, tile or whatever, the difference is mainly semantic) by a simple id number, and I should be able to render that image onto any graphical context I wish, using only a single x and y value.  I should not have to do any sort of voodoo to get my warrior sprite to render on my isometric grass tile. i use the same x and y value, and they are correctly rendered with the feet of the warrior in the middle of the isometric tile, because the image manager loads this information from the image itself, as in the extended sprite templates.

The second essential element is a board, which represents the game world. In tile based games, there is almost invariably some sort of grid, be it square, isometric, hexagonal or whatever.  Within the grid are the objects that comprise the world.  Depending on need, the grid locations might be as simple as a bit or number, but may be rather complex lists of stacks of object existing within the grid, not to mention other aspects that describe the grid itself.

The third essential element is a plotter. Once you’ve got a board that abstractly represents the world and images that show what those abstract elements might look like, you need to be able to convert from a grid coordinate to a rendered coordinate.  For this element, we completely forget about the screen, and pretend that we can render the entire gameworld in an abstract worldspace.  The main issue solved here is that you may have a 8×8 grid of tiles that represents a game of reversi.  When I render grid location (0,0), what sort of spacial relationship will it have with grid location(1,0) or (0,1) in order for the graphics in each to render correctly?

The fourth essential element is a scroller, which has very little to do with graphics, and everything to do with math. A scroller takes the output of a plotter, which is a coordinate in an abstract and boundless worldspace, and converts it to a sceen coordinate.  In a game where the grid does not extend beyond the bounds of the screen, the scoller is of less importance, but the use of separate world and screen spaces still has value.

The fifth essential element is a mapper, which takes a screen coordinate and determines the grid location corresponding with it, typically for pointing device input.

The sixth essential element is a walker, which allows movement from one grid location to another grid location based on starting location and a direction of movement. Typically less important in square coordinate systems (as they are elementary), but in isometric and hexagonal grid systems, these can be quite useful.

The seventh essential element uses all of the other six, and is called a renderer.  It may redraw the entire screen each frame, or it may use dirty rectangles.  The important thing is that each update, it knows what grid locations need to be redrawn.

The above, if you were to sprinkle in a bunch of code dumps, would be my first book.

Old Articles for a New Book

I recently got two copies of a form email from John Hattan regarding two of my older articles still sitting there on GameDev.net:

http://www.gamedev.net/reference/articles/article747.asp

http://www.gamedev.net/reference/articles/article1122.asp

747 (my old isohex article) is around 10 years old, and 1122 (about a trick i do with sprite graphics) and is slightly less than 10 years old.

Both were pre-book, and the concepts in both were the foundations of my first book.

In fact, I would say that if I had not written those articles, I likely never would have written a book, would have never participated in the formation of Sweet.Oblivion, nor the successor GameDev.net.  So, these articles (especially 747) were written at a pivotal moment in my life.

I actually got paid $50 for 1122 by Gignews. 747 landed me the role of “isometric guy” for quite some time.

And both articles, as I read them now, are pretty much garbage.  747 uses pascal (PASCAL!) and 1122 uses ripped off SpriteLib graphics.

But! The folks at gamedev.net are looking for folks who to revamp their old articles for inclusion in a new book.  These are articles they would like revisions of for inclusion.

Which says something, I think, about the articles themselves.  If you read them now, they are badly out of date, but still have something to say, and still are useful.  10 years is a LOOOOOOONG time in computer land, especially internet land.

So, it looks like it is time to dust off those articles.  Plus, I am told that doing so will earn me a modest sum of money and a copy of the book.

Hey… why not?

Indiana Jones

I saw the new Indiana Jones movie last night.  I could do an old fashioned fanboy rant here, but I’ll spare you.  I’m certain that you can read those sorts of things elsewhere.

I will simply state that I didn’t like it, and that one of the reasons I did not like it is that I don’t feel it necessary to tie up all of the hanging threads of the original movie with a pretty pink bow.

I will continue to hallow Raiders of the Lost Ark as one of the worlds nigh perfect movies.  Temple of Doom has earned my respect on its own terms.  The other two movies, in my opinion, are lumped into the same category as all of the Highlander stuff after the original movie.

I also saw Iron Man, which I felt was pretty good, especially when it immediately follows Indiana Jones.

Running Season

I have a Rat Terrier, which is a fine smaller dog with a good temperament, but is a little hyper.  He’ll be three this summer.  His name is Porkchop.

Over the last three years, he has gone through a number of different chew toys.  We determined early on that any chew toy made of cloth or rope would last approximately 2.3 seconds.

His first year, we found a bone shaped piece of blue rubber at wal-mart that he couldn’t manage to destroy.  Sure, there were teethmarks in it, but it held up surprisingly well for an entire year.  Chances are, it would still be holding up to Porkchop’s abuse, but he lost it.  My guess is that he buried it somewhere.

We had a replacement blue bone, and that one got lost too.  Now we have a black bone, but after last year, he has chewed the ends down a bit.  I would have bought a new blue bone, but last time I was shopping for one, they no longer had them.

In any case, now that the weather is nicer, my dog likes to play fetch, so we enter what I call “Running Season”.  Each day, I throw the bone out into the middle of my yard fifty times or so.  Its sort of a competition… will my arm give out before the dog gets tired of running around?

When we first played this “game”, my arm would tire first.  Now, while my arm isn’t what it was by the end of last year just yet, I keep throwing until the dog quits, which with a high energy rat terrier can take a while.

By the end of summer, my dog will be totally buff, like he was last year.  He had gotten flabby over the winter.  Not as much fetch can be played when the snow is higher than the dog.  However, it did not keep him from playing fetch those few times we did during the winter when the snow with knee high.  He was a determined dog, too… digging trenches in order to find it.

Again, Rat Terrier is highly recommended.  Good with kids, doesn’t shed, easy to train, high energy, and kills vermin(so far a number of mice, moles, a bullfrog and a rabbit).