Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[malloc]

I'm in. It seems like you(we) focus too much on ideas to be honest? I think we should focus more on what is possible to do in a few months with us all working, and most important, set up a lead programmer. I believe we need someone who can have somwhat of a final word on things, maybe not on design but on structure of the project.

We do indeed. I would volunteer myself. But knowing how big of a job it is, I am a bit hesitant to do it. At the very least the project needs to get properly off ground.

I can contribute with programming and music. I know java, C# and python. Most experienced with Java. Github is a good choice for sharing source code and resources, if there isn't a problem with having it open source?

Not at all, the project could actually benefit a lot from Open Sourcing. I personally prefer SVN and Google Code for my code repository needs.

[GalenEvil]

YAY! Finally getting to install Unity onto my computers ^_^ Will hopefully be able to get some of this stuff working now and get some real progress going

I heard from Kof that we aren't going to be using stairs? Just elevators and ramps? I should be able to get the pathfinding to work with elevators once we have a prototype version of them that I can test with. I could maybe treat the elevator as something similar to a really big stairway for the moment, but I'd rather use a prototype elevator and work with that so that I don't accidentally flub up the code to much with faux-elevators

[Araph]

My vote for the style of the robots is changed to Malloc's version. For the time being, it doesn't particularly matter what the robots look like, and if we decide otherwise we can just change it later.

I really like the logo and the name, but you guys do realize that water in a steamboiler is over 100C, right?

Astute observation, Sherlock. In all seriousness, though, we're aware of that.

I kind of thought the reason they are steamdriven is because that the colonists behind it were knocked back into a dark age by some Cataclysmic event. The intelligence could be precursor technology. Actually, part of the game could be about finding precursor technology. Like exacavating bronze giants and starship drives, etc.

I like this idea; it could give a sort of end goal to the game, like striking adamantine in DF.

I'm in. It seems like you(we) focus too much on ideas to be honest? I think we should focus more on what is possible to do in a few months with us all working, and most important, set up a lead programmer. I believe we need someone who can have somewhat of a final word on things, maybe not on design but on structure of the project.

I'd disagree about focusing too much on ideas. It's always good to have a big list of things that can be worked on, as opposed to finishing something and then deciding what to do next. I do agree with the lead programmer thing, though.

And welcome to the project! Always good to have more people here.

I personally prefer SVN and Google Code for my code repository needs.

At the Google Code page for this project, you can start uploading code to the repository if Kofthefens wants to test pathing or something. Probably not needed at this point, but it's an option.

I heard from Kof that we aren't going to be using stairs? Just elevators and ramps?

Well, the version of the robots we're most likely going to use has legs, so I would think stairs would be possible.

Oh, and before I forget: Pranz, to add you to the Google Code site I need you to PM me your email address.

Regarding the transferal of stuff in the Google Docs page to the Google Code wiki: I'm currently just copying and pasting stuff in there for convenience; once we get features in the game itself we'll need to fill out the pages more.


One last thing; Malloc, would it be possible for you to send me either the UV meshes for your version of the robots or the model itself?

[dreadmullet]

On a different note, I've slapped together a basic collision mesh for the physics of having a mine cart roll down a track. I'll be looking into track laying next. I was thinking of letting the player define the rails using B-splines or cat-splines so we get smooth tracks (Smooth tracks means less bouncing of the mine cart), but I'll have to figure out how to make this play nice with the voxels, because a naive implementation would end up with tracks that are half in one voxel and half in the other. After that I'll do some more work to optimize the mine cart physics, so moves and derails in a natural way.

I don't think we need any fancy B-splines or anything. Actually, now that I think about it, something like that would work. At first, I was thinking it would be easier to just make a few models for each type of turn. But then, if the voxels turn out to be small, there could be all sorts of possible turns and small chicanes and whatnot. Some sort of curve... thing would work. (You obviously know what you're talking about.)

Also, just to be clear: we're using Unity's physics engine for the entire minecart simulation? That seems like the easiest solution, but it seems like it will be quite slow. Instead of a full simulation, I suggest an optimization: instead of using cylinders or something to internally represent the wheels, I suggest using boxes. The boxes wouldn't rotate, but it would still look natural I think. The wheels would still appear to turn. I'm not explaining it very well.

[Virex]

But then, if the voxels turn out to be small, there could be all sorts of possible turns and small chicanes and whatnot.

Slopes were the main reason for me. The current setup only allows for 45 degree slopes, which is very restrictive. Besides that, a spline-based system makes it easier for the user to lay a natural-looking track because the tracks aren't limited to pre-defined angles and slopes. And lastly, I'm just lazy. Making models for tracks would mean we need something like 20 models for 3 angles and 3 slopes and then we still have to find out how to pick the correct path. Using a spline method, I can hopefully do all that with a single script.

Also, just to be clear: we're using Unity's physics engine for the entire minecart simulation? That seems like the easiest solution, but it seems like it will be quite slow. Instead of a full simulation, I suggest an optimization: instead of using cylinders or something to internally represent the wheels, I suggest using boxes. The boxes wouldn't rotate, but it would still look natural I think. The wheels would still appear to turn. I'm not explaining it very well.

