🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Iso Ideas!!

Started by
1 comment, last by thekid 24 years, 5 months ago
Hi, I already started an tilebased engine. I am using C/C++ with DirectX. Does anyone have any ideas for making a good tile engine. I will probably use square tiles with a top-down view. any ideas or examples would be appreciated!! Thanx The KID
Advertisement
I think the biggest advice I can give is to really go in depth with planning how the layers of your tile engine will get blitted. Tile organization can be a fine line between making your game look blocky or making it look so good that the player forgets he''s even SEEING tiles.
Usually, most people will first blit the base layer, then the fringe layer (trees and bushes and stuff), and then the object/NPC layer.
But now with computers as fast as they are, having like 8 or 10 layers of tile blitting isn''t unusual. It''s just a matter of deciding what would be drawn on top of what. Also, you may want to keep kind of a "backup" layer overtop of your player in case he walks under some trees or something. It just goes to show how tile organization is so important.
You might want to check out David Michael''s comments in this forum under the post "How to Render 2-3 Layers Of Tiles". He''s a whiz with the tile-based games (Artifact rocks) and his comments are always great ones.
I hope that helped.
I have found that a lot of information is available with regards to rendering the screen, moving around, even a few on object selection and file formats. What I think is really missing is the importance of whole-programme design. I''ve started and restarted a number of tile projects and ended up painting myself in the corner because I spent too much time thinking about how I was going to draw the tiles and not enough time thinking about how I was going to gather user input, manipulate the tiles and store object data. Keep in mind that the user, if he is using a mouse, will want to be able to walk with the mouse, click on objects and use them, click on buttons on the toolbar, etc. Additionally, you''ll want to be able to have multiple objects that look the same but might have different characteristics (eg. all blue potions use the same tile, but one is half full, the other is three-quarters full). What about game updates? How will you update data and how will you keep track of the age of certain objects (bodies on the ground should turn into bones, eventually). I really think spending some time and thinking about which modules need to know about which others is really important. If you are writing in C++, maybe think about base classes and implement those so that extending the game is easier in the future when you decide that your Map Dialog would look better if you subclassed it and spruced it up. I can''t stress the importance of looking at the whole picture at once from the start. You''ll save yourself a lot of headache. Even if you implement a function called LoadMap that doesn''t actually load the map, it sets the map to hard coded values, at least you only have to change the code in one place. Think about pointers and how you can use references to data instead of copies of data.

My guess, of course, is that most people think about these things before I do. But then .. it''s just about learning.

This topic is closed to new replies.

Advertisement