Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 21 Aug 2004
Offline Last Active Apr 15 2015 08:15 PM

Posts I've Made

In Topic: Best way of handling Auto-tiling?

04 March 2015 - 05:08 PM

Yeah, if you are making a game that is resource intensive then you may not want to do a multi-layered terrain approach. Every map we've made so far needed no more than three layers of tiles to create, so it's not as if we're abusing things and adding several more layers than needed. If you really want the simplicity of a layered drawing system + the performance of a single layer system, what you could do is render all of your tiles when a map loads so that you already have all of the terrain in a single layer. This might require a bit more video memory to hold all of these pre-rendered composite tiles however. But then again if your terrain is procedural and dynamic (can deform from battles, for example) then this approach probably won't work for you. It's hard to speculate on what the best solution would be for you without knowing more details about your title, target platform, system requirements, etc.

In Topic: Best way of handling Auto-tiling?

03 March 2015 - 08:02 PM

We have had a little experience with it. Here's some old documentation on how we originally went about handling transition tiles in our title: [LINK].


While in theory this sounds nice, it was really a pain to implement and support it. We've pretty much thrown away all support for this sort of programmable transition tile. We achieve the same effect now by simply using multiple tile layers and having transparency in several of our tiles that do the blending. Adding support to our editor to automatically detect the proper transition tiles and enter it accordingly is not worth the effort for us (we are a very small team of unpaid hobbyists). Instead, we focused on making our editor easy to use in other areas and add in the extra tiles necessary into our tilesets to achieve nice looking transitions.


Here's a long-ish video I released recently of several major changes that I made to our editor. You can kind of get an idea of how we build maps using tilesets, layers, and a feature we call "map contexts". If you're not interested in watching the whole thing, I would skim around and take a look at the different things we can do with it.




My opinion is that custom support for transition tiles in your editor/game is "nice to have", but probably shouldn't be a high priority. There's likely much more important things you can invest your teams time in, and I don't think adding any fancy transition tiles will save you much time in map design (at least not for a game like ours). But take my opinion with a grain of salt, as I haven't worked extensively with this sort of technology myself.

In Topic: Very basic 2D RPG game

13 February 2015 - 09:02 AM

Well typically 2D RPG maps are built using layers. A layer may contain either tiles or objects (sprites). Typically you don't want to have something like a house be an object, because such a large, static structure is better constructed using tiles (since you can change up the size and display of the house more easily that way). I'll give you a simplified explanation of the class modeling in my own RPG.


We have a class called MapMode which is the highest level class and implements the main loading, update and draw code. This class got really big in the past because there's so many different things it needs to do, so we decided to create some helper classes to it that are responsible for handling specific operations on the map. Two of these classes are called TileSupervisor, which manages everything having to do with tiles and tile layers, and the ObjectSupervisor, which manages all of the sprites and the map's collision grid. Naturally, our tile layers are managed by TileSupervisor while the object layers are managed by ObjectSupervisor. We can have any number of tile/object layers and their draw order can be arranged and re-arranged in any way we like, but for simplicity let's assume we'll always have 3 tile layers and 1 object layer.



Our map is built using several layers of tiles, where each layer is like a 2D array. The same tile image may be drawn in more than one location, so it's inefficient to store several copies of the images. The TileSupervisor class maintains a vector of tile images, and our layers are nothing more than integers that index into that vector to extract the desired image to draw. Now we could either create a 2D array for every tile, or we could create a single 2D array and store the layer information for all tiles in there. We went with the latter approach. The MapTile class is a very simple wrapper around a 1D vector. This vector contains the indexes into the tile images container for each tile layer. So if we wanted to draw a tile that was located at the X, Y position on the map for a layer Z, we would access the 2D array of MapTile objects, index the X, Y element of this array, extract the Zth element from the MapTile object, and use this integer to index into the tile images container to extract the image to draw.



