Print

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

[Sindai]

Pausing in order to "catch" units (as opposed to buildings, which would be easy) makes perfect sense to me. What's strange about that?

[Red Jackard]

My personal understanding of what the presentation arc would bring wasn't a complete graphics overhaul along the lines of 3d or even isometric,I'd always presumed it was going to end up looking more like an old Final Fntasy or Zelda game with things like:

Close enough. Seems like quite a few don't read the development page:

# Core50, TILESET SUPPORT, (Future): Allow graphical tiles to be used for all game objects.
# Core51, SIZEABLE GAME WINDOW, (Future): Allow the resizing of the game windows, and possibly the support of variable width fonts to allow more text to be displayed.
# Core52, INTERFACE OVERHAUL, (Future): A coherent interface, additional options and mouse support.

[Reasonableman]

In another thread, I was reading about how the way brooks work at the moment (being a full z-level deep, yet allowing creatures to stand on them) is a workaround to placate the current z-level system. If so, what we could eventually see is a z-level system that makes terrain vary between 1-7 high in each z-level, which practically begs for a Stronghold-style rotating isometric view. It'd still be divided into the same number of z-levels, those levels would just be subdivided into 7 separate layers which could be dirt, grass, water, stone, or any number of things.

[SirPenguin]

When people talk about right-click context menus for every tile and to get at creature interfaces etc., I'm wondering how you guys are picturing that working with pause/unpause and larger tiles (and so possibly fewer displayed depending on resolution).  If they are zipping around, you wouldn't really be able to use the right button effectively, since you'd miss all the time, as far as I can tell (having it pick the closest wouldn't work since people want info for all tiles and sometimes there are a lot of critters running around), but the whole pause-to-do-anything paradigm is sort of weird as well.  Were you still imagining being paused when you do things?  Did the unpaused view work any differently?  Making everything move smoothly between tiles and/or more slowly is off the table for the purposes of my inquiry here.

I can't speak for everyone, but here's how I envision it.

Space still pauses. Right clicking brings up a context menu, but does not pause when it's on a stationary object or tile. For example, if I right click a floor tile with a rock on it, it'll be up the context menu for the rock (ex. Dump/Hide/Etc.), and I can make my choice while the critters run to and fro.

If I right click on a critter, however, the game pauses for me, as the actions I'm doing are probably more advanced, and it'd be nice to change them before they run off to admire a fine door. "Catching" critters wouldn't be a problem, as we can just Space to pause beforehand.

[Davion]

When people talk about right-click context menus for every tile and to get at creature interfaces etc., I'm wondering how you guys are picturing that working with pause/unpause and larger tiles (and so possibly fewer displayed depending on resolution).  If they are zipping around, you wouldn't really be able to use the right button effectively, since you'd miss all the time, as far as I can tell (having it pick the closest wouldn't work since people want info for all tiles and sometimes there are a lot of critters running around), but the whole pause-to-do-anything paradigm is sort of weird as well.  Were you still imagining being paused when you do things?  Did the unpaused view work any differently?  Making everything move smoothly between tiles and/or more slowly is off the table for the purposes of my inquiry here.

For right-click context menus I envision:

• If you right-click on a tile the game pauses, locks the game screen, and brings up the context menu wherever the pointer is at.
• If you right-click somewhere else on the screen while already in a context menu then it jumps to the new tile.
• If you left-click outside the boundaries of the menu then it cancels and unpauses.
• If you left-click inside the menu on a listed item then it brings up that info or does whatever it needs to do and unpauses.

With something like this, in theory, the game would only be paused for barely a second or two while the person navigates the menu to click on something. The brief pause would only be there to make sure the cursor hits what you want it to hit when you right-click, and to only stay paused while you're in the menu. 

Alternatively, just having context menus enabled while paused would be fine as well, the above is fancy pants and could be madness.

[Sobaalissimo]

Well Toady, you already have to pause a game to catch a dorf or critter.
I can't check it now, but doesn't the 'v' command pause it automaticly?

[Toady One]

Yeah, I know.  And with a keyboard cursor, it's a good thing.  I was thinking it might seem stranger with a mouse-based system, though, in that it would be jarring to normal expectations, and that getting around that if necessary is something that needs to be thought about.  If people are fine with pausing it, maybe it's not a problem, but I thought it might be for a new mouse-based user.

If you right-click somewhere else on the screen while already in a context menu then it jumps to the new tile.

Does that include within the boundaries of the context menu?  I guess if the menu is translucent it wouldn't be too confusing, and you could get used to the right button popping you around as its primary function.

In another thread, I was reading about how the way brooks work at the moment (being a full z-level deep, yet allowing creatures to stand on them) is a workaround to placate the current z-level system. If so, what we could eventually see is a z-level system that makes terrain vary between 1-7 high in each z-level, which practically begs for a Stronghold-style rotating isometric view. It'd still be divided into the same number of z-levels, those levels would just be subdivided into 7 separate layers which could be dirt, grass, water, stone, or any number of things.

