*i

Feel free to post. If you have any questions, feel free to ask them. You should look for some timeline someone posted a while back. Maybe someone knows what I am talking about.

Yeah, I agree this area tends to be pretty obnoxious. Fortunately, it really is the only major fight like it in the game. The problem, as you alluded, is that the conflict is too big with too much going on in different areas.

Yeah, haste is definitely not a game changing status like it was in previous games. The increase in AP was so ridiculously powerful that it pretty much became the one necessary effect to have for any fight of note. All of the effects are there, just subtle at times. To demonstrate the effect of bless, shield, etc. Save the game, and play the fight numerous times with and without the effects. On average, you should notice a difference.

Geneforge 5 has been released for Windows. Be sure to check out the demo.

If you want to know more about the race of people from beyond the ocean, play Geneforge 1.

It's been a while, but at this point you need to find information on the Portal. You will need to find two crimson rubies to proceed. It may involve finding a gem mine. I cannot remember exactly how to open up that town.

Thanks Thuryl. I added a comment on that in the paragraph below the example code.

Dice, Random Numbers, and Statistics for BoA Designers By: Stareye Blades of Avernum offers a powerful get_ran( num_dice, min, max ) command. However, fully understanding it requires a bit of statistics. Not grasping these results can produce outcomes in the game a designer did not fully expect. I'm going to go through how the results are distributed and discuss the implications on design. The simplest case is when we set num_dice to one. This uniformly samples a number between min and max. So the command get_ran(1,1,100) will produce a number between 1 and 100 where each number has an equal chance of occurring. This is useful if you want to create an event with multiple random outcomes. To do this, assign the result to a variable (call it r) and go through a series of if-then checks on the value of r. A sample code is as follows: Code: r = get_ran(1,1,100);if ( r <= bin1 ) {event1}else if ( r <= bin2) {event2}else {event3} Note that result of get_ran was assigned to a variable because each time you call get_ran, it generates a new random number -- if you need to check a random number multiple times call get_ran once, store the result, and check the variable. The probability of each event occurring is the relative width of the bin given by values bin1, bin2, and bin3. A possible application for this is have random text bubbles occur on a specific character or a creature script deciding which programmed ability to use. In this case the probability distribution is easy to understand. Now what happens if we raise the number of dice in the get_ran command? The results are now no longer uniform. The command get_ran(10,1,4) produces a number from 10-40. However, it is not distributed evenly unlike the previous ones with one die -- note that the call get_ran(1,10,40) would produce an evenly distributed set of numbers. The most likely result of our get_ran(10,1,4) command is 25 and numbers close to that. Numbers near 10 or 40 are incredibly rare. This is because when you add together lots of rolls on the die, there are far more ways to get 25 than there are 10. In fact, to get 10 requires all ten rolls equal 1. The probability of this is (1/4)^10 or around one in a million compared to 1/31 (around 3%) for the get_ran(1,10,40) call. In other words, the results from get_ran(1,10,40) and get_ran(10,1,4) are incredibly different even though they have the same range of values. Designers should keep this in mind because our previous code would produce very different results statistically if I used one versus the other. Good applications for large numbers of die are things like dealing damage or other things where you want randomness, but not a huge amount of variation. So how is the result of get_ran(10,1,4) actually distributed? This is not an easy question to answer because it requires a bit of calculus to solve correctly. However, we can often get a pretty good guess by something called the Central Limit Theorem. This handy theorem states that if we add together a lot of independent, identically distributed random variables (as we are with adding 10 dice with values from 1 to 4) the result will roughly be a normal distribution in the vicinity of the mean average. This probability distribution if very peaked about the mean average (25 in this case) and drops off very quickly as we go further away from it. In other words, high chance of getting near 25 and very low getting around 10 or 40. Know that the more dice we use, the more it follows this behavior. Note that damage from weapons (not considering armor) works this way. If a weapon produces 10-40 damage. You can just think of that number as around 25 before any damage reduction from armor kicks in. This is useful when deciding on how much armor and defensive stuff to give things so you have a good idea of how much damage is actually being done in combat. The key point with all of this is that the number of dice dramatically affects how the random numbers come out of the get_ran command. The results of, say, get_ran(20,1,3) are very different statistically than get_ran(1,20,60). Not understanding this can lead to errors in assuming how likely specific random events are in your scenario. The get_ran command is very powerful, but make sure you script in mind with how the numbers it produces are distributed.

The iPhone Geneforge not going to happen. Also, I'm not going to let this thread devolve into a classic Mac/PC flame war. For those two reasons, I'm going to lock this thread.

Thanks Nicholas!

Nicholas. I'm going to echo Thuryl. Be patient and please do not triple post; use the edit feature instead. The members here are generally helpful, but understand that they are not a 24/7 service. Also, I'm going to please ask you to make your signature less bulky. Thanks!