Now let's talk about objects. We define a MapObject as an entity with an x, y position on the map that has a height and length property, indicating how large the object is. We also have other properties we can set for objects such as whether or not to draw the object if it is on the screen (visibility toggle). We have a base class called MapObject which is abstract and contains these common properties, as well as pure virtual functions for drawing and updating the object. We have a number of classes derive from MapObject to support different types of objects on a map.

  • PhysicalObject is a static object that does not move. A tree could be a physical object, for instance.
  • TreasureObject is derived from PhysicalObject and can be interacted with by the player to extract treasure contents.
  • VirtualSprite is a sprite (moving object) with no image. This serves both as a base class for other sprites, and can also be used as a map camera (our camera is always focused on a map object).
  • MapSprite implements NPCs and player-controlled sprites. They can have dialogs, be given movement commands, etc.
  • EnemySprite is derived from MapSprite and causes a battle to occur when it collides with the player controlled sprite.


The ObjectSupervisor maintains a vector of MapObjects for each object layer. When it's time to update the map, the code will go through and call the update function on every object to update their animations, change their position, perform collision detection, etc. To improve performance, we keep the objects in this container sorted based on their draw order (you want to draw objects on the screen from top to bottom). So when we call the draw function, we already have a draw-order sorted container of objects and can simply iterate through the container and draw each object that should be visible on the screen.




Hope that starts to get the gears moving in your head about how you can go about implementing tiles and objects and layers on a map. The map code for an RPG is probably the most complex piece of the game and it will take time and practice before things start to make sense. I didn't even get into other map aspects like dialogues, events, pathfinding, and so on. My project is reasonably well documented (certainly more so than most) and the code is open source, so you are welcome to study it and learn if you like.



Documents the design and structure of our map code. Somewhat incomplete, but covers the most important aspects.



Source code - main directory



Source code - map directory



You can also download it and run Doxygen on the source tree. This tool will build the API documentation and can also do things like construct class hierarchy diagrams to give you a better understanding of each piece of the code and how they all tie together. Again though, this is pretty complex and is definitely above the scope of what you're aiming to do with your project. Hope you find this information helpful.

In Topic: Very basic 2D RPG game

13 February 2015 - 07:51 AM

FYI, even a simple 2D RPG is quite an ambitious project and not very suitable for a beginner IMO. I was in the same position as you ten years ago and went ahead anyway. I suggest making an extremely basic game first and build up from there. Start small and work your way up instead of trying to add everything you need all at once. For example, your milestones could be something like this.


  • A single map that you can walk around in.
  • Add NPCs that randomly walk around the map
  • Add dialogue to the NPCs
  • Add random enemy encounters (with a very simple battle system where all you can do is select "Attack")
  • Add a basic character management menu
  • Add a second map


And so on. I'll second KnolanCross that if you just want to make a RPG, use one of those tools he listed above. You may think that coding a simple 2D RPG isn't that difficult, but it is. My project is currently hovering around 250K lines of code that were written (and re-written) over many years. If you want to make an RPG from scratch, be prepared for the enormous amount of time and effort it will take.

In Topic: Modern game development/programming for a not-quite beginner?

11 February 2015 - 09:47 PM

Maybe take a look at these courses:







They pretty much dive right in and you'll make simple clones of popular games like Asteroids. I think this would be a good way to both refresh yourself on the fundamentals of programming, get some experience making games again, and learn a popular new language in the process. I got about half of the first course a couple years ago to refresh myself on Python and I thought it was run very well.



C++ has evolved quite a bit, but as long as you still know how to do memory management and understand the basics of object oriented programming, it shouldn't be too difficult to pick up again. C# would more or less tie you to Windows. There's unofficial support to run the language on other systems, but I'm not sure about the effectiveness of writing C# applications for non-Windows systems.



If you're making a simple 2D clone to get some practice, using SDL or SMFL is a solid and reasonable choice. If you're planning to do anything really complex though, I would suggest using an existing game engine library instead of rolling your own.