Print

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

[alamoes]

I always thought that civilization could be simulated with simple voting rules.  First, the people of a family eventually learn to elect a leader.  The leader gets old.  He tries to make sure *someone he trusts* gets the succession.  People elect different guy upon death.  Fighting ensues.  If monarchs son gets it the people will be sad, but eventually try again to restore monarchy.  If the elected gets it, he will try to get his son in power causing possible fighting again.  Fighting can occur in stalemate.  Losers become #slaves# based on law.   This was inspired by CK2 motives.  I want CK2, but I gots macs 

*often family, because you know family won't do bad. 
#worst case scenario they become slaves and slavery is invented.  Best case they lose a title.

Somehow one day I will translate this into numbers and chances.  But for now I give you this very, very, very watered down look into my convoluted and biased (towards liberalism of course ) mind. 

[Leatra]

If you don't implement multithreading now, you'll have lots of fanboys (including me) begging you to include it later

Just look at Dwarf Fortress. People debated about it for a long time but I understand. It could mean Toady spending a year rewriting codes for multithreading. You don't just go "meh, I'll multithread this shit" while in development.

[Ultima Ratio Regum]

Well, Core speed will continue to speed up... but mostly on high end CPU since Intel seems to fight on smaller and more low power CPU. But prefetch, better cache, technologies like "turbo boost" and maybe new instructions will help maintaining single core perf.

As for multithreading, use "import threading" in Py http://docs.python.org/library/threading.html. At first I recomande you to multithread only different part of your program ( like the logs, the UI, the music and the AI that aren't related ). Then you can monitor witch thread is the bottleneck, and try to make like one thread for ally AI, and another for the foe, then another for faraway combats. You know, with proper multithreading, my fortress in DF could at least three time bigger. 

That makes a lot of sense. Thing is, though, Python seems to imply it still only uses one thread 'at once', so I'm unclear how this is faster than just using a single thread. Excuse my hardware ignorance . Surely using multiple cores, but in sequence, is no different from using one? Still, I've started looking at the documentation for the multithreading Python stuff...

I always thought that civilization could be simulated with simple voting rules.  First, the people of a family eventually learn to elect a leader.  The leader gets old.  He tries to make sure *someone he trusts* gets the succession.  People elect different guy upon death.  Fighting ensues.  If monarchs son gets it the people will be sad, but eventually try again to restore monarchy.  If the elected gets it, he will try to get his son in power causing possible fighting again.  Fighting can occur in stalemate.  Losers become #slaves# based on law.   This was inspired by CK2 motives.  I want CK2, but I gots macs 

*often family, because you know family won't do bad. 
#worst case scenario they become slaves and slavery is invented.  Best case they lose a title.

Somehow one day I will translate this into numbers and chances.  But for now I give you this very, very, very watered down look into my convoluted and biased (towards liberalism of course ) mind.

I think that would all be awesome. Some of that is being incorporated in the very basic histories I'm having the game generate for now, though these will only get more advanced as time goes on. Whoever leads a particular group - be it a bandit chief of the king of an empire - should have a history (of varying length) behind them explaining how they got that position/throne, and what's happened since they got it. Once you enter as a player character, you should be able to get to the top in the same ways...

If you don't implement multithreading now, you'll have lots of fanboys (including me) begging you to include it later

Just look at Dwarf Fortress. People debated about it for a long time but I understand. It could mean Toady spending a year rewriting codes for multithreading. You don't just go "meh, I'll multithread this shit" while in development.

