Is this possible?

So I am trying to make a 3d mining game, but before I get deep into developing it, and put a ton of time into it I would like to know if what I am wanting to do is possible in unity.

I'm going to try and explain this as best as I can.

So my world is going to be a smooth none blocky voxel world, where players can dig for minerals with shovels and machines, so here are my questions.

1. Is it possible to have minerals scattered throughout my world in the ground randomized amounts more in said area and less in others?

2. Say I dig with a shovel now the shovel has dirt on it with the minerals mixed into the dirt from that spot, am I able to code it to where I can dump that dirt off the shovel and it makes a pile on the ground that retains the minerals that was initially on the dirt that was dug by the shovel and able to repeat the process, so the pile gets bigger and bigger the more u add to it but keeps all the minerals dug up by the shovel????

3. If number 2 is possible, that means I would beable to use a backhoe fill up a dump truck move it across the map keeping the mineral and dirt contents dump it at a processing plant in a new pile then moving it from the new pile into the plant to separate the dirt and the minerals held in the dirt, correct??

Thanks.

 

1. Yes
2. Yes
3. Yes

Now grab on Unity and hop on the work.
Be advised, start with pong game first, if you never developed any game yet.

 

I have a little bit over a year of experience I have made smaller games but nothing Of this size so I'm using this as a learning experience as well It may take me a very long time to do this but I will learn so much as well

So if that is all possible How would that be achieved Like I'm not asking for specific code I'm just asking for a short explanation because I can't find anything on this


The only thing that is remotely close to looking like this is gold rush and gold hunter But they are not able to retain the minerals when they dig When they dump out a shovel it disappears And they are not able to dig on the entire map they can only dig in specific areas with weird types of material

 

Yes.

It can be done, but it may require skilled programmer.

Basically, games are made with smoke and mirrors, and nothing prevents you from having a pile on the ground that literally stores list of materails within it, and then making pile bigger. Same goes for transporting it in a t ruck. You don't need to simulate every speck of material, you just need tostore total.

However, what you describe is "ground manipulation", this is something that people usually want in farming sim, but the thing is I do not recall a farming sim that offers such feature. The closest to that is Farming Simulator 19, where you cutting grass or harvesting wheat produces physical piles on the ground which you can then collect.

Spoiler

So you may be aiming too high.
----

Destructible landscape requires voxel terrain (you'll be able to dig caves) or heighmap terrain (you won't be able to dig caves)

In its simplest form, dumping stuff from shovel requires you to spawn "pile of stuff" object on ground, attach information regarding what's inside of it, and make it bigger when there's more stuff in it. In more advanced form, it can be implemened like heightmap that is poking through the ground in places where there's a pile of stuff.

 

Honestly with one year of experience, I'd strongly recommend trying this as a 2D game. It sounds like a concept where 3D would add a lot of development complexity with possibly little additional gain in gameplay fun.
2D will be challenging and fun enough already

You could use this affordable system here for a headstart: https://assetstore.unity.com/packages/tools/level-design/digable-2d-terrain-200544

 

Kinda done with 2D games I want to make a 3D game I understand it will be a lot of work and I am prepared to learn, it may take years but it's doable.

 

It's not unlike an inventory system, how you render it is different but same mechanism of adding/storing/removing "items" to containers whether minerals or potions or whatever, and a dump truck and dirt mound instead of a backpack/chest/etc can all be considered types of containers that dirt/materials can be added to.

Even in an inventory you may have a different graphic for a silver coin vs a pile of silver coins assuming coins are stackable and you reach a certain threshold in which it becomes a pile.

For your dirt pile you may have to build a 3d model pile that is made up of segments/nodes/submeshes, and each time you add to the pile it toggles a node on and sets its type of mineral and units of material. When all the nodes have been toggled on the pile is full and can no longer be added to.

 

From my experience, I can say that going too big, when it comes to side projects can be frustrating, and you may quickly lose motivation. Try to slice your plan into smaller pieces, focus on core functionalities, and once it is done add more features.

Many functionalities that you want to code will take long weeks or even months to make (you will have to learn many other things before you will be able to make it work) and the progress in your project will be little.

I understand that you don't have much experience with 3d, so maybe work on smaller projects, learn one thing at a time, and once you feel ready, go for the big one

 