I've tested that, it doesn't work well even when using zero-friction materials. I think the problem is that extra drag is induced when one mesh penetrates the other. If using cylinders turns out to be too expensive, which I highly doubt (it's only 8 cylinders colliding with a mesh), there are two options. One would be to switch to spheres, which could be cheaper if Unity's collision engine is poorly optimized. Two would be to forgo a collision-based model altogether and use a first-principles based force balance instead. But to do that, I first need to make a representation for the tracks as two lines.
But before I'm going to do any premature optimization it may be a good idea to do a stress test. I'm not going to optimize something that doesn't impact the frame rate anyway.

[dreadmullet]

Have you tried messing with settings in Time and Physics? In the time settings, you can adjust how often the physics are updated. And there's all sorts of stuff in the physics settings.

[GalenEvil]

I am in favor of stress tests Now that I have Unity up and running I am going to try to put together something that will put some stress on my pathfinder stuff. Something along the lines of 500-1000 units pathing to random points in a maze room should give a decent result. I will have to figure out how I will be putting it all together with multiple Z-Level areas to work through >.>

I guess once we have a decent minecart prototype I can start adding them into the generic pathing so they will path themselves to their goal points effectively. If I can get one of my subGoals for AI Pathfinding to come out right then it probably won't be difficult to adapt it for use with the railstations and tracks.

Okay, so we aren't going to be going with a treaded robot then and instead will have a legged robot? Or will there be a subset of robot that uses treads as well? Like: Minerbots have legs so they can move swiftly back and forth from their mining area and a cart since they won't be carrying super large loads at one time; and Haulerbots which are mostly quarantined to the surface layers where the tracks end and are equipped with treads and the ability to carry heavy weights with ease. Having different types of bots would allow the player a bit of strategy on which robots to build base on what they need to have done, as well as the logistical requirement(s) of accessible track-endings/stairs/elevators/ramps.

Hope that made sense Let me know if it needs elaboration, or explain why it isn't feasible please!

[dreadmullet]

Personally, I would prefer that each robot be the same. All of them look identical, except for their materials and tools.

[Kofthefens]

Personally, I would prefer that each robot be the same. All of them look identical, except for their materials and tools.

Me too

Also, I probably won't be able to work on it again until Wednesday or the weekend

[GalenEvil]

Okay, I'm cool with that Thanks for letting me know.

[Virex]

Have you tried messing with settings in Time and Physics? In the time settings, you can adjust how often the physics are updated. And there's all sorts of stuff in the physics settings.

I know that, but the current collision mesh yields pretty decent results already, except for some bounce after it is spawned. Reducing the time step improves things a bit when going around corners, but I'm wary of doing that until we've got a way to stress test the system. I don't want to optimize everything for a short time step only to find out we'll have to increase it. Especially considering that increasing the time step is a pretty expensive method, whereas I could also try to minimize shaking by adding interpolation between the location of the collision model and the rendered mesh.

[GalenEvil]

I have some ideas that I'd like to start working on but I need to know a few things more before I really go full bore at it:
1) Do the robots need to be able to take rides on the minecarts?
2) How are the terminals going to be set up? IE. On the track or on spurs
3) Should I include markers for elevation changes during pathfinding? IE. going up/down ramps/stairs/other elevation changes that could be used as part of a weighting system to choose the actual best/fastest path for the robot to take. Such as it's easier to go down a ramp a little to get to a minecart terminal that will take the robot up faster then taking a technically shorter route which has a lot of up-ramps/stairs that would end up being slower.

There are a few more things that i'd like to ask but I am at the library so don't have my notepad of ideas with me...

[Araph]

1) Do the robots need to be able to take rides on the minecarts?
2) How are the terminals going to be set up? IE. On the track or on spurs
3) Should I include markers for elevation changes during pathfinding? IE. going up/down ramps/stairs/other elevation changes that could be used as part of a weighting system to choose the actual best/fastest path for the robot to take. Such as it's easier to go down a ramp a little to get to a minecart terminal that will take the robot up faster then taking a technically shorter route which has a lot of up-ramps/stairs that would end up being slower.

I would assume that robots can hop into minecarts and ride for as long as they need, either getting off at a station/at the end of the tracks or maybe braking the cart partway along to their destination before letting the cart continue onwards (assuming it's steam powered). As for 3, I would say yes for sure.

[GalenEvil]

Okay, I think what I will do is make some pictures in Paint and upload them so that I can describe everything that I plan to get done (most of it is already in pseudocode and ready to go) as far as the minecarts. I am thinking of applying a Dijkstra algorithm for along the cart tracks. I hope that the robot can't just jump off the carts as that would make things a little more difficult to code around and would have to purposefully code in extra nodes for the option to jump off at those nodes.

How will turning be handled in the minecarts? Is it going to be 45deg angle changes in direction or more gradual changes? And a final question before I have to head home from the library, if a track has a spur and it ends up looking like ---< are we intending to allow the carts to path from the top of the < to the bottom of the < without issues? I think a better way to put it might be, are the carts only going to be allowed to path through turns of maximum 45deg angle or will right angle turns be allowed as well?

[Virex]

Hold on, there may be some confusion here. The mine carts, as it stands now, are physics based. This means they'll follow the track as good as they can, but if they go too fast they'll derail. That means a right angle is right out. If the track has to snap to the voxels, it would be in turns of 10, 20 and 30 degrees, no more.


A spur in a track would require a switch and the cart could either go up or down, depending on the switch. But a cart coming from the top of the spur or the bottom of the spur would continue in the direction opposite to the spur, there's no way to jump from the top of a spur to the bottom, unless the user builds it in the following way: \---<, in which case a cart coming from the top of the spur would roll up the ramp, back down the ramp and then down the spur, assuming a switch is flipped.


My current idea is that carts can only be loaded and unloaded at terminals, so there's no problem with robots jumping off at in-between parts of the cart. As said, it makes both pathing, and some of the cart handeling easier.