Unfortunately, that contest is over and for future contests no material prizes would be forthcoming as things stand. If someone can get Jeff to offer up a prize or we can get together some community pot to raise prize money, then it could be done. While I cannot speak for Jeff, past experience tells us he may be open to a few free registration keys. Cash prizes are probably something we will not see.

Quote: ...a scientific Monte Carlo simulation. Story of my life...

That said, if you are interested in making your own games, please check out Blades of Avernum or Blades of Exile.

Every script in BoA has a state that it runs every turn (call it the active state). The default is START_STATE. If you use set_state(n) in the script for the current active state, it switches the active state to be run every turn to state n. I tested this and it does work on the scenario script. I presume the same behavior works on terrain scripts as well. To answer Enraged Slith's question, I suppose you could have some terrain type that acts differently every turn after an event specific to that script has occurred. For instance, a mine could use this. The default START_STATE checks to see if the player is close to initiate the trigger and sets a new state (call it 3) that acts as a timer. After a certain number of ticks, the mine explodes and a new state (4) is set that essentially does nothing. Of course, there are other ways to do this, but this is one possibility where you could use it. EDIT: I should add that if you just want to run a snippet of code and not switch the state that is called every turn, you should use set_state_continue(n) for that. It is confusing, but the two calls are entirely different. I would prefer if Jeff called set_state something else like set_active_state or something to make the difference more clear.

I would apply anyway. Jeff has always said he needs more casual players in the testers to get better demographic information about what preferences are. The key thing really is commitment.

As I've said earlier, Jeff has had plenty of bad reviews before. He's still around. I agree with Slarty, sometimes it's better for some people to have a slightly negative view than it is for more people to have no clue it exists at all.

Quote: Well it does kind of rush into your first meeting with Rawal. You have very little idea what's going on when some person who you assume is very influential demands that you do something. At this point most people have very little knowledge about the shapers or a backstory, and have no idea where to go or what to do. Rawal does tell you to see him in his spire and gives you pretty specific directions until you leave the Whitespires. Furthermore, a lot of the story background is given in the introductory text. As someone else said, it seems like the reviewer didn't read it very thoroughly. To say that one has no idea about the world around him is a bit disingenuous; it's like complaining a novel makes no sense despite the fact he skimmed the first chapter. If he had said that the introductory text did too little to explain the background, fine, that's a valid opinion. I also grant you that we don't know everything at the beginning, but we shouldn't either. Maybe these days players expect everything spelled out to them in big bold letters, but part of the genre is to have the player to figure out a few things out for himself. If you actually take the time to talk to the people around you, a few basic things start making sense pretty quickly.

Quote: But I still think the reviewers should play past the demo. No argument here. However, I understand time limitations. If they cannot, I wish they would be more upfront with it. How hard would it be to qualify your review with "I played through the demo version and..."?

Single person RPGs are a niche genre to begin with. Add the old school aspect and it gets even more so. As I said, no one's opinion is any more or less valid than another. However, the general complaint I (and many others) have is that it appears this review is based on assumptions made from very limited information. It seems quite clear that he only played the first part. While first impressions are important, some of his comments show that he was merely making stuff up to fill in for knowledge he did not actually have. This is not his fault. I'm sure he has deadlines and a limited time to play these games. What I do find annoying is that he did not say, up front, that he was basing his review on the first couple hours of gameplay. Granted, this probably applies to ALL of the games that they review, and by saying that for everything diminishes their perceived credibility. Does not make it right, of course. I would not worry about what these reviewers say. In my experience, many of these "professional" reviewers are self-absorbed individuals that think they know everything and their opinion is fact. I'm not sure how many people actually take everything they say as such. So I would not fret too much. Jeff has gotten negative reviews in the past and still survives until this day.

Well, everyone's opinion is valid, including Holt's. Fortunately, if your opinion differs (which I suspect it would if you are around here), MacWorld is nice enough to offer the ability to comment. If you want counter this, post something articulate in response so you appear as an informed gamer with a different view and not as a fanboy.

Slarty is correct. Most scenarios that were out at the time were trash. I seem to recall a lot of empty outdoors and towns that were just plain buggy and annoying. If memory serves, we had Riddle of the Spheres and Islands of the Wheel and maybe a few other ones. Bandit Busywork is not a bad scenario by any stretch of the imagination. It is a great starter scenario for a new designer. As such, it was an example of one to help push the BoE editor. It received less than rave reviews because when compared against its contemporaries, it falls short.

Or script directions for Elmer Fudd. :-P

Visually, I prefer the flowers only. The mushrooms and the flowers seem to clash too much for my taste.

The recent BoX contests have accepted both. I would assume any future ones would be the same. This is a lot easier now that BoE is open source and can be ported to the new architectures.