Your account is eight years old yet you only have a year of experience. That doesn't suggest to me that you're going to be able to stick to a project for years. Choosing 3D is fine but you don't want to jump head first into a gigantic project with little experience. Start small and work your way up.

 

I think this point is what has people concerned. The way you're talking about this is not generally the way most experienced game devs would think about it.

The way most devs would think about this is something like:

"I have a shovel object, it's got a

dirtType

property and a

dirtAmount

property"

"when the player uses the shovel I'll spawn a shovelDirtBlob prefab and attach it to the shovel dirtBlob attachment point"

Or something super simplified and dumb like that. The way you're talking about it sounds much more detailed and realistic, which is why the more experienced peeps are giving you warnings.

 

OP you really need to pick something of a suitable scope, this isnt it based on your experience and the way you are talking about some very basic things.

I guess what everyone is trying to say here is : if you need to even ask these questions, you are definately not ready to build this yourself. You will just end up having to come back to ask for help for every step along the way. Based on your experience level its going to take a lot longer than you think.

As a rule of thumb: generally things always take at least 2-3x longer than you would expect the actual implementation to take, to account for bugs, testing, package issues, performance issues, etc etc that come up along the way. So whatever time you think this can be done in, is drastically off.

Nobody is telling you these things out of malice, everyone just wants you to suceed instead of fail.

Good luck

 

Yes. Except that OP seems to be looking for a way to mix multiple types of ore in a single pile
That calls for a list, at least in the pile.

 

Below is simple idea could use to get started. I agree with others than if you are asking these questions, the described game is too complicated. However, you can practice making some of these subsystems on their own and learn a lot.

I like to use some mind-mapper application to sketch out my ideas in plain english, then form it into pseudo-code before doing any in-engine work.

It helps me to think in terms of questions. Who, where, when, what, why? Who needs to know what, and why, and how will they communicate with others that are involved, etc.



I've described here very simple idea that can get the ball rolling but naturally you will need to modify it as you add additional features. Eventually your data may need to be contained in arrays or maps, and perhaps your interaction tool (the shovel) needs various states defined which handle what sort of animations and events it will perform. But it is good to start simple and only add one new thing at a time. This way when you have bugs, you can solve them.

Try to avoid doing things "right" to start with. You'll end up confusing yourself. Just get things working in a way that you can understand. YOu will naturally come to face problems, and then when people tell you the "right" way, you'll be able to understand what they mean. But if you try to apply the "right" methods from the start, you'll misapply and cause problems that are not easy to solve.

In other words, do work in whatever way you can to create your desired results, then get help from others to refine the code into something that is more maintainable, performant, etc. You have to start by doing the work.

From here you will have to figure out many more questions to ask.
How does one entity identify the other?
Who passes data to who?
Does one entity need to know about the other?
etc. But you'll be able to ask those questions more specifically once you get to them, and then more useful, less broad answers can be given.

edit:
to get start with this whole setup, just do it with text, like a text adventure game. This will ensure you understand the communications between gameplay objects. Thats the most important part. Then when you get to tacking on visual elements, your mind is free to focus on those details without having to also design the fundamental system at same time.

 

I agree that tackling this entire project is probably too big, if a finished game is the goal, probably a 2D game would be more likely to be finished with the overall game idea.

OTOH, you could just tackle one problem at a time, like the pile concept. I might try something that uses 3D perlin noise to color/reveal/create the various amounts of minerals. It seems to me that you could normalize the pile of noise from 0 to 1 and assign percentages of each mineral in that range. So, 2% gold + 98% dirt would use the value .02 to clip the 3D noise to represent gold.

Not sure of the mechanics of how to show this, but as others said, you simply need a list of minerals in the pile. Using that, determine if materials/particles/voxels or a mesh would be the best way to represent it. I think refining that mechanic to work and look good in 3D would be quite a challenge and keep you busy for months!

 

I really appreciate all your feedback, I understand what I am describing might be * too big for my scope * but please bear with me for just a minute, or out of my skill level, but my motivation is extremely high and that will not falter this is something I have really been wanting to do and am very determined to do it.

I will try to explain it a little bit more. Please keep in mind out of the entire game THIS IS the most complex part the rest of the game is nowhere near this complex, so I want to take the time to learn this part.



