New Jacbil Thread

Since Jacbil Gobbet has switched to a completely different style, I decided to start with a new thread. Here are some pictures with some of the new ground artwork.

Jacbil Gobbet started out as a pixel-platformer where you could dig+place square tiles like in Minecraft. The feedback on the style touted it as being too close to Terraria. We decided to switch gears and make a painted art style. Since painted art is a little bit harder to fit into the tile system, we now have the game run completely off of the image API. All "collisions" are run off of the get pixel blocks and are judged based off of clear, pure black or pure white being empty space and anything else being a collided pixel. Being image based gives us the opportunity to have really cool physics and world events that might be difficult to otherwise implement.

I think it looks really cool (I'm personally not a fan of pixel art)! Would be interesting if you give us insight in how the API mechanics work, I've been interested in that but the documentation is pretty poor.

I don't know if my system is necessarily the best. Since the wolf is 256x256, I can't check every single pixel without causing some lag issues in stencyl. So what I did instead was have a loop adding pixels to a list and checking the list for their color. Stencyl (or haxe or flixel or whatever) uses hexadecimal color coding. Here are some examples:
#000000 is black
#FFFFFF is white
#FF0000 is blue
etc.

However, the system does not relate this directly and instead converts it to a number.
black = 0
white = 16777216 (actually 16777215 or 16777214 in most cases)
blue = 256

Hexadecimal is 16 values per digit. So the white is 16^6. Blue is 16^2.

So this looping occurs checking pixels above, below and on the sides. It scans for anything with color and counts that as a collision. So I can have the same functions as with a normal platformer... If onground = false you cannot jump. If the loop for the bottom of the actor picks up color, set onground to true. etc.

The other side of this is the digging and other image adjustments. As the stencylpedia article on image API states, masking is a huge drain on system resources. I've found it is best to keep an image below 10,000x5,000 pixels when using a mask. Otherwise, you do hit upwards around 1 second of lag in the game.

Another thing I tried doing was putting the background pictures into the "extras" folder and loading them as the scene is created. Unfortunately, this caused a background color to automatically be inserted. It also formed a weird 32 pixels shadow at the point of overlap. I had to take the less optimal solution of have the background as actors when creating the scene. It does not shove in a background color or have the shadow overlap. All I need to do is cycle through animations as the scene is originally drawing.

FYI, the world is also procedurally generated. So you will never have the same world if you play the game a second time.

New screenshot from what I was playing around with tonight. This presents a conundrum. If you dig, then place a block and then dig the block, how do you load the scene without it eventually taking an hour to draw/mask everything?

Leave the blocks as actors.
- I thought of this, but the world is based on image API. I think adding in actor collisions and box2D will cause lag. Plus, I wouldn't be able to claim an image-based world anymore. It is more of a last resort.

Don't have placed blocks stay through saving/loading.
- This is a real possibility for solving the problem. Will having your placed blocks vanishing when you come back take away from the user experience?

Have the actor stay as simple object on the screen, while drawing the image of itself to become part of the world.
- This one is my current favorite. I don't have to have Box2D physics. I can easily save/place all of the blocks where they were placed and draw them when loading the scene again. When the player dig and hits the placed block, I can use the actor on top as a mask in addition to the normal dig mask. Since I have actors placed in all of the locations, you can always dig up the correct spots. When loading, those removed actors will not be draw during creation.
The downside to this is that your normal dig will have a variable impact when digging near your placed blocks.

People have asked about number of actors on the screen. I was just testing a dust storm using particle actors. They were spawning at a rate of 200 per second. I let it go for a bit before seeing the framerate dropping. I would estimate at least 10,000 actors on the screen. Maybe as low as 5,000 since some were leaving the screen.

Oh, and they were all moving at the time of the screenshot except for those accumulating on the tree.