I have been sleeping on an idea i''ve had for a week now. It involves a 2D tile engine, wait, it is a 2D tile engine. I figured out a theoritically pretty efficient way of handling a complex and highly scriptable tile engine that would allow for anything from Pac Man to those Program the Robot puzzles in Dr. Brain to those games where u walk around searching for artifacts and killing monsters. So any 2D tile world where gravity is not an issue can be created using this engine (of course if u have an RPG or something, ur gonna need some extra code, this isnt a whole game creator). I am thinkng about seriously writing this. It would be an engine, plain and simple, and then using the powerful scripting language and tile definition tools, many games can be created really quickly, all of them drastically different. Here''s a quick idea of what I have, however im not gonna reveal how i intend to do this just yet, that''s my problem. Plus this just might be an original idea, though i highly doubt it. I have basically reversed the thinking process of how most ppl do tiles. Instead of saying "I can have many tiles on the grid that are of the same type", i say "I can have the same tile on many places on the grid". You''re probably scratching your head wondering what the heck I''m on, but believe me, it makes sense. Through this concept, I can have large detailed tile structures with many properties while using only a teeny tiny amount of memory. Hell, a version of this with low res graphics and small worlds (50x50 tiles) could work as a DOS program, fitting snuggly in the 640KB of memory. Each tile PLACEMENT takes up 2 bytes. Note that this is different than saying that each tile takes up 2 bytes. A tile will take probably 20-100 bytes depending on how complex i make the system. A maximum of 35000 (other values are reserved, hence the rounding) tiles can be created, but i would be surprised if a game ever needed more than 200. Now you might be thinking, ok, the fool made it so all the water tiles on the map are one tile, all floors another, but what if there are switches? If one switch is manipulated, they would all be? Nope, not how I''m doing it. Each tile placement can still be manipulated individually. A map could have 20 switches, and only require 80 bytes of memory, yet each switch could have a totally different effect. Anyway, the engine promises to be really powerful, however it would result in a map editor that might become as difficult to learn as 3D level editors for games like Quake. Now i need ideas for tile properties, objects taht can react with tiles, etc. Nothing too concrete, i dont want suggestions like "ice tile", however something like "slippery tiles" is okay. I want as many properties as possible, preferably ones that require a single bit to store, but something more complex is okay too,.

I''m not sure what you''re trying to say here. If you are going to store the map as an array of 16 bit ints, each one indexing a tile in a tile list, then that idea is pretty much the typical way of doing tile games. You also can create the tile required by mixing several types (e.g. forest fades into grassland fades into desert etc.). I think there are several articles about this on this site.

I came up with that idea 6 years ago (I was 15) for Cradle Quest 1 which I did in QuickBASIC. I also invented the smooth scroll. I figured it out by playing Super Mario Bros and reasoning how it worked. I also had a book with a demo that enlarged text by scanning an area for pixels and drawing larger rectangles at another location. I took it from there. I made it so that different colored pixels drew different rectangles. I didn''t think to use matracies until a few years later when I ported the game to the TI-85. The map was actually drawn on the screen then erased prior to the flip so the player never sees it.

I use the same technique today for my current ISO project. The data format is far different but it''s the same concept. And it''s in C++.

Good job on figuring it out though. It''s more impressive to reason it out than ask for tutorials.

Ben
http://therabbithole.redback.inficad.com

quote:Original post by Anonypous Moster

I''m not sure what you''re trying to say here. If you are going to store the map as an array of 16 bit ints, each one indexing a tile in a tile list, then that idea is pretty much the typical way of doing tile games. You also can create the tile required by mixing several types (e.g. forest fades into grassland fades into desert etc.). I think there are several articles about this on this site.

That''s the manipulation style that it manages, but the concept behind it is a bit different then the simple straight index tile to list. I think KalvinB knows what im getting at.

Well, I might as well explain this a bit more, and see what you guys think then (i was too lazy to type it up before ) I was thinking of how in Windows you can create string tables in resource files. The main reason for this is the ability to easily translate an application into a different language later. It has a side effect however: if you have a string like your company name, and you use it in several places in the application, you only need to waste space on the string once, and then the rest of the time you only have a (4 byte i think) reference to the string in the string table. While a few bytes don''t make much difference, if you look at the ratio of memory saved, it''s quite large savings. This just kinda popped into my head cuz i happened to be thinking, which I do quite often late at night.

Next I thought of how all 2D tile based games are the same, there really isn''t that much variety. A single tile engine could be used at the very least as a basis for anything from PacMan to those search for treasure games to even WarCraft II. I was particularly thinking of the puzzle type games, where you walk around flipping switches and pushing blocks and stuff trying to get from point a to point b. In that kind of game different tiles have different affects on other tiles. Many games like this hard code in all the tile effects, but i really hate that since it results in no expansion possiblities, often messy/buggy code, and overall disorganization. But when you look at the effects that u want ur tile to have, it''s often a 1 or several basic things. In fact, what it comes down to is the equivilent of switching tile properties. But 20 byte tiles are a no no.

The system I thought of works a bit different. First some vocabulary:

Tile: this is a 2 byte reference to a particular tile definition.

World: a 2D array of Tiles.

