This all looks jolly good. Let me know when you want the Steampuppy library

Cas

Assuming I get greenlit (or approved however steam will be doing it by then), I'd love to take a look at it when the time comes! How hard was it for your guys to write? If it's not too terribly complicated of a process I may attempt to write my own. Although I'd love to have an all-in-one package to get my game steam-ready. If I use it, I'll be sure to credit Puppy Games in whatever way is reasonable. Maybe I can push a few sales your way.

I've got the map maker starting to come together. Mostly GUI work, with a few tweaks here and there. You can now select layers, brush sizes and various terrains. Most of the basic tools work, like the eraser and grid tool. Hopefully I will have the entire editor completely ready to output maps for the game here in a few days. But I still have a few more complicated features to add. (Like a minimap, and the Dark Mode tool) So it may take longer than expected.

Map editor is almost ready to actually develop maps. I'm still hammering out the last few features (Like Undo/Redo, proper saving, the minimap and cleaning up the GUI) but now all terrain transitions are working for both light *and* dark texture variations, all the tools that are added work fluidly, it's all extremely easy to use! This scene in this screenshot was made in under a minute.

I'm planning to release the first tech demo as just the stand alone map maker, to let you guys test it out. Currently the map maker runs at 60FPS at 1080p on all the machines I've put it on, including my Ultrabook that only has IntelHD graphics. (Keep in mind, this editor is running within the game engine, so all the fancy lighting and shadow systems are working live/in real time!)

It's good that you've put so much effort (I think) into optimising the game so that it runs well (that means it should run on mine, as I have a HD graphics chip too).

That's one of the reasons I've been working on the Map Editor/Tile Engine for almost a week straight. My hope is that the final game will be a "run on anything" type of game, where people can stick it on their business/school laptops and play the game in their down time on the go. I'm not sure what specific intelHD chip you have, but here's the specs of the Ultrabook:

So at least as of now, if you have me beat (or have around that) you should get 60FPS as well.

I also have one more optimization I have to do, currently the map is made up of 7 layers. But if you place a tile on say, layer 4, and a tile exists on layer 3, it'll still render both tiles even if the tile on layer 3 is no longer visible. If I add a check to detect what tiles can completely cover the tiles below them and hide them in that event I can probably reduce the total tiles needing rendered on screen about 30-40% in a heavily decorated area with multiple layers of tiles all over the place.

I actually removed the FPS cap on the game and ran it on my desktop, without the latest tweak, in a maxed out area (all layers used) I get 190FPS.. With the tweak I get about 240. *But* it's not finished yet, as of now it just stops rendering any tile that's under another, even in the event that tile doesn't fully cover the tile below it. The final version of that optimizing will know the difference and know when is the appropriate time to hide the tile. But still, the ultrabook was running it at 60FPS without the tweak. So I'm already overjoyed! But I'd love to make it even faster, because other elements of the game will no doubt bog it down anyway.

Ah, that's where we differ a bit. Mine's only a 1.3GHz i5, but because my resolution is 1440x900 it might scrape through.

My best guess is you should be fine, because the biggest resource hog I have right now is rendering all the little 8x8 tiles. Because the game is an 8x8 tile based game, at full 1080p (operating at 640x360, since the game is scaled x3) there's up-to 3600 tiles per layer rendered on screen at once. At 1440x900 there would only be 2250 per layer.

The engine is rendered at a fixed 1:3 scale regardless of the resolution. So a bigger screen wont make the images larger, it'll just let you see more of the screen all at once. (Like the old Roller Coaster Tycoon games if you played them)

Not to mention I also haven't put in that last tweak yet that should greatly drop the amount of tiles needing rendered in complex environments.

- New terrains, including water!- The minimap is fully functional!- Terrain transitions complexity increased, now even more natural looking terrain can be quickly drawn.- Many GUI changes- Bunch of optimizing, the engine runs even faster now.- Untested, but should now be running on Macs.

That smooth shaping looks like the Terraria game, good job! Now I have to look up how to do this...

After making all the drawing all the required terrain transitions tiles, you have to setup a way to check the 8 tiles around the tile you placed when you place it and change that one tile accordingly, I did it by building a small string of numbers like, say this for example:

111111000..or.. when broken down it looks like this111111000