I'm thinking about it ! I'm just not clear what the advantage is to using many if Python only actually accesses one at once. But maybe I'm misunderstanding this. Anyway - I'll keep looking into it this week, and I'll post here once I've made a decision (which is to say, once I've understood it...)

Meanwhile, this week's devblog is on species-specific name generation. I think it's producing some great dwarf names and elf ones, but I think the human names might need a little work... thoughts?

http://www.ultimaratioregum.co.uk/game/2012/02/27/whats-in-a-name/

[Lord Dullard]

Well, Core speed will continue to speed up... but mostly on high end CPU since Intel seems to fight on smaller and more low power CPU. But prefetch, better cache, technologies like "turbo boost" and maybe new instructions will help maintaining single core perf.

As for multithreading, use "import threading" in Py http://docs.python.org/library/threading.html. At first I recomande you to multithread only different part of your program ( like the logs, the UI, the music and the AI that aren't related ). Then you can monitor witch thread is the bottleneck, and try to make like one thread for ally AI, and another for the foe, then another for faraway combats. You know, with proper multithreading, my fortress in DF could at least three time bigger. 

That makes a lot of sense. Thing is, though, Python seems to imply it still only uses one thread 'at once', so I'm unclear how this is faster than just using a single thread. Excuse my hardware ignorance . Surely using multiple cores, but in sequence, is no different from using one? Still, I've started looking at the documentation for the multithreading Python stuff...

Believe me when I say that using the threading module still speeds multiple threads up significantly. That's all I've been using so far, because I started coding Cult when Python was on version 2.4, but you should also know that Python 2.6 just came out with a module that does implement true multiple processes by circumventing the global interpreter lock: http://docs.python.org/library/multiprocessing.html

I'm probably going to be switching over to that module in the next couple of weeks. Can't tell you about the speed difference yet, but I imagine it'll be considerable, at least on a machine like the one I'm using (four core @ 3.4ghz/core).

But yes, right now, even just using the old module... still big speed leaps.

[Leatra]

This quote is from my reply to the latest devblog post. Just wanted to see what people would think of this idea.

I also thought about lore as a skill. I’m not sure if it’s a good idea or not. I’m talking about things like necro lore, infernal lore, ocean lore, nature lore, mythological lore, etc. For example, if you have a very low necro lore, your character can’t tell the difference between a lich and a zombie. If your character has a very high necro lore, your character can identify necromancers at sight. When you encounter a human necromancer he would be identified as an ‘a male human necromancer’. Lore skills could be learned by reading books.

It sounds a little hardcore role-playing but I’m just brainstorming. Feel free to use the idea however you like. Maybe add a ‘magic lore’ skill so players can identify spells and spellcasters.

[Ultima Ratio Regum]

Believe me when I say that using the threading module still speeds multiple threads up significantly. That's all I've been using so far, because I started coding Cult when Python was on version 2.4, but you should also know that Python 2.6 just came out with a module that does implement true multiple processes by circumventing the global interpreter lock: http://docs.python.org/library/multiprocessing.html

I'm probably going to be switching over to that module in the next couple of weeks. Can't tell you about the speed difference yet, but I imagine it'll be considerable, at least on a machine like the one I'm using (four core @ 3.4ghz/core).

But yes, right now, even just using the old module... still big speed leaps.

Cool. In that case, I'll try putting it in. At least, I'll try figuring it out, since I have to confess I can't make *any* sense of it right now. A few questions, then, if you've got it working - how significant is the issue in the red box at the top of that page? And it says it only works for windows/unix; for a mac release, would I have to remove it all? And, lastly, how hard was it to implement the old version (and what stage did you start putting it in at)?

Hey, I just had a thought:
will the materials be like DF or more like other RPGs as in, like DF, will a warhammer be super effective if made out of silver, but steel or some other light metal will be crap for a hammer, and vice versa for stabby/slashy weapons?

As it so happens, one of the things I did yesterday was create a database of all materials and what effects they have. So, yes! Crappier materials will make a big difference. It also allowed me to make "flesh" a proper material for "weapons" that are the severed limbs of foes, which was obviously great.

...

I think it's a great idea - see reply on blog!

[gimli]

It's ridiculously handy (the multi-threading, that is).

This is looking really cool. Can't wait to play. 

Is it? Interesting. Maybe I should look more into it... and thanks ! Gearing up for a week of pretty solid coding from Saturday onwards at the moment, by the end of which I'm hoping for a lot of progress on creatures/combat etc...

These days, multithreading is almost a coding requirement. Core speeds won't be going up by much anymore, just the number of cores and multithreading efficiency will keep increasing.

This is correct....at one point [when tons of new features will be added] DF will be extremely slow since it's only using 1 core. +1 for gfx but it's no biggie. The FPS in fortress mode is aleady very low if your fortress is big enough. [My processor is E8400 3Ghz]

[Lord Dullard]

Cool. In that case, I'll try putting it in. At least, I'll try figuring it out, since I have to confess I can't make *any* sense of it right now. A few questions, then, if you've got it working - how significant is the issue in the red box at the top of that page?

From a brief check of the linked issue page, it appears to affect OpenBSD/FreeBSD/related platforms. I guess the seriousness depends on how multi-platform-friendly you are determined to make your game.

And it says it only works for windows/unix; for a mac release, would I have to remove it all? And, lastly, how hard was it to implement the old version (and what stage did you start putting it in at)?

That I can't tell you, unfortunately. As for the difficulty of implementation, it can be a bit tricky to learn how to have two processes running in parallel that don't interfere with each other or do weird things to your output, but it's not too crazy to figure out. The actual code structure itself is relatively simple; you create a class that inherits from the multiprocessing class provided in the module, then set it up as instructed, and run it by creating an instance of the class and using, say, MyThreadingInstance.start().

I think I started using it... geez, I can't recall exactly, but originally it was just for some lightweight trickery with a couple of display classes that did fancy things like fading text and variable lighting and whatnot, so pretty early on. But you could always switch over something like your pathfinding algorithm just by restructuring the way it works. Even if you only switch pathing to multiprocessing, you'll likely still see a big boost in game speed.

[Leatra]

...

I think it's a great idea - see reply on blog!

Awesome!

Now that you mention it, I'm very curious about the skill table. I think skills and attributes are essential in RPGs and the power of the character you are role-playing is much more important than the skill of the player.

[Man of Paper]

Will we be able to load people into catapults and launch them over walls haphazardly?

[Leatra]

Will we be able to load people into catapults and launch them over walls haphazardly?

It's funny how many people ask that

[Man of Paper]

Will we be able to load people into catapults and launch them over walls haphazardly?

It's funny how many people ask that

I ask only because if the answer is yes, that means I may be able to launch corpses, or my enemy's corpses, or maybe even my enemy's flaming corpses.

[darkflagrance]

Will we be able to load people into catapults and launch them over walls haphazardly?

It's funny how many people ask that

bay12 and you wonder WHY people ask that?

Ironically, in Dwarf Fortress the only thing catapults can launch are rocks. Not even flaming rocks. And they don't even do much damage. 

[varsovie]

Will we be able to load people into catapults and launch them over walls haphazardly?

It's funny how many people ask that

bay12 and you wonder WHY people ask that?

Ironically, in Dwarf Fortress the only thing catapults can launch are rocks. Not even flaming rocks. And they don't even do much damage. 

once seige weapons are moddable, someone will make a dragon firing ballistapult.

The ability to launch elven children is the bare minimum. Bonus point if the catapult is mounted on a flying carp.

[Nighthawk]

Will we be able to load people into catapults and launch them over walls haphazardly?

It's funny how many people ask that

bay12 and you wonder WHY people ask that?

Ironically, in Dwarf Fortress the only thing catapults can launch are rocks. Not even flaming rocks. And they don't even do much damage. 

once seige weapons are moddable, someone will make a dragon firing ballistapult.

The ability to launch elven children is the bare minimum. Bonus point if the catapult is mounted on a flying carp.

Why mount the catapult ON the carp and fire elven children when you could be FIRING the carp AT elven children?
Or maybe you could fire elven parents at their own children... that would be even crueler.