Tile Definition: a 20 or so byte (actually I can get it down to less, but I''ll say 20 for now) that defines a tile''s properties/graphics/etc.

Since each Tile is 2 bytes, there can be a maxium of 65 536 Tile Definitions, but a round off to 65 000 (thus freeing first 536 bytes for future neat tricks) is what I chose. That means that the bulk of the tile data can take a maximum of 1 300 000 bytes (about a megabyte). A game will realistically have between 20 and 2000 tiles, meaning 400 to 40 000 bytes of memory (approximately 0.39 to 39KB) taken up by a highly versatile tile definition database. Hardly anything by today''s standards. Okay, now let''s create a simple Tile Definition structure:

***************
- graphicID
- walkable
- slippery
- killsplayer
***************

This structure allows us to create tiles that are walls (make walkable falls), tiles that are normal floors, tiles that are slippery, and tiles that ccan kill a player. The latter three variables only need to be a bit long each, and i have further ideas for reducing how much space they take up even more. Now lets create 3 tile definitions. TD 1 is a wall, TD 2 is a floor, and TD 3 is spikes. You can figure out their properties yourself.
Now lets see what this engine allows us to do in run-time. Say the player steps on a floor tile that happens to be a secret switch (ill explain how this element is added without another TD later). Now we want this switch to make a certain spike tile into a wall tile. All that has to happen is the Tile has to be changed from 3 to 1. Hmm, simple enough. Now say the player does something else that triggers an event. This time you want to turn the entire floor into ice for 20 seconds. The previous method is rather sucky for this. Instead we can change the TD of the floor itself, and make slippery be true, and maybe also change the graphicID to be an ice tile. Suddenly all floor tiles are changed into ice without a noteworthy performance hit (we are changing 2 bytes, thats it)!

So how did i do the above changes? It''s not hard coded, it''s done through a script! All tile property changes are scripted. Furthermore, the trap door i mentioned above is done through events. Basically, if i specify in the script that i want the floor tile at x,y to generate event # then it does. And in that event number, i put in the script code to change the spikes into a nice safe floor.

There will also be objects (stuff like treasure, keys, etc), players (the player, duh!), and creatures (which can be assigned one of several AIs or be have a AI scripted specifacally just for it). All these things can be altered using the script language i would write.

I think this will result in a system that uses little memory and keeps system requirements dependent on few factors (mainly amount of tiles and creatures, not complexity of tile code itself), so if ur computer can run one level in the game (assuming the game always uses levels of about the same size), it can probably run any level, no matter how complex later levels in the game get.

Sorry for the long post but hopefully this will clarify what I''m doing. Please comment and suggest tile properties.

quote:Original post by Tyrian

I''m sure there are a few tile engines that use references similar to your idea, but give it a go anyway, and did you imply that you would use a resource file to store your graphics? How about using Icons( just a thought)? Also, make the tile types a bit more generic such as Blocked, Walkable, Under, Layer(n ) and Special. This way you can have your script provide the special properties and layers.

No, graphics will be stored in a highly compressed image format, possibly of my own designing. Tiles need a lot of fundamental properties to make this work good. More versatile. and i have a tonne of memory cuz of the way this is designed

quote:Original post by sbrown

So are you saying you store the image of a tile with reference to the tiles properties in some place and then reference both the picture and the properties together? (as opposed to having a huge array where each tile has an image and properties)?

Isn''t this the way tile engines are normally done?

No
The graphic ID is part of the Tile Definition
read what i wrote several times, maybe it will make some sense, im having trouble expressing myself :/
Most of the plans are in my head, and they can fill up half a book already, so it''s hard to summarize. Im sure this method has been used before, but i hav enever seen it in tutorials or anything. Bascically it''s an efficient way of managing and using tiles that drastically reduces memory usage and can allow a lot of speed and versatility if implemented right.

That is the way all tile engines should be done. All professional ones are. There may be a newbie out here and there that hasn''t figured it out yet.

Also you won''t have tons of memory. Your tiles may be compressed on disk but in memory they''re not. You might as well keep them as BMPs unless you plan on decompressing on the fly during render. The only advantage to compressing on disk in your own format is keeping them from being edited.

The only ways to save video memory are to shrink your tiles, use a lower resolution, and or/use less colors.

Ben
http://therabbithole.redback.inficad.com

quote:Original post by KalvinB

That is the way all tile engines should be done. All professional ones are. There may be a newbie out here and there that hasn''t figured it out yet.

Also you won''t have tons of memory. Your tiles may be compressed on disk but in memory they''re not. You might as well keep them as BMPs unless you plan on decompressing on the fly during render. The only advantage to compressing on disk in your own format is keeping them from being edited.

The only ways to save video memory are to shrink your tiles, use a lower resolution, and or/use less colors.

YOu have a point about the BMPs, except that they do increase the hard disk space of a game alot, and when a person has a lot of games installed, they should do some work to keep themselves small (the games).

As for the tonnes of memory comment, i stand by it. I have done a lot of calculations, and the amount of memory the tiles take up is nothing compared to graphics/sound buffers/etc

compare 4MB of images to 100KB of tile data

I don''t suppose u know of any particulary good articles on creating script compilers/parsers? im not familiar in that field, and i dont wanna screw this up.