I want to do an invisible grid on my map that is many grids for example 10x10 or 5x5 1x1 etc grids that have a maximum height and a maximum depth. Within these grids, it spawns randomized invisible minerals ( that are dice rolled on startup for the amount within the grids some will have a higher maximum amount that can be obtained and some a lower maximum amount that are scattered all over my voxel terrain )

So that when I dig with a shovel it takes a piece out of the terrain ( spawns the dirt in the shovel or bucket, etc ), lowers the overall minerals in the said grid, and adds the removed amount to the dirt in the shovel, so when I dump out the dirt in the shovel the small pile it creates has the minerals that were removed from the said grid by digging with the shovel in that pile, and the more I dig and add to the pile the bigger the pile gets, but it retains all the mineral information within the pile that was removed from the grid.

The minerals ( pile of dirt ) that were removed from the said grid have to be able to be moved around after it has been put on the floor maintaining the minerals that were dug up when the shovel spawned the dirt on it out of the grids mineral count.

If I can figure out how to do the above ^ the rest of the game is not going to be as difficult.


I am not asking people to code this for me, I am asking for guidance on where I can read up on doing what I mentioned above because I have been searching and am coming up empty


Thanks in advance.

 

honestly man I appreciate the feedback, but the only way to learn is to take on challenges, I didn't use the codes in mine but this is the basics of what I am trying to accomplish, this is the most complex part of my entire game, once I learn this the rest is nowhere near as hard.

 

yeah i think its good to take on things that are "too hard".

I think it's important to start building the system with only text first. Like this:

UnReal World - Screenshots

It can be 2d or 3d, but just set a static camera that looks down on your game objects. Use print logs or setup a super simple HUD to display text.

The print logs will give feedback about logic happening.

First steps is get your game objects in the scene and be able to display text when you click on them. Then display text that tells your their assigned variables when you click on them.

After that you can work out a way to move data around.

Forget about procedural systems and voxels and all that advanced stuff for now. You will see that getting the basic channels of communication and managing data will be plenty to chew for awhile.

 

If you believe that this is by far the most complex aspect of your game then I'm even more inclined towards this being out of your league. You've completely neglected to consider the main difficulties of working with voxels.

Getting voxel terrain to render properly is fairly difficult but it's not the worst part. You need to be able to generate voxel data, stream it into memory from files, and stream it back out to files after it has been modified. None of that is trivial. Minecraft has a far simpler voxel approach and it struggles with all of this.

There are no third party voxel terrain systems available for Unity that haven't been abandoned by their developers so you will have to build and solve all of these problems yourself or hire someone to do it for you.

 

I don't want the voxels themselves to store the data, that's why I want to use an invisible grid pattern that is like a layer over the voxel landscape, I already have a working voxel landscape that I can put holes into it renders just fine from what I have seen, so I dunno why you are saying this stuff? I mean your comments really just scream you can't do this give the hell up.

That's not going to happen, you might see something as too hard or impossible, I see something that is hard and or *impossible* as a challenge.

My entire life people have been telling me what I want is impossible or too hard I am wasting my time, and every time I have proved them wrong when someone tells me it's out of my league or my skill level I always strive to prove them wrong, and I have not failed once I put my energy and mind to it.

I will figure this all out, if u are here to just say don't do it, go do something else, if u think that is hard then this will be even harder, like seriously? is this what you do people ask a question and you try to steer them away from accomplishing what they want?

Do you really live your life like this?

 

You're describing factorio/space engineers. From those factorio is 2d, space engineers is 3d.

The pain point is the grid. You'll have to polygonize that, and that can be painful. See Dual Contouring for smooth landscape. Or you can make it simpler and use minecraft visuals.
Here's an example:
https://forum.unity.com/threads/dual-contouring-are-there-opensource-implementations.1269281/

You can also make the grid 2d with height. But you'll still have to polygonize the grid and reflect changes to it.

The actual digging thing is simple.

In your game you'll have every material defined at some point. It could be "iron ore", "copper ore", "uranium ore", "adamantine" or whatever. The definition will also include its material texture. So t he data on your grid will store which material is present, and how much of it is there.

So, when you dig with a shovel or anything else, you probe the grid, verify which material is there and reduce total of material in the cell. Then you update the landscape to reflect that. On your shovel, you store which material you're holding, and how much. You update the sholvel to reflect it holding something which can be simple model swap, unhiding a portion of model, etc.