Basically every "1" is where a tile is the same terrain type as the one you just placed, every "0" is a empty spot, or an unmatching tile. Then, depending on the arrangement of the string of numbers (I used an int btw, not an actual String) you tell the engine what type of transition tile it should put there. Keep in mind the center "1" is your tile being checked. So in this case, it would of be converted to a down facing straight transition tile.

Where as something like this would have become a south west corner transition.:011011000

Eventually after you hammer out every single possible variation that could exist, and code in a very fast way to do the checks, you'll end up with what I have.

One critical step is to make a "no valid connection at all" terrain tile (note my little tree "dots" in the gif) because there will be some illegal transitions that are impossible unless you want to make like 30 more texture transition variation possibilities. You'll see when you get there, but there's many very awkward transitions that require very awkward tiles, like this for example:111111010What do you do with that? Now you need a T-joint thing. In my game, in this situation the center just becomes the same tile as in my first example (Straight down facing transition)

..and the oddball 1 in the bottom row, does it's check and it sees this ..so it becomes an "illegal transition" and becomes a single stand alone texture:111010000

So while I *could* make transitions for these situations as well, you get to a point where it's just overkill.

Here's one of my terrains, if you want to see how many transition tiles each of my terrains have. Only the top row is important, I just added texture variations on top of all this. But it's not required.

EDIT: I think the theory behind this a lot of people may miss is they probably think you need to check the entire terrain/map as a whole, you really don't. You only need to check each tile 1 by 1 and the 8 tiles around it, if it's done correctly all the tiles will end up lining up perfectly.. being completely unaware of the rest of the map, just the 8 tiles around it.

What is your code for doing the transitions? There was a good tutorial that I found (though I can't find it again) that explained how to use powers of two. You would give each tested area a different power of two, then that would give you a unique number from which you would get a portion of the texture.

The code is too complicated to explain in it's current state (because it accounts for random textures, tile ranges and a mess of other things) but here's a slight rewrite. Without my extra data this might actually be forloopable or simply compressed into a single line like your's is. My original code can't due to too many special rules/situations in the check though.

Note that my entire map is stored in a 3D int array; mapArray[tileX][tileY][layer]. So the mapArray parts will have to be however you fetch the tileId you're checking against.

All we're doing here is checking all possible tiles away from the center one, and also marking the center tile "1" every time (because it's always 1). In mine, you'd actually generate an int with a 2 on the front, only because it's easier to just pre-init the int with something in this situation. Basically it starts from the top left tile, moving across, jumps one row down, repeats, jumps one row down, repeats. Every check multiples the value by 10 or multiplies by 10 and adds 1. When it multiplies by 10, it's basically just adding a 0 on the end of the int.. or, if a tile is found multiplies by 10 and converts the 0 to a 1 by adding 1 to the entire value, a tile was found.

It's pretty messy looking, but it works amazingly fast considering how fugley it looks, and in this situation that's extremely important because you may be running a few dozen of these checks all at once if you're checking multiple layers or using a large terrain brush.

once you have that, it'll built your int string (keep in mind, it'll be something like 2111111000 instead of 111111000) because that 2 is still there. But you can now use that built number string to compare to situations and decide what tile belongs there.

The first tutorial that comes to my mind is this one.Is that the tutorial you had in mind?

Yes, that's the one. Thanks for finding it

Hey! That's one of the tutorials I found too when looking up ideas on how to do mine. I ended up going with my own method though, as far as I know there's no tutorial for it. I can't imagine I'm the first person to come up with the idea though. It's not exactly groundbreaking.

Here's a method similar to mine I just found, it's an interesting concept. Basically involves assigning a value to each corner of each tile. This has the potential to be faster than my method, but I think to implement it correctly you'd need a byte[][] array that's 4 times larger than your entire map. At least, that's where I'd start before attempting to optimize. Because assigning the 4 bit value to each tile on the fly seems like it would be painfully slow. It would make more sense to always have the data stored somewhere to recall.

Was working on optimizing the lighting system so the lighting map can be updated on-the-fly a bit faster, thought it would be a good time to show off the lighting working in-game with the new lava texture.

I must have an explanation. How do you get it too look so nice without shaders?

I may have to write a tutorial on it later, it's a bit too complicated to go into without pictures, and as far as I know there's no tutorials anything like it on line. I'm not even entirely sure how to explain it without visuals. :/

It's actually not that complicated of a concept, I just can't think up how to explain how it works without a long detailed tutorial.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org