Print

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

[Cheddarius]

Actually, I just build 9 at once, and then go back for the last one when they're done and all my dorfs are safe.

Er, I mean if you have a wall outside, and then want to build a wall on top of it - do you see what I mean? Then you have to build every tile in a specific order, outmost to innermost.

[darkflagrance]

Actually, I just build 9 at once, and then go back for the last one when they're done and all my dorfs are safe.

Er, I mean if you have a wall outside, and then want to build a wall on top of it - do you see what I mean? Then you have to build every tile in a specific order, outmost to innermost.

What I do is build stairs adjacent to the entire wall as scaffolding, and tear that done when.

Or, you can also build a narrow allure (wall walk) behind the wall where your dwarves can stand to build the wall.

Edit: I must have been really sleepy making this post...

[Cheddarius]

Ah, that'd do the trick.

[Andir]

Actually, I just build 9 at once, and then go back for the last one when they're done and all my dorfs are safe.

Er, I mean if you have a wall outside, and then want to build a wall on top of it - do you see what I mean? Then you have to build every tile in a specific order, outmost to innermost.

What I do is build stairs adjacent to the entire wall as scaffolding, and tear that done when.

Or, you can also build a narrow allure (wall walk) behind the wall where your dwarfs can stand to build the wall.

Ah, scaffolding... I always cringe when I hear that in meetings concerning new code projects...

I build the corners, then the walls after.  It helps to define the boundary.  I've not built a double high wall without a floor though so you got me there.  I guess I'd probably end up building a scaffolding then, but I wouldn't like it!  It violates my coder nature to build something that's just going to be deleted later.

[PermanentInk]

It violates my coder nature to build something that's just going to be deleted later.

If you don't mind hearing my own opinion as a software engineer, I think this is a counterproductive habit of thought.  Being too attached to not deleting your code can lead you to make poor decisions, because quite often deleting code is exactly the right thing to do (my most productive days are ones where I delete tons of code).

One of the most important programming skills I know of is being able to look at what's going on with fresh eyes and say, okay, what are we really doing here, and do we need all this?  Could we be doing it in a different way?

The important thing to acknowledge is that you will understand your problem better over time, so it's not necessarily right to front-load a bunch of analysis effort and try to get it exactly right the first time.  Often it's far better to build something quick and basic that works, and in the course of using and integrating that piece into the whole, you learn more about how it should be.  You gain more information for less effort this way, and you can afford more iterations to get it rock-solid.

Rather than me typing up a long tirade on it and derail the thread, though, I recommend that you google the phrase "build one to throw away" and see what others have had to say about it.

[Andir]

It violates my coder nature to build something that's just going to be deleted later.

Being too attached to not deleting your code can lead you to make poor decisions, because quite often deleting code is exactly the right thing to do (my most productive days are ones where I delete tons of code).

One of the most important programming skills I know of is being able to look at what's going on with fresh eyes and say, okay, what are we really doing here, and do we need all this?  Could we be doing it in a different way?

Err, I think you read too much into what I said and maybe took it too far.  I delete lots of code (most of it the other people in the office that are doing it wrong ) but I tend to dislike creating my own throw away code unless it's necessary.  There's a difference between re-factoring, and just simply throwing up code to make something work for the boss.  I tend to plan out my program and create it "the old fashioned way" instead of the new "agile development" ways where you barf up something then go back and fix all it's problems.  Yes, barf coding leads to faster demonstrable items, but it also leads to some of the particularly fun sites like DailyWTF.  Have I done it... Yes.  Have I hated to do it?  Yes.  Have I learned from it?  Yes.  But jumping the gun by saying I NEVER do something because I said I hated to do something just is taking what I said WAY too seriously.

Like Fortress development, I tend to plan out a layout scheme (and sometimes graph it out on paper) before I get started instead of some of the other folks who just throw rooms wherever it suits them.  I'll have a small tunnel running off into somewhere that looks totally random, but in reality it was an already planned location for a housing tower and I just wasn't ready to dig out the stuff around it yet... but I needed the rooms.  So I quickly dig out a single tunnel that follows predetermined halls counting the squares I need to get into that tower structure and slowly start working my way there.  It means less starting my fortresses over "aka deleting code" because I didn't think about the problem ahead of time.  I know how many rooms I need.  I know that I'm going to put them in stacks.  I know I need to keep them X units from workshops and that needs to be around resources... if you go in like you state you just get a cluster of garbage layouts.  Sure, you get a fort built up fast, but it's not very efficient.

