Falcon

[Weregoose]

[thebetter1]

Okay, it seems to work pretty well. But what's wrong with my old method? It creates a very accurate delay and causes very little speed reduction when no delay is wanted. Also, size isn't the biggest issue, as the final game will be several hundred kilobytes anyway because of all the data.

I've been considering changes to my previous ideas for the battle system. I know that it will be possible to move forward or back, and each individual enemy can do the same. Would it look better to have the enemies on the top of the screen and you at the bottom, or the enemies at the right and you on the left? For distance, should it be a number of units (such as feet), or should it be in a few set stages (close, crossbow range, spell range, etc.)?

[Weregoose]

The space on the calculator is finite. Using double or even triple the number of bytes to accomplish what only a small number will can be thought of as just wasteful. (Obviously, the degree of that perception varies between individuals.) Though, I'd also venture to suggest that it's lazy, and maybe even inconsiderate when it comes to the amount of space that gets used up on others' calculators. Plus, as a habit, it's along the same lines as hard-coding something that ends up needing 50,000 bytes, without a concern as to how much that is, and without contemplating ways to reduce the file size (by way of selecting a different variable type, or using a loop, etc.).

We could use crude bitumen to power our vehicles. The car will still inevitably reach its destination, but it'd certainly take longer to get there; it might mean putting more into the gas tank, since much of that material would be excess sludge that the car could do without; and the engine will probably work harder for it in the long run. Furthering the analogy, one should try to figure out what combination of fuels is most efficient: use less, but keep the potency. Sure, there's testing (and retesting) involved, but mankind sure wouldn't have gotten a rocket into space by using crude bitumen.

[thebetter1]

Isn't the delay for using an Else clause supposed to be less than that of using rand though? The main issue here is speed, not size. I'm obviously not concerned with inefficiencies in speed that occur when the delay is being executed; this will simply allow me to put in fewer factorials. Ultimately, the size difference is less than 10 bytes. When you compare this to the 2kb I intentionally added to add speed over a For loop, I think it's on the right track.

[Weregoose]

Why, pray tell, couldn't you use a wait condition above rand?

Furthermore, adding bytes for a longer delay, versus changing an integer for a longer delay.

Obvious choice, if you ask me.

[thebetter1]

Oh, did I forget to mention that I switched to the rand( method weeks ago?

I'm now getting into the healing system. I'm planning on 2 hp per day, plus a 50% chance of one more, a 1/3 chance of another, and a 1/5 chance of a 5th point. The character's first aid skill will passively increase these chances; I set up the random system so that the skill value is the lower bound of the random number generated, so a higher skill gives a higher chance, and a skill of 100 guarantees that 5 hp will be recovered each day.

[thebetter1]

I'm gonna be putting this game on hold for a little while. I'm entering a game in the Omnimaga contest. Once that's done, I'll get back to this.

[thebetter1]

Okay, I got another demo out. Details are in the first post in this thread.