When you dump the shovel onto ground, you spawn a "rubbish pile" object. Actually, when you dump shovel onto ground, you check if a "rubbish pile" object is already present, and instead of making a new one, you use existing one. A rubbish pile object will store a list of all materials in it and their amounts. So it will have a list that it has 100 units of iron ore, and 200 units of uranium, for example. And it will update its own appearance to reflect materials within. That's if you want to do it easy way.

Let's say you don't want the easy way and instead want to make your life difficult, by implementing system of farming simulator, where a vehicle can dump grain onto ground, it iwll form a pile, and that pile will be a smooth pile, not a distinct object, and you also can ride through it, bulldoze it, etc.

In this case, you have an a LAYER of, I don't know "mineral grain" (what's the english word for all material composed out of thin particle t hat forms pile? "Dust"?) or "mineral dust". That layer would be a 2d grid overlaid on top of your world, whether it is 2d or 3d, storing how much stuff you've dumped for every single square of the grid. It has to be fairly high resolution, by the way. So, when you dump shovel, you'll update the "dust map", and based on data of in the dust map, you'll update the "dust mesh" which will be geometric representation of the piles. And based on the stuff stored in this particular spot, it'll have to change its visuals.

But let's say it is not enough. You really want to make your life difficult, and want to make piles out of powdered uranium and dig tonnels through them! In this case, when you pour things down onto ground, you'll update the world voxel grid, forming new voxels at the dumping spot.

This is not recommended at all, as it will not let you bulldoze the material easily, and will have a fairly low density compared to 2d layer of dust.

-----

For the record, didn't I already explain all of this in this thread?

 

There is two way to go about this.
Either you take into consideration, what have you been advised here from experienced fellow developer.
Or you hop on and try actually do it, to see for yourself, if you are up for a task.

Ask yourself a question. What did you do past week in Unity?

Either way, if you are doer, you would be already on a task, prototyping things, to see how complex / easy are for you.
You wouldn't be asking "if is possible". But you would be asking specific problem how to solve.

The way you have asked question in OP, it indicates, you are not ready yet for such complex challenge. And fellow devs recognize it here.
Therefore, people try to advise you to take up healthier approach.
Not because they don't wont you to succeed.
But because many went that route, or learned from others. Literally we got weekly people asking similar questions like yours, one way or another.
Taking up challenge which is out of scope, is not fun neither proficient. And can be very tiring.
Chances are, you will be stuck on a problem for a months, just because you got missing pieces of knowledge and expertise here and there. That can lead to burn out, because lack of sense of progress.

Our collogues advise you to take simpler steps, to allow yourself to learn these missing pieces, before you jump on bigger project.

 

What exactly what you are having trouble with? Is it how to do the invisible grid? is it how you store the information on the grid/shovel/pile?

 

OP you are obviously not listening to anything anyone is saying, so why not just give it a go. Its clear nobody is getting through to you and that you are misunderstanding what is being pointed out, so best thing to do is give it a go and see for yourself. High % chance you will hit all the hurdles explained in here and more, but hey at least you will be convinced that way.

As said before, nobody wants to see you fail, everyone wants to see you succeed and that is why you are getting this feedback. So ignore it at your own peril, but some of the members in this thread replying are some of the most experienced and oldest members of the unity community, something to take into consideration. Would they really be trying to sabotage you? Would they really be giving you wrong advice willingly? Would they really be trying to scare you off something that actually is doable? Do you really think this is the first thread like this the forums community have seen and replied to?

People are basing feedback on the 100s, maybe 1000s of users who have posted similar things and had similar takes, only to end up crashing and burning despite all our attempt at helping them steer onto something actually manageable.

So basically, ignore at your own peril but its your life and your time, spend it how you please.

Personally, I have very rarely ever seen @neginfinity @Ryiah or @Antypodish give bad advice and I am always inclined to give them the benefit of the doubt when hearing advice from them. I certainly wouldnt be outright ignoring what they say, but hey I have been here long enough to see the benefits of their advice, hence why I am saying give it a go and see for yourself.

If you succeed, everyone will be happy for you and high fives all round. But if you dont succeed, its just wasted time for you and its honestly more wasted time for us trying to stop someone going down a failed path. Its obvious what to do in this situation for me, but yeah do what you got to do mate and see how it goes.

 

I get the frustration guys, but sometimes, if a person with a strong personality wants to climb a mountain and its also the mountain that all your good friends died on, the only thing you can do to save them is point out the best routes to climb.

