Im just gonna re-install it all, what all do i need to run game.py?
Follow the instructions in my screencast series to do easy_install and virtualenv. There is a requirements file in the repository you can use with pip pip install -r requirements.txt However, for pygame to install properly, you will have to first use apt-get to install some sdl libraries. I will make a complete list when I get a chance. I plan to start working on this again today and tomorrow.
In other news check this out. It's the Google Native Client SDK. The idea is that you want to make a web application with HTML, Javascript, CSS. However, some part of the web application should be written in native code, like C. The example they use is a video editing web app. If you don't want to use something like flash, you can use the NaCl (lol!).
This is still beta, and Chrome only, and such, but it just might be the kind of thing that would be good for this project. It would make it easy for us to get it to run in a browser.
I think the primary problem in Dwarf Fortress is that it's not entirely clear whether you control the dwarves, or if you don't.
What now? Now you're just making up 'problems' to support your idea, that one doesn't even exist. It's clear as day what you control, in adventurer mode you control one adventurer, and in fortress mode you control the fortress, resources and what work needs to be done, which the dwarfs will eventually do, and everyone wishes they would stop partying and get that work done. Seriously, play the game, you JUST give orders and control resources, nothing more.
Since you asked for my thoughts, have them: I'll call your bullshit. Your entire premise to your 'great' idea is wrong Scott, using such tactics to make you look smart and amazing to those who have no fucking clue what you're talking about is quite sad, please don't bother with that again. And please, do implement, and enjoy implementing, the same things as Toady One, they're good things that make DF fun to play.
What now? Now you're just making up 'problems' to support your idea, that one doesn't even exist. It's clear as day what you control, in adventurer mode you control one adventurer, and in fortress mode you control the fortress, resources and what work needs to be done, which the dwarfs will eventually do, and everyone wishes they would stop partying and get that work done. Seriously, play the game, you JUST give orders and control resources, nothing more.
Since you asked for my thoughts, have them: I'll call your bullshit. Your entire premise to your 'great' idea is wrong Scott, using such tactics to make you look smart and amazing to those who have no fucking clue what you're talking about is quite sad, please don't bother with that again. And please, do implement, and enjoy implementing, the same things as Toady One, they're good things that make DF fun to play.
Nobody agrees with you. If DF was so great, we wouldn't be re-coding it. It has tons and tons of serious flaws. The only things good about the game at all is the fundamental concept that cool stories can emerge from a combination of detailed simulations and the artistry of designing a fortress.
Nobody agrees with you. If DF was so great, we wouldn't be re-coding it. It has tons and tons of serious flaws. The only things good about the game at all is the fundamental concept that cool stories can emerge from a combination of detailed simulations and the artistry of designing a fortress.
Im just gonna re-install it all, what all do i need to run game.py?
Follow the instructions in my screencast series to do easy_install and virtualenv. There is a requirements file in the repository you can use with pippip install -r requirements.txtHowever, for pygame to install properly, you will have to first use apt-get to install some sdl libraries. I will make a complete list when I get a chance. I plan to start working on this again today and tomorrow.
In other newscheck this out. It's the Google Native Client SDK. The idea is that you want to make a web application with HTML, Javascript, CSS. However, some part of the web application should be written in native code, like C. The example they use is a video editing web app. If you don't want to use something like flash, you can use the NaCl (lol!).
This is still beta, and Chrome only, and such, but it just might be the kind of thing that would be good for this project. It would make it easy for us to get it to run in a browser.
Sorry I haven't gotten back on task with DORF yet. I have to do a bunch of work on frontrowcrew.com that I keep doing on and off. Procrastinating on it is literally costing me money. Once that's all done, DORF will be my only coding outside of work.
Since I'm in the middle of exams and I still have another week to go, I'll take a stab at it once I'm done. I've peeped at the code though and I'm having a hard time understanding it.
I started just to make sure I knew enough to join in, but this was never something I was going to spend a lot of time on while at home. Once I'm away on work trip I plan to get into it a lot more.
I offloaded the rendering into a separate rendering class, and introduced a method for updating a single grid square in the terrain, which Luke was looking for. As it stands, the mover would still need a reference to the renderer or the rendering method in order to update the terrain, though. If anyone has a better idea as to how to interface with the renderer, feel free to describe and/or implement it.
I looked at the last commit by Jormungandr/Alex, but it seems to be inoperable because it lacks the addition of the terrain.climate module which seems to be necessary for it to work.
Wiscocrew's Hiders and Seekers are interesting, although it seems like they could be handled more efficiently.
Yeah, I figured since you used the same icon in Github and you posted about it in this thread. I haven't looked at what you've done in detail yet, though. In any case, the more people we can get thinking seriously about algorithms, the better, and the hider/seeker thing should be a nice starting point.
Of course, I could be wrong, and there might not be a better way to do it.
Python 3D engines: Panda 3D looks like the best, and unlike most of the alternatives is actually complete. So if anyone suddenly feels moved to translate the game into 3D, that'd be my recommendation. For now, it seems like more complexity than it's worth.
Also, I pushed the missing file mentioned by lackofcheese. And I agree that high-level commands to the AI along the lines of what Luke/Scott/cheese were discussing is the way to go. Along those lines:
1) Game AI frequently makes use of state machines and/or behavior trees (which are a special, hierarchical kind of state machine). This is perfectly compatible with the sort of system under discussion. Now anyone who wants to work on this has terms to search for.
2) We should consider a probabalistic approach, particularly if we're modelling a large number of actors (dwarves). A simplified example of this: take a group of dwarves whose goal weights are 70% "build rooms", 10% "make jewelry" and 20% "gather food". When any given dwarf is looking for something to do, those percentages are the chance he'll choose that goal. Goals are then made up of a number of component tasks that must be executed in sequence before he can choose a new one (barring some extreme circumstance); this sort of structure is, again, where behavior trees come in.
Does anyone have any thoughts on the Renderer class? I was thinking about it and I decided that it was obvious that it should be modular, to allow us to swap one renderer for another without any difficulty (even in-game!). I'm thinking there should be a Renderer class that all Renderers inherit from, but I couldn't work out how to structure things; also, at the moment, the ViewPort is sitting inside the Renderer because that was the best I could come up with. As it is now, it's definitely a significant improvement to the previous structure, but it could be much better.
I agree with Alex about the probabilistic approach, but how are we going to set things out when there could potentially be quite a large, and, more importantly, variable number of goals? I guess we could have weights and the proportion of an individual weight to the sum of all the weights would be the probability of a goal, but I'm not sure if that's the best approach. If you had to force a task in "god mode", would you then set the weight to infinity?
I'm almost done rewriting frontrowcrew.com and moving it to the new server. I haven't made improvements or changes to it yet, at least not anything big. I've just rearchitected it to not such as much, so that it will be easier to start making bigger changes when I get around to it. It will be done this weekend, as Monday is a holiday. Once it launches, DORFing will resume forthwith.
Almost done with the stuff for frontrowcrew.com. I'm on schedule to finish all that jazz tomorrow. IDShare will also be down tonight, but I don't think anyone cares or would even have noticed, if I didn't say anything.
Yeah, I keep thinking about it, but every time I sit down to code lately I just want to work on the web site and such. I'm sure that will fade once I knock out a bunch of the big features I have planned.
I've been working on a roguelike with pygame & pyopengl for awhile now. I've managed to tackle some of the hardest engine problems (IMHO) including things like
-Caching the map graphics with opengl buffers so the engine isn't slow (Even just rendering the game was taking > 1 second before using opengl and vertex buffers) -Making sure that ascii-art walls line up correctly when placed next to each other (this sounds easy, but with opengl, mip mapping, texture scaling, etc. this is a total pain and took weeks to get right). -A simplified version of Hierarchical Task Networks so the agents in the system can be assigned tasks and the priorities of tasks can be dynamic and change in realtime. -GUI using PyUI -Random map generation including random buildings with rooms that take up all available space.
I'm actually using it to make a horror roguelike at the moment, but I have no problem giving the source code early if you guys think it will be useful.
Word of advice: Making dwarf fortress (or any game) takes at least a year minimum. Plan out as much as possible with a program like Freemind. When I made Underworld Hockey Club, I wanted to see a skeleton get bodychecked through the glass so much I didn't design anything outside of the hitting and bodychecking mechanics. That caused massive delays and a lack of polish even when the game was released.
I think the main problem with this project at the moment is lack of direction. I'd be putting some work in if I knew what to do, but I really don't. I guess I need to think about it some time.
Comments
pip install -r requirements.txtHowever, for pygame to install properly, you will have to first use apt-get to install some sdl libraries. I will make a complete list when I get a chance. I plan to start working on this again today and tomorrow.In other news check this out. It's the Google Native Client SDK. The idea is that you want to make a web application with HTML, Javascript, CSS. However, some part of the web application should be written in native code, like C. The example they use is a video editing web app. If you don't want to use something like flash, you can use the NaCl (lol!).
This is still beta, and Chrome only, and such, but it just might be the kind of thing that would be good for this project. It would make it easy for us to get it to run in a browser.
Since you asked for my thoughts, have them: I'll call your bullshit. Your entire premise to your 'great' idea is wrong Scott, using such tactics to make you look smart and amazing to those who have no fucking clue what you're talking about is quite sad, please don't bother with that again. And please, do implement, and enjoy implementing, the same things as Toady One, they're good things that make DF fun to play.
I do have something of an excuse, because in the past week I've moved house and gotten sick.
I looked at the last commit by Jormungandr/Alex, but it seems to be inoperable because it lacks the addition of the terrain.climate module which seems to be necessary for it to work.
Wiscocrew's Hiders and Seekers are interesting, although it seems like they could be handled more efficiently.
In any case, the more people we can get thinking seriously about algorithms, the better, and the hider/seeker thing should be a nice starting point.
Of course, I could be wrong, and there might not be a better way to do it.
Also, I pushed the missing file mentioned by lackofcheese. And I agree that high-level commands to the AI along the lines of what Luke/Scott/cheese were discussing is the way to go. Along those lines:
1) Game AI frequently makes use of state machines and/or behavior trees (which are a special, hierarchical kind of state machine). This is perfectly compatible with the sort of system under discussion. Now anyone who wants to work on this has terms to search for.
2) We should consider a probabalistic approach, particularly if we're modelling a large number of actors (dwarves). A simplified example of this: take a group of dwarves whose goal weights are 70% "build rooms", 10% "make jewelry" and 20% "gather food". When any given dwarf is looking for something to do, those percentages are the chance he'll choose that goal. Goals are then made up of a number of component tasks that must be executed in sequence before he can choose a new one (barring some extreme circumstance); this sort of structure is, again, where behavior trees come in.
As it is now, it's definitely a significant improvement to the previous structure, but it could be much better.
I agree with Alex about the probabilistic approach, but how are we going to set things out when there could potentially be quite a large, and, more importantly, variable number of goals? I guess we could have weights and the proportion of an individual weight to the sum of all the weights would be the probability of a goal, but I'm not sure if that's the best approach. If you had to force a task in "god mode", would you then set the weight to infinity?
I've been working on a roguelike with pygame & pyopengl for awhile now. I've managed to tackle some of the hardest engine problems (IMHO) including things like
-Caching the map graphics with opengl buffers so the engine isn't slow (Even just rendering the game was taking > 1 second before using opengl and vertex buffers)
-Making sure that ascii-art walls line up correctly when placed next to each other (this sounds easy, but with opengl, mip mapping, texture scaling, etc. this is a total pain and took weeks to get right).
-A simplified version of Hierarchical Task Networks so the agents in the system can be assigned tasks and the priorities of tasks can be dynamic and change in realtime.
-GUI using PyUI
-Random map generation including random buildings with rooms that take up all available space.
I'm actually using it to make a horror roguelike at the moment, but I have no problem giving the source code early if you guys think it will be useful.
Word of advice: Making dwarf fortress (or any game) takes at least a year minimum. Plan out as much as possible with a program like Freemind. When I made Underworld Hockey Club, I wanted to see a skeleton get bodychecked through the glass so much I didn't design anything outside of the hitting and bodychecking mechanics. That caused massive delays and a lack of polish even when the game was released.
Edit: Duh, Python is cross-platform.
I think the main problem with this project at the moment is lack of direction. I'd be putting some work in if I knew what to do, but I really don't. I guess I need to think about it some time.