Print

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

[Putnam]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

That is completely off-topic, unless you're actually saying that easy to program implies easy to compute. If so, I want this list sorted by bogosort in the next 5 minutes:

Code: [Select]

5 4 7 5 1 2 3 4 9 1 5 4 3 4 9 7 5 1 2 3 4 3 5 7 1 2

Bogosort is very simple to program, heck, here's a quick implementation in python:

Code: [Select]

import random
def bogosort(yourlist):
    while not all(yourlist[i] <= yourlist[i+1] for i in xrange(len(yourlist)-1)):
        random.shuffle(yourlist)


[Urlance Woolsbane]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

I'm not the most knowledgeable in this department, so have patience with my ignorance, but doesn't a tile-based system allows for Toady to "cheat" more easily than a mesh-based one? Most physical discrepancies in DF are invisible, which is beneficial not merely in terms of immersion, but also in regards to optimization. Surely not having to calculate each object's mesh (even rather primitive ones, per your proposal) frees up a fair amount of processing power for DF?

It also means that terrain and structures can be mesh-based, which is better for simulating their destruction and can have their vertices used as pathing nodes (If a beeline to the target destination is not possible, the AI is definitely going to make a beeline towards a vertex).

Agreed, but I'm not sure that's viable for something with the scale of DF. Look at the FPS-damage done merely by flooding or by smoke. Imagine the processing-strain resulting from simulating all the minuscule bits scattered by a cave-in.

[Untrustedlife]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

That is completely off-topic, unless you're actually saying that easy to program implies easy to compute. If so, I want this list sorted by bogosort in the next 5 minutes:

Code: [Select]

5 4 7 5 1 2 3 4 9 1 5 4 3 4 9 7 5 1 2 3 4 3 5 7 1 2

Bogosort is very simple to program, heck, here's a quick implementation in python:

Code: [Select]

import random
def bogosort(yourlist):
    while not all(yourlist[i] <= yourlist[i+1] for i in xrange(len(yourlist)-1)):
        random.shuffle(yourlist)


As a programmer That got me to laugh out loud +1 my friend +1.

[Orange Wizard]

If we're using python why not just list.sort()

[Putnam]

bogosort is bigger and better than list.sort(), which IIRC uses timsort. Timsort is, what, O(nlogn)? Bogosort is O(n!), much bigger number!

[Orange Wizard]

Hah, I can go bigger than that.

Code: [Select]

def sort(i):
    while True:
        pass


[Putnam]

but then it'll never get sorted

(the same is actually technically true of bogosort, since shuffle relies on a random function that'll probably have a period less than n!)

[Orange Wizard]

Code: [Select]

def sort(i):
    from time import wait
    wait (9999999999)
    return i.sort()
?

[Putnam]

that's still O(nlogn), just with a massive constant added to the front (which big-O doesn't care about)

[Orange Wizard]

Programming is hard.

[Isngrim]

-snip-

I'm not the most knowledgeable in this department, so have patience with my ignorance, but doesn't a tile-based system allows for Toady to "cheat" more easily than a mesh-based one? Most physical discrepancies in DF are invisible, which is beneficial not merely in terms of immersion, but also in regards to optimization. Surely not having to calculate each object's mesh (even rather primitive ones, per your proposal) frees up a fair amount of processing power for DF?

It also means that terrain and structures can be mesh-based, which is better for simulating their destruction and can have their vertices used as pathing nodes (If a beeline to the target destination is not possible, the AI is definitely going to make a beeline towards a vertex).

Agreed, but I'm not sure that's viable for something with the scale of DF. Look at the FPS-damage done merely by flooding or by smoke. Imagine the processing-strain resulting from simulating all the minuscule bits scattered by a cave-in.

Yep,Fps would get bad fast with the scale of things in DF (especially after breaching hfs),im to tired to go into a bunch of details,so download Unity or UDK,and blender.Then add 100 plus low poly shapes (something with at least couple hundred triangles more then a cube[ A simple capsule shape has 960 traingles]) have them move around,then add your controls and try moving about,.That's not taking into account for fluid physics,terrain destruction,temperature,AI (which needs to be more robust to traverse 3D space then a simple grid as i recall),and all the fun stuff that now happens outside of the Fort.then there is the FPS issue,with 3d graphics low FPS can actually render the game impossible to play,or make the player feel sick,were in 2d graphics it makes the game feel more like a turn based game without making the player queasy

[Man of Paper]

Just popping in to say that if DF has taught me anything, it's that everything is doomed.

[evictedSaint]

Just popping in to say that if DF has taught me anything, it's that everything is doomed.

It was inevitable.

[Max™]

Programming is hard.

Code: [Select]

import:pythonKnowledge
      if false do find(pythonBooks) then
            if boredom ~= 1 do
                somethingElse
            return "Sort your own damn list!"
            end
      end

[Ggobs]

Just popping in to say that if DF has taught me anything, it's that everything is doomed.

sigged