Official KaM Remake Ideas topic

[Krom]

Seriously though, for hunting to be possible it needs to have issues solved:

- hunter
- hunters hut
- meet animals (2-3 kinds at least)
- animals respawning and areal mechanism
- food value (how much food 1 deer can provide?)
- balance with other food types
- side effect resources (skins?)

Main blockers are that we already have 4 balanced and distinct food types, lack of sprites.

[FeyBart]

Seriously though, for hunting to be possible it needs to have issues solved:

- hunter
- hunters hut
- meet animals (2-3 kinds at least)
- animals respawning and areal mechanism
- food value (how much food 1 deer can provide?)
- balance with other food types
- side effect resources (skins?)

Main blockers are that we already have 4 balanced and distinct food types, lack of sprites.

I think the balance would be the least problem (even though it would cause quite some fighting), but the sprites - and probably the mechanisms, don't know anything about that - could be quite some work. The balancing would just be testing and logical thinking. The sprites are incredibly hard to create, which I'd say is the main problem. As much as I'd love to see this, it's pretty much out of the question as long as there's no graphics artist working on the Remake.

[Ben]

We all know that there will never be a hunter in the Remake. Krom's points should be enough to diffuse the argument. We already have four groups of food as it is. It'd be better to spend all the time, energy, and money (Yes, money, because we'd need to hire someone to make all the animations) on other projects.

[FeyBart]

We all know that there will never be a hunter in the Remake. Krom's points should be enough to diffuse the argument. We already have four groups of food as it is. It'd be better to spend all the time, energy, and money (Yes, money, because we'd need to hire someone to make all the animations) on other projects.

True, but a man should have dreams.

[The Dark Lord]

Even though the map list may load much quicker now than it did before, I still find it irritating to wait for it and especially the need to scroll down if I want to load the same map. It's also annoying that the scroll bar moves up if you scroll down and your computer hasn't finished loading the list. So I have two suggestions:
- Have Remake remember which map was loaded last and make it go to that specific map on the list when you press on 'load game' (which should be 'load map' I guess)
- It would also be awesome if we could 'jump' from map to map by pressing letters. For example, pressing 'k' would make the list jump to 'Kaderto', pressing 'k' twice would result in jumping to the second map that starts with a k: 'King's Bounty', etc.
This would not only be useful in the map editor, but also when selecting a map to play.

[Ben]

It's also annoying that the scroll bar moves up if you scroll down and your computer hasn't finished loading the list.

I know that my emotions are irrelevant here, but OH THE RAGE that this has given me in the past!
The Dark Lord has given simple, but great ways to improve the usability of the Remake's UI. The little things like this are what makes games great.

In addition to what he just wrote, I have another proposal; however, it is on a different issue: I find it terribly annoying when I am queuing citizens in the school,m just to see that, e.g., a farm has been built and I have to start the entire queue over again because I want my farmer trained before my new laborers and serfs. This may seem petty, but I find that I am doing this much too often, and scrolling through the school's UI takes too much of my time. My idea: What if we could click-and-drag citizens in the school to swap two citizens?

[Krom]

@TDL: Yes, even with threading maplist takes noticeable amount of time to load and that is irritating. I've added that to our todo list along with remembering last selected item and fast key input.

@Ben: School queue management - that sounds good. However I would not like to add new mechanics to to the UI (drag'n'drop) just for this single case. Maybe it can be solved by other mechanic?

[Lewin]

@TDL: Yes, even with threading maplist takes noticeable amount of time to load and that is irritating. I've added that to our todo list along with remembering last selected item and fast key input.

Since I improved the threading the map list now loads almost instantly for me (ignoring the first time of course). I mean when I change from SP to MP in the map editor main menu, the list is populated before I can even move my mouse over to the scrollbar (before it took ~4 seconds). Maybe that's just because I have an i7 and 7200 RPM disks?

Please keep in mind, this is since I improved the threading, which should have been in the more recent demos we sent TDL for testing Tower Defence (but not in the public/balance test releases).

If we wanted to improve it further we could use more than one thread for scanning, that would not be hard and will greatly speed it up for people who have more than 2 threads on their CPU (maybe other people too due to waiting for disk reads?).

Pressing a key to select the item with that letter definitely needs to be implemented.

I agree with Krom that drag and drop is not used anywhere else in the KaM UI, so maybe it would be better to do it another way. It would indeed be a useful feature though because I often find myself clearing the queue of recruits in the barracks to add a farmer then adding the recruits back.

[Krom]

Mapscan must be irritating for me because in development we often change versions or flush temp files which causes maplist to rescan all maps from scratch, which even now takes a lot of time. Accessing cached maplist is much quicker, no arguing

I doubt more threads will help cos we are limited by IO operations (maps are scattered on HDD).

[Lewin]

I doubt more threads will help cos we are limited by IO operations (maps are scattered on HDD).

More threads means one map can be loaded from disk while the other is being processed by the CPU. Maybe it will keep the disk busy for more of the time? But you could be right, it needs testing.

[Ben]

@Ben: School queue management - that sounds good. However I would not like to add new mechanics to to the UI (drag'n'drop) just for this single case. Maybe it can be solved by other mechanic?

I don't know of any other way that this could be done, really. However, I'm not sure that your argument is really that valid. The school's queue is not found anywhere else in KaM. The way it trains citizens in a queue is different, too, so maybe this drag-and-drop can be unique to the already-somewhat-unique school

[FeyBart]

Maybe Ctrl + click could put it up first in the queue, when you order the citizen to be trained?

[Krom]

@Ben: The difference is that queue mechanic is an expansion to usual order mechanic. Drag'n'drop however is relatively new mechanic that imposes objects can be picked in UI, stick to cursor and moved around freely, then released on to something. We would also need to invent cues for the player, that d'n'd is encouraged way of handling of some objects.

What if clicking on a unit in queue (except one being trained atm) would free that spot, but wont move other queued units to it, just leave a gap? Then when clicking to train new unit will put the new unit into that spot. Flaws that if you just want to cancel a unit the gap remains

Another idea, maybe an area, next to each queue item to move it to front of the queue (e.g. small arrow above)

[Ben]

@Ben: The difference is that queue mechanic is an expansion to usual order mechanic. Drag'n'drop however is relatively new mechanic that imposes objects can be picked in UI, stick to cursor and moved around freely, then released on to something. We would also need to invent cues for the player, that d'n'd is encouraged way of handling of some objects.

What if clicking on a unit in queue (except one being trained atm) would free that spot, but wont move other queued units to it, just leave a gap? Then when clicking to train new unit will put the new unit into that spot. Flaws that if you just want to cancel a unit the gap remains

The gaps sound somewhat promising, but strange. When queue reached a gap, the gap would just be eliminated, right? Still, this is very strange. I personally don't like it.

Another idea, maybe an area, next to each queue item to move it to front of the queue (e.g. small arrow above)

I don't think I understand what you mean Like a button for each box in the queue for moving the citizen in that box to the front? If so, then we are reaching yet another cluttered UI. And let the bus jokes start

Feybart's idea is alright; however, I would prefer right-clicking instead of a key-combo. What if right-clicking on a citizen moved it to the 1st box in the queue (i.e., the one below the current training citizen box)

[Krom]

Left-click removes unit from queue, right-click moves it to the front of the queue? Hm .. that could probably work best .. No UI clutter and we are continuing to use RMB for an advanced action (like with weapons: LMB order +1, RMB order +10). Anyone has any arguments against this logic? )