That seems problematic as far as memory use, flows, building placement and pathfinding go.



Once the changes that allow resizing the view go in, supporting something like isometric would come down to deciding how to display something like a many-leveled layered labyrinth and still have the game be comparatively easy to use.  I gather that the point of going isometric is to show more than one level at a time, though I could be wrong about that, and it seems like it would take some work on my end with transparency and so on to make it work out.

[Deathworks]

Hi!

With so many people talking about mouse support, I believe I should point out that not everyone is strictly in favor of mouse usage.

Personally, I prefer the keyboard driven interface we have right now (it is not half as bad as people make it seem in these discussions), and whenever I update DF, complete mouse deactivation is one of the things I do in the init file.

I am not saying that people should not get their mouse support. But I hope that even once mouse support is implemented, all features will still be accessible via keyboard - and then keyboard alone (personally, I consider a mixed interface requiring usage of both keyboard and mouse to be about the worst you can get).

Deathworks

[Glutton]

1) The graphic presentation:
I believe that making each object have its own picture will be mor ethan enough for this game. Moders will be able to make great thinks with this. Some server-client applications or making it 3D will be just too much work and not so helpful. (the game is so complex that nice modded 2D will be nicer then poor 3D with crappy animations)
Maybe... if one tile will contain 2,3 or 4 small objects (not doors, beds,dwarf...) the game could render all 4 tiles scaled down so they will fit to the area of one standart big tile? That could also make orientation easyer. Example: if lever, stone and rat will be on the same arean, then insteed of showing one big tile swithing the object, it will show 2*2 smaller tiles inside this area.. one of them empty.
Maybe... the stone should be generally shown in some other way. With silled miner the fortress is full of them. And bacause current game is displaying just one object on the tile... it is making some areas terribly blinking with stones/furniture. So maybe the stones should be displaed like transparent tile with small stone at the corner?

2) Isometric view etc...:
I dont think this is the best idea. Will make the game graphic and orientation even more crappy. I suggsest: Leave the game area just 2D. With improving "Visualisation" windows... that will show jsut terrain and digged tunnels - without textures, without object... just to show how diferent z-levels are connected. Checking the water pump system without it is pain in the a**.
So only visualitation windows should be little bit improved.

3) Mouse support:
I agree that keyboard is the best. But mouse can make it even better. My humble suggestion into this area:
- Mousewhell to scroll in the lists and long menus
- Popus hints - hovering mouse over object will show details about obejct. Usable specially on dwarfs - it will quickly show name, enabled labours, equipment, if he is hungry... Howering over barels will show content. This could be used like nicely improved "K" function. Wih faster movement around the map, wihtout selecting items in the item list and entering another submenus...

[Benny]

Close enough. Seems like quite a few don't read the development page:

# Core50, TILESET SUPPORT, (Future): Allow graphical tiles to be used for all game objects.
# Core51, SIZEABLE GAME WINDOW, (Future): Allow the resizing of the game windows, and possibly the support of variable width fonts to allow more text to be displayed.
# Core52, INTERFACE OVERHAUL, (Future): A coherent interface, additional options and mouse support.

I'll be honest I didn't check back when posting this cos I was in a bit of a rush but I was aware they were actually down in there, they were more the points I remembered reading that I felt summed up what the presentation arc would initially mean. I regularly sit down and work my way through the dev pages to imagine how DF will be in the future when its being programmed by rtoadyd2 and cp3toe

On the note of mouse support, I agree that currently the first thing I do is completely disable mouse support whenever a new version comes out, but this is partially do to it not being properly implemented in the first place as well as not exactly allowing you to be able to do anything faster. This whole right clicking debate I imagine could shape quite drastically how mouse support is brought to us

I'd never even contemplated being able to right click on a dwarf or creature due to the whole moving round like lightning, I'd presumed it would just be your general tiles and what not that could be interacted with in this way and dwarves and such would just be interacted with via a menu option still

I wonder as to how much of a new menu system could be created without impacting on game performance drastically, what with redrawing windows and such like over action in the background, unless if every menu action was to the pause all the action I can't remember off the top of my head if every option does that or not on DF currently

[Tormy]

Okay, imho the in-game menus should be accessible while the game is running/paused also. While its not so easy to right click on a running dwarf, but most of the time it shouldnt be hard for us to right click on any ingame objects...of course it is much easier to do with a pause.
So basically right click on an ingame object -> menu appears -> game paused if it wasnt already -> player is browsing the menu/choosing options -> game unpaused only if we clicked on the object while the game was unpaused. If we paused the game before we right clicked on an ingame object, the game should stay paused after weve finised messing around with the right click menu.

As for the graphics, isometric could work. Do you guys remember this lovely screenshot?

