1
DF Dwarf Mode Discussion / Re: Oceanside site
« on: January 02, 2010, 12:07:40 pm »
I would like to get the world gen stuff for that.
Bay 12 Games Forum
- April 18, 2024, 05:13:22 am
- Welcome, Guest
News:
March 6, 2024: Dwarf Fortress 50.12 has been released.
News: February 3, 2024: The February '24 Report is up.
News: February 4, 2021: Dwarf Fortress Talk #28 has been posted.
News: November 21, 2018: A new Threetoe story has been posted.
Forum Guidelines
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
DF Modding / Re: Object Relationship Database
« on: December 18, 2009, 10:28:32 pm »
I placed it here as it was the most fitting place I could find. The idea is that it would help modders who are looking to add something to the game, they don't know what they wish to add, but they know they want to add something. Now as Lancensis stated the potential list is infinite, and that is why you use the knowledge of a group to help you come up with more then you could on your on in a reasonable time period. While my examples are simple there must be times when you are working and you wish to add some more units types but can't think of anything that relates to your theme (if you have one). In that case you could query the information other people have inputted to come up with related objects or at least get some inspiration. Say you wished to add a whole mess of demons to the game that are based off real legends. You could spend the time and find the more well known ones rather quickly or (assuming people have added it to the database) you could run a search on objects related to demons and come up with a list of types of demons, what demons can do, do they use tools, who are their enemies, who are their allies. All that information to help you create a more complete mod. Sure small details like the fire / fuel example I gave may never be implemented but that could give rise to an idea about some unit type, some item, or some type of building.
The whole point is that it would act as a place to look up a wide range of objects related to something you are searching for. Based off peoples initial reaction I don't believe it would get the use it requires inorder to be useful. It might have to do with the way I described it, or my idea has too wide of scope. It is an idea none the less that could help a lot of people who are having a brain fart.
The whole point is that it would act as a place to look up a wide range of objects related to something you are searching for. Based off peoples initial reaction I don't believe it would get the use it requires inorder to be useful. It might have to do with the way I described it, or my idea has too wide of scope. It is an idea none the less that could help a lot of people who are having a brain fart.
3
DF Modding / Re: Object Relationship Database
« on: December 18, 2009, 04:42:44 pm »
The objective doesn't have anything to do with code. The idea is to reduce the amount of time thinking about what specific objects can do and what they can react with. So instead of a person spending an hour or more trying to figure out how one object interacts with its environment they could query the database for that information.
When it comes to code people do ask "what can a goblin do?" and its much more complex then you think. Goblins can start a siege, retreat from a siege, send a child kidnapper, send a small ambush party, equip themselves with armor and weapons, break a dwarf into servitude, create massive towers,... there is a whole shit load of things goblins can do in game currently and a whole shit more possible things they could be programmed to do. The idea is to make that list so if Toady or someone else decides they wish to add something cool they have a massive list for ideas.
The Fire/Fuel isn't incoherent. It is a set of relationships between objects. You could have Fire ignites Fuel but that simplifies the overall idea. By using heat you allow for fire to increase the temperature of an area. You allow for fire that isn't hot enough to light specific fuels. The idea is that by breaking the simplified reaction down to smaller pieces you can allow for a more complex reaction that is easier to handle.
When it comes to code people do ask "what can a goblin do?" and its much more complex then you think. Goblins can start a siege, retreat from a siege, send a child kidnapper, send a small ambush party, equip themselves with armor and weapons, break a dwarf into servitude, create massive towers,... there is a whole shit load of things goblins can do in game currently and a whole shit more possible things they could be programmed to do. The idea is to make that list so if Toady or someone else decides they wish to add something cool they have a massive list for ideas.
The Fire/Fuel isn't incoherent. It is a set of relationships between objects. You could have Fire ignites Fuel but that simplifies the overall idea. By using heat you allow for fire to increase the temperature of an area. You allow for fire that isn't hot enough to light specific fuels. The idea is that by breaking the simplified reaction down to smaller pieces you can allow for a more complex reaction that is easier to handle.
4
DF Modding / Object Relationship Database
« on: December 17, 2009, 06:36:46 pm »
So I was thinking of what could help a lot of people when coming up with what to add to DF and I came up with the idea of crowd sourcing object relationships. Basically what my idea is anyone who wanted to help would go to a web page, and input some information for others to use so they don't have to spend time thinking "what can a goblin do?". Instead they would ask the database and get a list.
The general idea is we have two objects that are related by some type of relation ship.
Person has Hair
In this case the two objects are Person and Hair and the relation ship is has. A more complex set of relationships might be
Fire consumes fuel
Fire radiates heat
Heat ignites fuel
This would be a set of relationships that when applied together would allow for fire to essentially explode when it comes into contact with fuel. The thought process is fire grows as it consumes fuel. As fire grows so does the amount of heat it radiates. The heat ignites fuel around the fire thus increasing its size yet again. Then the cycle continues until there is no fuel left.
The web page would be incredibly simple and have a search (which I would ask everyone to use before they input some relationship to prevent a mass of similar entries). Basically you select from a list of objects already in the database (searchable) and a list of relationships (searchable) and apply it. You would also be able to add objects and relationships should they not be listed.
If I made such an application how many would be willing to add a few things here and there?
The general idea is we have two objects that are related by some type of relation ship.
Person has Hair
In this case the two objects are Person and Hair and the relation ship is has. A more complex set of relationships might be
Fire consumes fuel
Fire radiates heat
Heat ignites fuel
This would be a set of relationships that when applied together would allow for fire to essentially explode when it comes into contact with fuel. The thought process is fire grows as it consumes fuel. As fire grows so does the amount of heat it radiates. The heat ignites fuel around the fire thus increasing its size yet again. Then the cycle continues until there is no fuel left.
The web page would be incredibly simple and have a search (which I would ask everyone to use before they input some relationship to prevent a mass of similar entries). Basically you select from a list of objects already in the database (searchable) and a list of relationships (searchable) and apply it. You would also be able to add objects and relationships should they not be listed.
If I made such an application how many would be willing to add a few things here and there?
5
DF Suggestions / Re: Multi-threading?
« on: December 17, 2009, 06:27:28 pm »
I did my masters thesis on parallel processing and as of right now it is highly dependent on the project. It is very difficult to multi-thread some applications due to dependencies on previous tasks. In fact doing so will most likely decrease the speed of an application. Take this as an example,
Job A requires Job B
Job C requires Job A
Both B and C require A to be completed. This can have some parallel processing but there is no easy way to add this into an application. Also by doing so there are increased chances of bugs. Job B and C should not access the same data at all. Doing so could mean sync bugs popping up which are incredibly difficult to find as they are essentially random. (Due to how OS's handle mutli-threading).
There are simple tasks that can be threaded such as for loops that don't require previous input. As I don't know how the code works for DF I can only give a few examples but I believe the modified A* algorithm could be one such area. Instead of calculating the path of 10 dwarves one after the other you could thread the loop to calculate 5 dwarves and 5 dwarves. Which gives you a max speed benefit of 2x. I do not believe each dwarf gets a path calculated every time step as that would be such a waste of processing power. Most likely pathing is queue based so entities that need paths are added to a queue and every x time step some are given a path. In this case multi-threading wouldn't give much benefit (if any) and it would require a major rework of the back end.
Another would be temperature. I believe temp would be a good threaded area as it could be well separated from the main code. This means the number of variables shared between threads would be drastically reduced making the task much easier. Since temp is a huge hog of CPU cycles throwing it on another thread would be a viable solution as long as all temp information is double buffered. The reason being the temp at a location might change by 1 unit and while that memory address is being written, the other thread would read it and get some strange piece of data. This would have an extremely small chance of happening but it would be incredible strange to have a dwarf burst into flames because the main processing thread read the temp of the cell he was on as 10000 while the memory data was being changed. (though it would be comical).
However, as has been stated we don't have ANY clue what the code for DF looks like. Because of that everything I have stated is an assumption of how I would program such an application as of this moment. The actual implementation could be TOTALLY different. That said with programming anything is possible and it all depends on time and the amount of complexity you are willing to deal with.
Job A requires Job B
Job C requires Job A
Both B and C require A to be completed. This can have some parallel processing but there is no easy way to add this into an application. Also by doing so there are increased chances of bugs. Job B and C should not access the same data at all. Doing so could mean sync bugs popping up which are incredibly difficult to find as they are essentially random. (Due to how OS's handle mutli-threading).
There are simple tasks that can be threaded such as for loops that don't require previous input. As I don't know how the code works for DF I can only give a few examples but I believe the modified A* algorithm could be one such area. Instead of calculating the path of 10 dwarves one after the other you could thread the loop to calculate 5 dwarves and 5 dwarves. Which gives you a max speed benefit of 2x. I do not believe each dwarf gets a path calculated every time step as that would be such a waste of processing power. Most likely pathing is queue based so entities that need paths are added to a queue and every x time step some are given a path. In this case multi-threading wouldn't give much benefit (if any) and it would require a major rework of the back end.
Another would be temperature. I believe temp would be a good threaded area as it could be well separated from the main code. This means the number of variables shared between threads would be drastically reduced making the task much easier. Since temp is a huge hog of CPU cycles throwing it on another thread would be a viable solution as long as all temp information is double buffered. The reason being the temp at a location might change by 1 unit and while that memory address is being written, the other thread would read it and get some strange piece of data. This would have an extremely small chance of happening but it would be incredible strange to have a dwarf burst into flames because the main processing thread read the temp of the cell he was on as 10000 while the memory data was being changed. (though it would be comical).
However, as has been stated we don't have ANY clue what the code for DF looks like. Because of that everything I have stated is an assumption of how I would program such an application as of this moment. The actual implementation could be TOTALLY different. That said with programming anything is possible and it all depends on time and the amount of complexity you are willing to deal with.
Pages: [1]