deMOLEstration

Page: 1 2
ID:99103
 
Jul 23 2010, 12:31 pm (Edited on Jul 27 2010, 2:30 pm)
Keywords: mole


While the pursuit of creating my first polished game is nearly in my reach. I decided to create a 'proof-of-concept' engine for a game I have long wanted to create. I have dabbled in the mining genre once before but failed miserably. The game was unpolished, broken, and was an embarrassment to the Calus legacy.


In 2008, once I was finished with the LineWalk demonstration I came across Hedgemistress' Miner League. I read numerous forum posts and searched throughout the web to find more information about this piece of art. Alas, while I could find limited information, it was not enough to satisfy my thirst. I then made an attempt to create a similar game but quickly realized that, at the time, my engine was not suitable.

Fast-forward to nearly two years later. Once again I came across Miner League and decided to create a 'proof-of-concept' engine that included both digging and some sort of slime physics. Two days later I came up with MOLE.

A person can start digging by pressing a directional key and then bumping into dirt. Originally, a 4x4 tile would be removed for each time you dugged. I decided to go with slime for one solid reason, it moves much slower than water and would require less cpu as it does not need to flow at a realistic pace.



I quickly noticed that once I implemented a terrain generator and applied it to a bigger map, the slime would demand too much cpu. So the tiles were increased to 8x8 and I implemented some checks within the procedure to ensure the slime would not move unless a player was near.



As I have stated, this is a 'proof-of-concept' demonstration, there is no game play. The purpose of this demonstration is to see how it holds up on other computers. I have realized that it is still cpu taxing once you get a ton of slime flowing. The goal would most likely be to create some sort of strategy-action hybrid where you must manage your resources and focus on base construction, similar to a RTS.


I would also like to thank Cinnom for providing me information on Miner League.
Jul 23 2010, 12:39 pm
Fluids are tricky. Cool to see you're working on tackling that.
Jul 23 2010, 12:42 pm
Very cool! Hope to see more of this.
Jul 23 2010, 12:47 pm
Is there any way to make it run faster?
Jul 23 2010, 12:54 pm
Forum_account: Movement or digging?

Either way, the speed can be increased.
Jul 23 2010, 12:55 pm
Everything really. It's hard to see how the slime flows when it takes so long.

It also looks like the slime's pixel_step_size isn't set right. Every now and then its movement will be jerky.
Jul 23 2010, 1:06 pm
Forum_account wrote:
Everything really. It's hard to see how the slime flows when it takes so long.

I can certainly increase the speed all-around. Though, there will be some consequences once I increase the slime's pace. I would love to see it move fluid-like, so I will see what I can do.


It also looks like the slime's pixel_step_size isn't set right. Every now and then its movement will be jerky.

Thanks for the heads-up, I'll fix it.
Jul 23 2010, 1:11 pm
The amount of CPU required is the exact reason Lexy went with slime instead of water. And it actually moved much slower than what you have in your demo.
Jul 23 2010, 1:20 pm
It's taking quite a lot for me to get the CPU usage over 10%. Being so slow might hurt more than help: the longer it takes for the slime to flow and come to rest, the more slime you can have sloshing around at once.

water_demo by Skysaw seems to handle fluids realistically and quickly.
Jul 23 2010, 1:38 pm
Forum_account wrote:
Being so slow might hurt more than help: the longer it takes for the slime to flow and come to rest, the more slime you can have sloshing around at once.

Actually, that does make sense. I've added a few more checks to make sure the slime does not move once it has settled and no one is in view. I also increased the speed. I will release the update in a few.


water_demo by Skysaw seems to handle fluids realistically and quickly.

But you must take into account that he stayed with the native BYOND movement. While he is using 32x32 tiles that are constantly updating their states, I am using 8x8 "tiles" that are constantly moving and checking for collision.
Jul 23 2010, 1:44 pm (Edited on Jul 23 2010, 1:59 pm)
Putting some consideration towards it, it seems the trick to doing it efficiently has to do with not constantly moving and checking for collision. Rather, you want to only be checking ones that are currently in flux.

One way to go about it is to create a list of unsettled slime which is populated whenever a turf is updated in such a way that a slime is identified as capable of moving. Go through one full iteration of the list each tic, adding additional adjacent fluids that can move while removing from the list fluids which have settled. By making sure no one slime is added redundantly to the list and processing the list one full iteration at a time it should promote uniform movement.

For best results, keep the list sorted in such a way that the lowest-most slime is processed first, thereby permitting it to settle at the lowest possible point quickly and preventing any slime above it on the list from registering as settled prematurely.
Jul 23 2010, 2:20 pm
Geldonyetich wrote:
Putting some consideration towards it, it seems the trick to doing it efficiently has to do with not constantly moving and checking for collision. Rather, you want to only be checking ones that are currently in flux.

In the latest release the 'droplets' check to see if a player is within its view, if so and if it can move, it will start moving and calling the collision procedure. If either of those turns out to be false, the move loop will be broken.

This new method uses as much of the cpu, if not less, and the slime's pace is faster.

One way to go about it is to create a list which is populated whenever a turf is updated in such a way that a fluid can move. Go through one iteration of the list each tic, adding additional adjacent fluids that can move while removing from the list fluids which have settled.

That is actually a nice idea. I'll try making a demonstration while using the method you suggested.


----------
I have released an update.
Jul 24 2010, 12:20 am (Edited on Jul 24 2010, 1:05 am)
In Dig It!, I made the slimes big circles using overlays. I set them to have a layer lower than that of the dirt, which I found to give the best looking results out of everything I tried.

