Code center > Suggestions
A limit for heterotroph bots, and normal veggie repro
Welwordion:
Well however you assume your bots already have learned to shoot other bots in order to increase their energy, if they do not have a way to nourish themself each generation will lose energy by costs or dieing until no energy is left within the system.
Also I think whats really making Darwinbots is ,are not visible undocumented mechanisms.
I mean come their is so much stuff you just do not know about the way bots and physics work without extensively searching the forum.
My suggestion is instead of seperating veggies and bots per se give me the option to make "classes" of bots
I then choose certain properties for them and in the menü choose which class a bots belongs to.
That way you could make more diversity without making properties invisible.
Also I always thought that it would be nice if the forces between bots could be a little more complex then justplanet eaters, maybe even with with the possibilty for bots to create pseudomass, charge for a certain energy cost?
Numsgil:
You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls. Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces. Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently. For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.
That said, I agree the options form is cluttered. It's been like that since before I joined. The current "advanced physics" window was part of my plan to create a "newbie" interface that's really dumbed down, and get people to edit "advanced" options in other panels. The problem is that it's hard to sync the two all the time, and so it creates all sorts of bugs that are hard to reproduce.
You worked at Microsoft, what's Microsoft's general strategy for user editable options? Most Microsoft software I use is generally pretty user friendly in that regard. I keep thinking that there's some sort of design pattern for GUI elements like this, like there are for class design, but if there is I've never found them.
So I don't have any answers, but this is definately an area for improvement. But it's been hobbled together for years, it can stay hobbled together for years more. Won't kill anyone, anyway
EricL:
--- Quote from: Numsgil ---You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls. Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces. Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently. For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.
--- End quote ---
Turns out the limit in VB is on actual controls be they in arrays or not. Putting controls in arrays doesn't impact the limit. I've tried it. I think VB control arrays are just a convience for addressing as far as I can tell. I'm pretty sure each control in an array still has it's own underlying Windows handle for tabbing, short keys, etc.
--- Quote from: Numsgil ---You worked at Microsoft, what's Microsoft's general strategy for user editable options? Most Microsoft software I use is generally pretty user friendly in that regard. I keep thinking that there's some sort of design pattern for GUI elements like this, like there are for class design, but if there is I've never found them.
--- End quote ---
I'm a systems guy, not a UI guy, but it was always a constant struggle to keep the UI simple in everything. Some groups are better than others, but I always thought Microsoft sucked at this in general. The knee jerk reaction, especially for enterprise apps and server admin stuff, was always just to expose another knob adn push the problem onto the customer's shoulders. The argement/defense was that there was always some customer who supposedly needed (or thought they needed) to tweak thread priorities or garbage collection schedules or something like that themselves. Generally, they never did. You see half-baked attempts in Microsoft products to simplify the underlying complexity such as the auto-shrinking menus in Office. Sounds good in therory, ends up terrible in practice.
My personal philospoghy is that if you can make it work, less UI is generally better UI. Not always of course, but in general. Every knob costs 10 times the code effort in documentation, user support, bugs, locaization, accesibility, and so on. Exposing knobs is the easy path for the coder/designer, the cop-out route. It actually takes more code, smarter code and more up-front thinking to make things elegant and auto-sensing or whatver it needs to be to not expose the knob, but in the long run, it's the right choice were it can be made. Apple is very good at this. Microsoft, not so much.
EricL:
--- Quote from: Welwordion ---Well however you assume your bots already have learned to shoot other bots in order to increase their energy, if they do not have a way to nourish themself each generation will lose energy by costs or dieing until no energy is left within the system.
--- End quote ---
I assume no such thing. I have run many zerobot sims using everything from everlasting nrg shots to benevolent shepards to supply nrg to my fledgling hetertophs until they learn to reproduce and do something to aquire nrg, even it that something is nothing more than blind reproduction. ALways reproducing means you will reproduce when you can, generally when yoru body >2, which happens when you get near an nrg source like a bleednrg bot. This alone is enough to allow first replicators to surive without being plants and to do so with costs....
--- Quote from: Welwordion ---Also I think whats really making Darwinbots is ,are not visible undocumented mechanisms.
I mean come their is so much stuff you just do not know about the way bots and physics work without extensively searching the forum.
--- End quote ---
This is true and you make a good implict point that the algorithm would have to be documented on the Wiki.
--- Quote from: Welwordion ---My suggestion is instead of seperating veggies and bots per se give me the option to make "classes" of bots
I then choose certain properties for them and in the menü choose which class a bots belongs to.
That way you could make more diversity without making properties invisible.
--- End quote ---
A species is just such a class. We use the term species like it means something. All it means in an evo sim is bots in this class had the same distant ancestor with the same set of starting properties. After the first cycle, every bot has it's own state - it's own mutation percentages, etc.
--- Quote from: Welwordion ---Also I always thought that it would be nice if the forces between bots could be a little more complex then justplanet eaters, maybe even with with the possibilty for bots to create pseudomass, charge for a certain energy cost?
--- End quote ---
Sounds interesting. I'm all for more complexity. But doesn't shell/body essentially provide this today? I.e. a way for a bot to turn nrg into mass? BTW, Planet eaters is terribly costly from a computation perspective as it is O(n^2) as currently implemented. It can slow a sim down by 100% or more.
Numsgil:
--- Quote from: EricL ---
--- Quote from: Numsgil ---You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls. Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces. Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently. For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.
--- End quote ---
Turns out the limit in VB is on actual controls be they in arrays or not. Putting controls in arrays doesn't impact the limit. I've tried it. I think VB control arrays are just a convience for addressing as far as I can tell. I'm pretty sure each control in an array still has it's own underlying Windows handle for tabbing, short keys, etc.
--- End quote ---
Au contraire. I have many warm, happy, fuzzy memories of moving labels from free floating to control arrays to free up room for new controls. Ah, the hours wasted... Anyway, you can find some informal proof in these discussions, where it's mentioned as the way around the limit. Not that I'm saying we need more controls!
I think we need to take a Thoreau view towards GUIs and simplify, simplify, simplify. But at the same time some functionality needs to be modifiable outside the source code, for specialized needs. I'm not sure what a good solution is. However, in general, these are the guidelines that I work with (in general, not just Darwinbots):
* New users don't like controls
* Experienced users like controls
* Some settings are tweaked quite often, and should be easy to modify.
* All settings need to be tweakable somehow.
* Their should be a practical widget for every control. (As an example where this failed: Visual Studio 2005 let's you change the intermediate directory for C# projects only by editing the .csproj file in a text editor, and even then finding that you can do this is hard since the .csproj files and options aren't well documented.)The requirements as listed suggest a hierarchy of options: one top level that is as simple as possible, and a sub layer where more controls are exposed. However, then you run in to problems of how to display settings in the newbie top layer that have been tweaked in the advanced sub layer. And there are problems with ensuring that both forms are in sync with the game data and each other. Adding a new control requires modifying both forms, and you've effectively doubled the maintenance for GUI components.
Another option, as I mentioned, is to allow users to edit "advanced" features by editing the settings file as a text document. But this always has the feel that what you're doing is back-door and sneaky, especially if the rest of the program is totally GUId. As the case with Visual Studio demonstrates.
Also, the optimal solution, from a programmer's standpoint, needs to provide a zero-error way to add new controls and sync them with the game data. This means one point in the code where all forms communicate with the settings structure, and one place where the settings communicate with the GUI. Preferably the same place, and preferably it could be done automatically in some way.
So I don't know a good solution, but I'll keep thinking about it.
--- Quote from: Numsgil ---...Apple is very good at this. Microsoft, not so much.
--- End quote ---
I guess I think like a developer. I don't use many Apple products, but almost every program I use daily is Microsoft. And I understand how the products I use work, and can tell you what almost every option or field does.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version