Tile-Based Build/Exploration Game DevBlog 5

You can find the last blog here:Tile-Based Build/Exploration Game DevBlog 4

This week the project has gone through a myriad of changes, many of which have completely changed the design of the game moving forward. In this blog I'll review some of the bigger challenges I've had to face and how I'm overcoming them. While finally coming to conclusions about the size constraints of 'Biomes' loading into a World, some interesting new ideas have come to light and are being implemented.

Updates:(build 071.2)

• Tile Orientation working for 'top' or 'bottom' tiles on initial creation!
• Biome loading/unloading has been fully tested.


• 'Biomes' are now 'Planets'.
• Planets load in as a giant CompositeSprite.
• Terrain is now 'drawn' into one Planet body.
• Planet 'contents' positions can be configured with one variable(super powerful).
• Planets now draw surface terrain as well as cavern(underground).
• Planet noise algorithms have been adjusted (smoother look).
• Planet boundaries now load in with Planet.
• Planets now use varied tileset depending on 'type' randomly chosen.
• New trigger system updates Planet 'contents' as player moves.
• New Resources Pane keeps track of collected items!
• Some new fonts!

The 2 Major Goals - Final Conclusion
Alright, it's been a long time coming but I believe I have potentially put these 2 biggest problems to rest. Let's take a look, for anyone who may be following along:

Tile Orientation: I may have been trying to approach the logic for this in the wrong way. Now I am having the tiles render on initial creation, and depending on position they will render a top or bottom tile. This system right now only accounts for the tiles drawn directly on the terrain 'lines' but for initial creation this may end up being all I'll need. This particular problem is multi-faceted, since tiles are not only created initially, but as a player places them as well. This means that the placement of each tile needs to be handled on a case by case basis (i.e. on initial creation, and also when a player places a tile). For now, due to the new way of creating a Planet body and 'drawing' terrain lines into it, the initial creation part is halfway solved and the rest is workable (side tiles)! Here you can see the grass showing on the top tiles:



Biome Loading: This has been a thorn in my side ever since the project began. I've had many ideas, theories, and questions all wrapped up into one big jumble of noob-learning-goodness around this topic. Finally, after trying many different ways, I have ultimately found the way I will handle this problem! First off, it's worth mentioning that when I first theorized about this project Mich from GG suggested it may be a problem having a player constantly loading/unloading in tiles as he traveled. I trudged ever-forward, trying mightily to figure out a way(if any at all existed) to make this happen. Ultimately, I did get it to work. I had a simple collision trigger that would render the next compositeSprite in the direction the player was moving. Even had each compositeSprite contain its own randomly generated 'goodies' (terrain, npc, critters, enemies, backdrop, etc). But ol' Mich was right, after all, that popping in and out those 'bodies' was causing a hitch. And yes, depending on the size of the 'body' the hitch would be more or less significant.

So what to do? How do you load in stuff? Well, after testing many different compositeSprite sizes I've found 2 ways. The first way, you have to create very small compositeSprite 'bodies' and have them load in with triggers. If they are small enough, they will pop in without a noticeable hitch. This would mean those 'bodies' need to be out of sight. The problem with this is that 'small' here is very small meaning like 20x20 or less, and you need to create and configure each of those 'bodies' separately (that's quite a bit of work take my word for it). You can of course set up global positioning variables and have the whole works build off of that when each new 'body' is created, but that's still a lot to make working at 20 blocks a shot: composite .taml, any potential noise files(terrain line generation), and also input scripts and listeners for each(you can potentially condense the input).

The second way basically abandons the loading in of new compositeSprite 'bodies' altogether (almost). Basically you don't do it with little compositeSprites; you do it with big ones. Create the largest compositeSprite you can muster up without killing Torque, draw in the terrain tile information with scripts/behaviors, and if you want another huge 'body' later there's just going to be a small load time associated with that. I've found that this is more than enough for what I'm trying to do, and if you are familiar with games like Terraria you understand that this is not how they have handled this. In my case, though, this design is actually working out to be precisely what I am needing.

This has allowed me to expand on my previous ideas of planet exploration for the game. A player can land in on a new planet, load in the huge compositeSprite, explore it, and take off. If the player wanted to explore farther off on any planet's surface he would have the option to suffer a short load time and generate it. Only then would all the new 'body' and input listeners etc. be needed. By design, in my game I don't think a player is going to be wanting to generate this big mass anyhow. They'll hit the surface, get what they need, and be on about their business. Using this method, the player will always have a rather large planet to explore initially and we can 'paint in' more if necessary. While this may not be the way I had initially envisioned it being solved, I am now moving forward nonetheless and considering this issue closed.

Note:It should be noted that I'm not just generating a huge square compositeSprite. I'm creating a huge square compositeSprite initially, and then by use of scripts and behaviors I am extending the bounds of that compositeSprite object to the left and to the right. This basically makes it so that the compositeSprite is very wide but not as tall.

Trigger System
This has proven to be very important for each Planet created. Sure, I could load in a huge compositeSprite but then what? If I populate that whole thing with sprites I am going to start having problems with performance. Never fear, here come triggers to save the day! Just by setting up some collision lines for the player to bump into, I can now just have that collision call to generate nearby 'stuff'. This could be anything from trees to an NPC, whatever. This is pretty cool stuff, so basically the player controls what is on any planet by generating it as he moves. This is akin to the generation of compositeSprites I was doing during testing of those, but here it's only adding or removing much less data. Good stuff here!

Resources Pane
The project is finally beginning to 'come to life' as the player can now interact with the world, accumulate resources, and have those resources stored and displayed in the new Resources pane! The Resources pane is still a work in progress since there is a lot to display and keep track of here, but it's functional in that it will show how many of %item you've collected. If you have none, it won't show. Each %item is an object with an image, name, value, quantity, and other potential information put onto a dynamic button. The %item (buttons) are put into a scroll container and used to display information about each %item.

Conclusion
Well there you have it! This week's blog update about my game! If you've followed along up to this point, you'll know that I've come quite a ways in a couple months. Moving forward, as usual, I have set my sights on some general goals to keep my randomness somewhat contained:

• More, more, more GUI elements.
• More resources.
• More tilesets.
• More planet props.
• Theorize about classes.
• Theorize about skills.
• Theorize about equipment.
• Take a closer look at persistence.
• Improve NPC, Critter, Enemy behaviors.
• New animations.
• Still need to take a closer look at sound.

As you can see here, my goals are starting to lean more towards the 'creative' side and that makes me very happy! Anything I add will, of course, require certain scripts and GUI elements or what-have-you but overall I'm starting to get a good 'base' to build off of now! Cheers and stay tuned!