(Another) Terraria-Clone

WIP games, tools & toy projects
#1

Yes, here is yet another Terraria-clone (currently unnamed until I come up with a specific direction) that I am developing using LibGDX. Unlike most other clones, my main focus for the game is to optimize it as much as possible to allow it to be played smoothly on mobile (Android) devices. Because of this my sole focus is to design complex algorithms to keep the amount of resources and memory being used as low as possible. For example, the two big things that I am currently focusing on optimizing are the world management system and the lighting system. Right now I have the world management system pretty much done. I am able to have a world with 1,620,000 tiles managed efficiently and ran on an Android device at a stable 30 fps. I also developed my own physics system which efficiently handles collisions for all entities in the world. The basis of the lighting system is done but I need to work on the removal of light when it is surrounded by other lights.

Current Features

  • World Management System
  • Procedural World Generation
  • Physics System
  • Lighting System
  • Saving and Loading Worlds
  • Block Breaking System
  • Item and Inventory System
  • Crafting System

Current Focus

  • Working on the procedural generation of the world.

Stream
I live stream development of the game whenever I am working on it. You can watch my streams here. Be sure to sign up and follow me to get notified when I am streaming. I stream everyday for a few hours a day!

Video Feature Showcase - December 19th, 2015

Update #3 - December 17th, 2015
I managed to implement procedural generation of caves, ores, and trees. The cave generation values need to be played with a tad, but as of right now it works great. You can see a picture of the updates below. Let me know what you guys think!

Update #2 - October 5th, 2015
So I added the inventory and item system to the game! I also added drops when breaking blocks. Here is an image of what it looks like currently. The next thing to do is to add the ability to place blocks based on what is selected in the inventory. Let me know what you guys think!

Update #1 - September 30th, 2015
Here are some images of the game. The first image is a picture of the lighting system as of a day ago. The second image is a picture of the lighting system as of two days ago.

As I further the lighting system I will be posting more pictures and videos. Let me know any suggestions and comments you have!

#2

Just finished the algorithm that removes the lighting generated by a light source. The important thing with my lighting system is that, unlike most other light systems, my system doesn’t have light sources generate a dynamic light value each frame. We can assume that light sources only change when they are modified (broken, placed, or moved) so there is no need for a light source to generate light values every frame. My system generates a dynamic light value once after the light source is placed. It removes the generated light once the light source is removed (broken). It cuts down on resource-usage and makes the game run a lot faster. It also works very well with multiple lights placed next to eachother. Here are images of the lighting system in action, starting from one light source, adding more, breaking some surround blocks, and then removing them. Let me know what you guys think!

#3

We can’t see your images. You’ll have to paste the actual image link (which actually is hosted on imgur).

Good on you for optimizing the lighting engine! I don’t think Terraria dynamically updates per frame, most engines actually update when needed rather than per frame.

Have you considered putting colours for lights? The colours can mix together with different light sources. Here’s a screenshot of my game way back when I was using recursive flood-filling (it uses raycasting which is faster).

It looks smooth but it’s just gradients to interpolate between tiles. Try it!

#4

My mistake! Fixed the pictures. I am not using a raycasting algorithm, I figured a grid-based recursive fill algorithm would work efficiently (which it does). The system doesn’t currently support different colored lights but it’s definitely something I’d like to add in the future and something I already know how I’d do.

My philosophy right now is to ignore the cosmetics of the game and focus strictly on the fundamentals and background services of it. I’ll worry about the cosmetics when the game is fundamentally sound.

#5

Yup, sounds just like the opposite of how I normally do things ::slight_smile:

Recursion can either be pretty efficient or not so much depending on your method of execution. If you’re doing repeated method calls for recursion, it works but it’s not the fastest. A faster way would be to iterate through a queue, but seeing as your game doesn’t have as huge of a world as I did it’s not a big deal right now.

#6

Haha I guess that depends on your definition of huge. My world currently has 1,620,000 tiles in it which I would personally say is pretty huge. Why would work size depend on whether to use the raycasting method or not?

#7

Well my game http://www.java-gaming.org/topics/iconified/35090/view.html has a max map size of 68,719,476,704 X 68,719,476,704 xD total map size on disk 17GB xD

#8

Well I can’t say I have tried maxing it out so Ill do that later tonight and let you know. I’m also targeting this for mobile which is a huge difference when you compare CPU and how much memory each can handle

#9

I think I must’ve made an error. World size doesn’t matter, but it’s how many tiles on-screen at once that matters for updating. My raycasting technique is more-so a Bresenham line algorithm except counting down a light value for brightness. It works a lot faster (and prettier) than the recursive way because it’s not constantly calling functions. My bad! :stuck_out_tongue:

#10

Oh okay I can understand that more, but in my recursive fill algorithm the amount of tiles on the screen doesn’t matter. This leads me to believe that your algorithm, potentially, iterates through all of the tiles on the screen. I would assume that you raycast around the source of the light but I’m not familiar with the Bresenham line algorithm so I’ll have to look into it.

I also don’t think that you can say that because a method is recursive, it is therefore slower than a non-recursive method. The fact that it calls a method over and over doesn’t slow down the algorithm unless you’re comparing it to another algorithm where there are less statements being called on. This really comes down to comparing two algorithms runtime with, say, Big O notation.

For example, say we are trying to sort an array of 1000 elements and we have the option to use the iterative bubble sort method or the recursive merge sort method. You can calculate the Big O runtime for each and see that the merge sort performs extremely faster than bubble sort. You can also do benchmark tests to get the same results. The fact that a method is recursive doesn’t slow down the speed and in some cases can make an algorithm more readable.

#11

My recursive method was actually quite efficient like you said (it acted just like yours, spreading out from a source), but as the number of light sources grew, the amount of method calls grew a lot as well. Method calls are much slower than iterating.

Recursion is great when the language has tail-recursion optimization. However, Java does not.

Regardless of our lighting methods, both recursion and raycasting work quickly. I also mainly chose raycasting after recursion because I disliked my diamond-shaped lights that recursion had, not because recursion was slow.

#12

Yeah I do hate the diamond shape. I may possibly look into that line algorithm later and do some benchmark tests to see what lighting method’s more effective. Now that I’ve got the system working efficiently though I’m going to stick with it. :slight_smile:

#13

So today I made some updates to the UI system and how I believe it will work. I got rid of the ugly arrow buttons that move around the player and switched them with “joysticks” where dragging the left joystick horizontally will move you left and right and dragging upwards will make the player jump. I also added a joystick to the right side that is used to break blocks and in the future, attack monsters and other actions. It works by dragging the joystick in the desired direction that you intend on breaking the block. It will also highlight the block that you are attempting to break so you know what you’re aiming at. You can see it in the picture below. The arrow on the right side switches between placing torches and destroying blocks by clicking the screen. This is completely for debugging purposes and will be removed. Let me know what you guys think!

#14

So I added the inventory and item system to the game! I also added drops when breaking blocks. Here is an image of what it looks like currently. The next thing to do is to add the ability to place blocks based on what is selected in the inventory. Let me know what you guys think!

#15

Hey everyone, it’s been a long time since I last posted an update to this game and that’s because college kind of took over most of my time. Now that I am on winter break, I have began continuing development of the game. Over the past 24 hours I managed to implement procedural generation of caves, ores, and trees. The cave generation values need to be played with a tad, but as of right now, it works great. You can see a picture of the updates below. Let me know what you guys think!

#16

Just released a video showcasing the current features in the game and what I plan on working on next!

Video Link: https://www.youtube.com/watch?v=-z4o8CwJR8EMmB9b5njVbA

Let me know what you think!