I dont think that trying to make this work and failing/quitting at some point is bad. Clearly our hero is at a stage where they are still learning the basics of programming, so any challenge is going to teach them a lot.

For some people, getting easy, reasonable victories leads to boredom. They know that they need impossible challenges to stay motivated.

 

Absolutely and thats why ultimately I said to OP give it a go and see for themselves. Hopefully our advice is null and void and they will be fine, but important to point out the necessities to them first, which I think we have all done amply in this thread.

I want OP to do well and manage to make this, but I also dont want OP to try, get disheartened and get put off game dev. We all have unfinished prototypes floating about we wish we had been able to see through to the end, I dont want that to happen to OP if its possible

 

It's not bad but some people burn out long before they can reach the conclusion that it's okay to fail/quit, and saying "it may take years but it's doable" leads me to believe that the OP could very easily be one of them.

 

if I was someone that burns out at the sign of struggle I wouldn't own my own company right now, I hit major walls in the years building it, (it's not a dev company ) but I pushed the walls and ultimately succeeded, I spent over 5 years learning and struggling to ultimately succeed, so I don't really think I will just say the hell with it I quit for this.

basically this, what I have been asking a few times in this thread is just for someone to point me in the right direction if any documentation on this issue, I have a voxel world already contrary to what someone said early mine works, I dunno how to do an overlapping invis grid to the entire voxel world, or how I can store the data for specific grids with it being able to be called upon that data when the shovel interacts with the voxel landscape within the specific grid.

that's all I really have been asking about but people keep just saying that's out of my league instead of just pointing me in the right direction for the documentation for this type of stuff so that I can learn.

 

If you got the voxel thing right, then the remaining stuff is actually pretty simple.

I would do it differently, but I will go with your invisible grid idea so that it will be easier for you to understand.
For the invisible grid, you could instantiate cubes and remove their meshfilters / renderers (leave only the box collider). Each cube would be a cell of the grid. A simple script could generate and position all the cubes you need.
For the mineral data, you can make a script called MineralsHolder.cs and put it on the cube prefab. The script would have something like

Code (CSharp):

1. public int iron;
2. public int copper;
3. public int tin;
4. // put ALL mineral types that exist on the game here
5.  

This same script would be present on the shovel and on another prefab called "Pile"

So, when you hit the collider of the invisible grid cell, you can access the MineralsHolder on its gameObject and add the data to the script on your shovel (then destroy the invisible cell).
When you put the dirt on the ground, it will instantiate a pile and transfer the data on the shovel to the pile. (if there's a pile nearby, it will instead add the data to the data the pile has)

If you don't know how to transfer data like this, search for any tutorial about doing damage to something. Doing damage is basically accessing a script on the target and decreasing the health value on it.

(ignore what I will write below if you are confused right now. Just try to understand / learn what I said before first)
Note that if the world is large or you can't identify where you should instantiate the grid cells, it's much better to just simply add random minerals to the shovel when you destroy(dig) any vortex. The random minerals could also be affected by the player position (since you want different areas to have different ore amounts). If you do that you don't need to worry about grids.

 

I already explained everything in great detail to you, so you should be building a prototype by now.

Your voxel world is already a 3d grid. Each cell stores information, which at the barest minimum is "texture type at that point" and maybe "density". Your voxel world library should already offer an ability to create and destroy cells at runtime and query "what is at this point in space". If it doesn't, it is not a voxel world. Additionally, your voxel world library should already allow you to store some user-defined data in each cell. Something like 2 int values per cell will not inflate memory requirements much and would allow you to store mineral type/quantity. If the creator of your voxel world library for some incomprehensible reason didn't think of something this basic you can still derive mineral from texture type. If your voxel world library doesn't support different texture types per cell, it is unusable for your current project, and you need another one.

"How to make a 3d grid" is just a game object that defines invisible volume. For example, it could be "volume center" "cellsize", "numCellsX/Y/Z", or anything. You can write it yourself, and it is not difficult. If you can't write it yourself, you need to hire someone who can.

---

Frankly speaking, you having a company and overcoming difficulties in the past doesn't matter. You're asking dev questions, and those require dev experience.

For example, as a training exercise, can you write a component that draws a 2d or 3d grid within "OnDrawGizmos" and then draws cells which holds player differently?