The Map Keeper

[spotlessmind1975]

My only issue with ugBasic so far is there doesn't seem to be that many games made with it which makes me question it.

This specific feature is recent, and the language is quite young.
Regardless, if it saves time, it comes in handy despite this.
You can also use inline assembly seamlessy, if needed.

Yup I know why C is slow on 8 bit processors, which is the main reason I program in ASM on the speccy.

Maybe there was a misunderstanding.

All your points about assembly are definitely valid, but they have one flaw: you have to know both language and hardware details. And, to develop a game or just a prototype, you must master both. Ultimately, in my opinion, it's just too much effort for a prototype. The reason for choosing a high-level language, in the end, is just this.

The real point is that the choice usually falls on C because it is known and widespread. There are also good cross compilers (like z88dk) which avoid compiling directly on the hardware, and that makes possible to work with hardware thanks to libraries. In my humble opinion, on 8-bit targets, there could be specialized languages which could give better results than C.

Does ugBasic not support recursive functions then if it does not use the stack if it can help it?

Sincerely, I don't think recursive functions are very useful in a real-time computing context with 8-bit processors. And, even if they were, they can always be translated into an iterative algorithm (which are usually more efficient, for the reason you well explained when you explained how you use Z80 registers). Furthermore, the stack is poorly suited to efficient multitasking, especially with a large number of tasks where each one claims to have its own.

I guess you picked Basic as the syntax for ugBasic because many people interested in retro coding will have used Basic originally then.

The reason BASIC was chosen is not because C or Python were particularly complex, at least in terms of syntax, to write a parser for. The reason is the same why it was chosen in '80 as the language of choice for 8-bit home computers: it was not created for a specific purpose, it was not very formal and it had a very gentle learning curve. Characteristics that it still has today, unlike many other languages, including C and Python.

It also fits perfectly with the concept of "isomorphism" which is the basis of ugBASIC. In a nutshell, there is no rigid separation between language and hardware and, at the same time, there is no "abstraction" to support multiple targets that introduces unnecessary slowness, like (generic C) libraries do.

For this reason I consider it preferable to C, at least in this very specific context, but your mileage may vary.

[helpcomputer0]

Making good progress on the prototype. Now have the world map, local maps, and dungeons explorable, and NPC's that offer healing.

I'm now thinking about the 1v1 combat system, I say "system" but it'll likely be quite simple. Here's some ideas, let me know what you think or if you have other ideas!

1. Dice rolls
- Each attack v defence stat determines number of dice rolls, then divide each total by 5 (to reduce randomness) and the total wins (hit or miss) for that round.
- Certain totals or individual dice rolls (e.g. 50% or more sixes) could guarantee a hit.
- This is very simple and might be quite boring/predictable, although it might be fun if its all shown on screen and not just "hit/miss".

2. Stats + Reaction
- When attacking or defending, the player has to press a key at a certain moment to deflect or make a successful hit.
- The speed/randomness of the on-screen swing-o-meter is determined by the difference in attack v defence stats, making it more difficult to achieve.
- This has the potential to get repetitive though.

3. Different tactics
- The player (a spearman) can choose different stances or attacks depending on the enemy, e.g. flanking against a cyclops.
- This is more of an addition to either of the above two systems. It could be a limited-use ability to use once in an encounter.

In each system I also expect there will also be the option to flee.

[ParadigmShifter]

I don't see how dividing by 5 reduces randomness :p Unless you round or something. Expected value of (X/5) is the same as (Expected value of X)/5.

EDIT: It will reduce the variance though - so I assume that is what you mean. However if this applied to health say, dividing by rolls by 5 is the same as multiplying the initial health by 5.

See wikipedia here:

https://en.wikipedia.org/wiki/Expected_value#Properties



Situations like that it's best to write a simulator which you give it attack and defence values (maybe hit points of defender and attacker as well) and then does a lot of iterations and reports the success/fail percentages at the end. Unless you want to do a statistical analysis

e.g. lots of people have done that for combat in Risk (boardgame) with various numbers of attackers vs. defenders and whether it's better to roll all 3 dice if you can (answer: it always is). But I can only find exact derivations rather than simulated ones, sorry!

You can write the simulator in your language of choice on a PC of course.

[R-Tape]

What about a combination of all 3 to avoid getting repetitive? Just for interest, you might want to check out the random key press fight in my Sixteen Skirmish..

Would it be mission creep or overstretch to include a simple adventure element with objects like keys and power boosting objects?

[helpcomputer0]

EDIT: It will reduce the variance though - so I assume that is what you mean. However if this applied to health say, dividing by rolls by 5 is the same as multiplying the initial health by 5.

Yes sorry, I meant variance. I haven't ran any tests yet but do intend to. This is more the ideas stage of design.

How to make a 1v1 combat system that is consistently fun and engaging?

What about a combination of all 3 to avoid getting repetitive? Just for interest, you might want to check out the random key press fight in my Sixteen Skirmish..

Would it be mission creep or overstretch to include a simple adventure element with objects like keys and power boosting objects?

Interesting, I'll check this out.

Hard to say if it's mission/feature creep, but I feel if I have to ask then it probably is

I intend to have an inventory but it will just be a list of things you can look at, not something you can manipulate or move around. e.g. selling or dropping items.