It's not counterproductive unless your productivity doesn't care about quality... and I know a lot of coders that don't care about doing it right.  I don't know how many times I've had to correct some of my coworkers classes that use public variables as parameters, non-thread-safe static vars that worked for their test, but caused all kinds of garbage in production data and cleaning up after them countless times... but they got commended by the boss for getting in early and decried later for the code I showed him later that caused X problem that lost the company three times their salaries worth.  Yeah... I'll stick to a well planned development cycle and enjoy the commendation pointing out how they screwed up by coding once and not throwing away because they got pulled to another project and ran out of time to go back and fix it.

[PermanentInk]

I don't want to derail this thread, Andir, so I replied to you over in general discussion: http://www.bay12games.com/forum/index.php?topic=46705.0

[Cheddarius]

Coding and DF are pretty different. I'm not a programmer by any means, but it seems to me that coding never really requires "scaffolding", because it's not physical. You never have to build some code to climb up on build some different code and then destroy the first code; you can always just build the code right from the start. So, it may be against coding nature to use scaffolding; but is it not clear that if you were a construction worker, there would be no other way?

[Neruz]

If you dislike building things that serve no purpose other than to be temporary and removed later, you're going to hate it when DF gets more realistic, since scaffolding is the only real way to build reasonable structures, and tends to involve vast amounts of temporary construction.

[Neonivek]

Coding has Scaffoding it is just called by another name.

Usually it is to allow the game to function before the pernament features are put in place.

Placeholders?

[Cheddarius]

Well, yeah, but they are not really scaffolding in the same sense, I think. The scaffolding in construction is absolutely required because you can't build otherwise. The game scaffolding isn't really necessary; you could theoretically program it the right way the first time.

[Neonivek]

Well, yeah, but they are not really scaffolding in the same sense, I think. The scaffolding in construction is absolutely required because you can't build otherwise. The game scaffolding isn't really necessary; you could theoretically program it the right way the first time.

Well you don't need Scaffholding to build buildings either. It just becomes obscenely complicated and absurd (And you would have to change your design significantly)

Without code scaffholding you effectively have to bug test everything at once since you cannot isolate (Well somewhat, you can test code onto itself but not how it works if it works fine code wise.). It is the equivilant of skipping Alpha and Beta.

[Googolplexed]

I guess one example would be the DF cave-ins. At the moment something wont cave in, even if there's only one small patch of sand supporting a mountain.

Toady has said that its a bit of a place holder, later he wants to actually get a proper cave-in simulation.

Scaffolding is useful, it allows you to develop a working version faster, instead of taking years to develop the entire program and then release it at once. Not to mention that it allows you to tell if the program is actually good/fun(Very important in games ) before spending years finishing it.

at the rate at which toady is developing DF it will take many years to complete, is it better to be able to play it now, or would you wait and play the entire game at once, which without feedback might not even be good.

The current invasions are a current placeholder to test larger scale combat, the armies are generated out of thin air, later in the army arc today will strip this and add in proper invasion forces and armies

[Andir]

When you are digging out an underground cave there is no reason to have scaffolding.  Building up, sure... digging out, not so much.  The only reason to have scaffold anyway is to build high fast and leave a lot of empty floors.  It's mainly for aesthetic purposes.  Otherwise, you'd have a usable floor on at least one side to build from.  Building a statue is quite possibly the biggest waste of time and space.  It may look neat, but it's pure eye candy.  My dwarfs have better things to do than put up scaffold, fiddle with some art and tear it all back down.

[Rozen]

Right now, I'm running Dwarf Therapist as a requirement, so the built-in management system is a turn off. Also, the building of walls/floors, or, more specifically, the uhkm scheme drives me nuts... it is one of the most painful things about the game (for me). I have been hacking the commands with AutoHotKey a lot, but between that and building walls and, by extension, monuments without trapping dwarves or leaving spaces that cannot be accessed, I go mad.