For flow, goo objects have a flow() proc that handles everything. It checks first if there is an empty tile below, and moves there if so. If it can't, it checks the direction that it last moved, and if it can move there, it will (so that your goo doesn't get all epileptic.) If that doesn't work, it checks east, west, southwest, and southeast. It goes wherever it can out of those choices. If after all of this, the goo object still did not move, it records that it did not move. On the next iteration, if moving fails twice in a row, the goo is "deactivated."

Goo is activated when a piece of dirt is destroyed. The dirt signals to surrounding goo in a 1 tile range that they should check whether or not they should move. When a goo object moves, it also runs this "activation" procedure on the tile that it is leaving, so as to start a uniform flow of goo.

The flow() proc only works when the goo can actually move. When it no longer can, the flow() proc is terminated and no CPU is used whatsoever until something tells the goo to try and move. I found that to be the most effective way to handle large amounts of goo at once.

It still can get somewhat laggy if there is a LOT of goo moving, but it doesn't take long for it to settle back down when the goo reaches the bottom of wherever it's flowing.

That's how I did it, anyway. Works pretty good.
Jul 24 2010, 12:40 am
Jul 24 2010, 9:45 am
Koil wrote:
In Dig It!, I made the slimes big circles using overlays. I set them to have a layer lower than that of the dirt, which I found to give the best looking results out of everything I tried.

http://files.byondhome.com/CalusCoRPS/mole6.png
I believe that looks 100x better than my previous screenshots. Thanks for the advice.


For flow, goo objects have a flow() proc that handles everything. It checks first if there is an empty tile below, and moves there if so. If it can't, it checks the direction that it last moved, and if it can move there, it will (so that your goo doesn't get all epileptic.) If that doesn't work, it checks east, west, southwest, and southeast. It goes wherever it can out of those choices. If after all of this, the goo object still did not move, it records that it did not move. On the next iteration, if moving fails twice in a row, the goo is "deactivated."

Goo is activated when a piece of dirt is destroyed. The dirt signals to surrounding goo in a 1 tile range that they should check whether or not they should move. When a goo object moves, it also runs this "activation" procedure on the tile that it is leaving, so as to start a uniform flow of goo.

My current spread() proc is somewhat similar. Though, I believe the route you took may actually be better. I'll compare both methods and then select the one that is more feasible. Thanks.
Jul 25 2010, 2:47 pm
Have you updated this at all? You've posted newer screenshots but the version on the hub seems the same.

I think what makes the slime look least slime-like is the gaps that develop. I think of slime as being very sticky and viscous, almost a solid. You wouldn't expect little drips to fall off the side, but that's what happens.

When one block of slime moves it leaves a void behind. It should either find a nearby block to fill the void or notify nearby blocks to move (so that one will fill the void). That way it would look like this:

 %%%%%%      # = ground
######       % = slime
######

  %%%%%
######%
######

   %%%%
######%
######%


Because each chunk of slime isn't moving entirely independently, you don't get gaps between drips. It looks like a solid piece of slime oozing over the edge.
Jul 25 2010, 3:57 pm
Forum_account:
I was holding off on updating as I have not added much to the engine. But, I will release a new version so you can see what has been done.

Updates as of today: The slime's speed has been slightly increased, a bug that affected the keyup/down macros has been smashed, some small backend work was done, and nearly a complete graphics overhaul has occurred thanks to Koil.

Plans: Koil has been lecturing on how I could implement cave-ins along with creating a pressure system for the slime. Once I have implemented the cave-in system, I will release another update.

He also recommended that I use circle overlays to make it look "slime-like". You can see the results here: Image

Although I like your idea of implementing slime-like properties, I thought that it may not be necessary as the slime balls, for the most part, now look connected while moving. Of course, I would like to know your opinion once you try the new demonstration.
Jul 25 2010, 4:24 pm
That looks much better. It took a while to get the CPU usage over 30% and it was only that high for a few seconds. Most of the time it was around 5-15%.

A few things unrelated to the slime:

The mole jumps and falls very slowly. It looks strange.

It's also hard to dig upwards. I can dig tunnels down to the bottom, but unless I dig downwards on angles (or have slime to swim through) it's very hard to get back to the top by digging.
Jul 25 2010, 5:28 pm
Forum_account wrote:
That looks much better. It took a while to get the CPU usage over 30% and it was only that high for a few seconds. Most of the time it was around 5-15%.

Thanks.

My spread procedure is rather chaotic and inefficient. If optimized, I am sure the average cpu usage would be around 5%.


The mole jumps and falls very slowly. It looks strange.

This is a customary response I have received from both Cave Dwellers and MOLE. I have toyed around with the gravity but have yet to find anything decent looking. I will try a few platformers, such as Super Mario Bros. and Megaman, and attempt to emulate their speed.


It's also hard to dig upwards. I can dig tunnels down to the bottom, but unless I dig downwards on angles (or have slime to swim through) it's very hard to get back to the top by digging.

My plan is to prevent upwards digging and allow users to places ladders down as they descend. Or I could take a page out of Miner League's book and allow users to climb back up, if the gap between both walls is the ideal size.

I will certainly add one of those into the next update.
Jul 25 2010, 5:39 pm
Calus CoRPS wrote:
This is a customary response I have received from both Cave Dwellers and MOLE. I have toyed around with the gravity but have yet to find anything decent looking. I will try a few platformers, such as Super Mario Bros. and Megaman, and attempt to emulate their speed.

If you keep track of the player's speed in separate x and y components, gravity is a constant acceleration downwards. Every tick gravity decreases your y-velocity by a constant amount. Jumping increasing your y-velocity by a large amount (over several ticks, if you'd like to allow for variable-height jumps).

You can see a simple example of this type of movement here: http://www.byond.com/developer/Forum_account/PixelMovement
Page: 1 2