[bprichard]

It is possible that this idea has been suggested and rejected in the past, but I would really like an interface similar to FreeCiv or perhaps even like Photoshop. What I mean is that you have a main game window that continues doing whatever dwarves do, and you can have multiple smaller windows up for other things like the list of dwarves, stocks or what have you and make adjustments while the game continues to run. So you could leave open whatever menus you wished and rearrange them as you like. This may be insanely difficult or impossible to implement, but I think it would improve my experience more than graphical changes or the ability to use the mouse more.

edit: Although along with my layout idea, there is one piece of mouse-related interface I would like added. I would like to have a window which is basically a mining designer. It would just be a grid in which you could create shapes that you'd like to have mined out (while the game is still running; for whatever reason I hate pausing for a long time to create interesting rooms), and then drag and drop your new shape into the main window where you want it to be dug out. And you could save shapes and whatnot to save a lot of repetitive work that kind of gets me down.

[Toady One]

As for the graphics, isometric could work. Do you guys remember this lovely screenshot?

I've seen it, but that image doesn't (and wasn't intended to) address any of the issues I mentioned (it also has fractional Z levels which don't currently exist and aren't likely to exist in the future, so it's not the best test image, though I understand that wasn't its original purpose so much).  It does do one of the things that bugs me in general about isometric, which is obscuring the view with things like trees, which can be handled with transparency I suppose, but the main issue is how to handle the stacked Z levels of a typical fortress.

[mostlikely]

As for the graphics, isometric could work. Do you guys remember this lovely screenshot?

I've seen it, but that image doesn't (and wasn't intended to) address any of the issues I mentioned (it also has fractional Z levels which don't currently exist and aren't likely to exist in the future, so it's not the best test image, though I understand that wasn't its original purpose so much).

The way I saw it the  z-levels in that image are a 1-1 translation to the current z-levels in DF but just under-sized for overview purposes.
This would spark the suggestion of 'scalable' z-level representation so the user can choose their preference between overview (low/flat z-levels) and realism (high/tall z-levels) representation wise.

It does do one of the things that bugs me in general about isometric, which is obscuring the view with things like trees, which can be handled with transparency I suppose, but the main issue is how to handle the stacked Z levels of a typical fortress.

The way I see it is to do it the same way it is done now. You see everything 'up-to' the 'current'  z-level. The user can navigate up or down cutting down more and more of the terrain/buildings as they go down.

The only problem will be terrain/objects that is obscured by terrain/objects on equal z-level.
This is a minor thing and depends on the type of isometric view that is picked (angle of view).
Like you suggested for objects this can be mediated by transparency and for terrain to let the user pick (between 2 at least) z-level representation heights.


Like suggested before the ideal way to go is to make the terrain/buildings polygon based and the objects/creatures sprites. Allow the user to set the view angle and current z-level and obscure anything above that level (maybe baring creatures/moving objects). But I guess that is out of the question?

[mostlikely]

When people talk about right-click context menus for every tile and to get at creature interfaces etc., I'm wondering how you guys are picturing that working with pause/unpause and larger tiles (and so possibly fewer displayed depending on resolution).  If they are zipping around, you wouldn't really be able to use the right button effectively, since you'd miss all the time, as far as I can tell (having it pick the closest wouldn't work since people want info for all tiles and sometimes there are a lot of critters running around), but the whole pause-to-do-anything paradigm is sort of weird as well.  Were you still imagining being paused when you do things?  Did the unpaused view work any differently?  Making everything move smoothly between tiles and/or more slowly is off the table for the purposes of my inquiry here.

Maybe a way to do this is using lists and rectangle selections.

Because DF allows you to stack multiple objects/creatures on top of one tile
when the user clicks on a tile there is bound to be confusion on what they want to select.
A simple way to circumvent this is to create a list of objects/creatures/ect that was under the mouse the moment the user clicked. An item on the list can then be clicked to select or activate a context menu (or whatever) even if the unit is no longer under the mouse (has zipped by).
This way the user gets time to pause and interface with the game while the game can go on.

This can be expanded by rectangle selections (click->hold->drag->release) where you create a 'list' of the selected objects/creatures/ect to be interfaced after the user had the time to inspect the selection.

Lists allow for allot of more interesting options such as mass-orders
(ie. [select] tile -> [select] mass dump selection)
, an unified (catagory) selection
(ie. [rectangle select] -> [select] surface [of selection] -> [select] build on surface -> [select] build wall.  or [retangle select] -> [select] dwarfs [in selection] -> [select] military -> [select] activate)
or things like shift/ctrl select (ie. add to current selection, ect)

But the basic idea is that after the selection is made (by a singe click or whatever other way) the user is given the time to specify their selection and interface with their selection while the game can keep going.

In my view 'pausing the game' should never be 'required' for user interfacing unless the user so desires it.