Swords and Runes

November 2015 Update



S&R NA Edition Thread:
 http://nintendoage.com/forum/mess...

Questions about the game itself (rather than its production) can be asked also in this thread.

---

LE AUCTION thread

 http://nintendoage.com/forum/mess...

 

April 21th 2015 Update

""" The time has finally come, Swords and Runes production has begun! """

 http://nintendoage.com/forum/mess...

In The Official Swords and Runes Production Thread you can check out the wonderful wooden box Beau made for the LE of the game. And read everything about the way this game will be released: Limited Edition, NintendoAge Edition, General Edition.

If you wish to test it out right now, you can download the demo from the first post of this thread. You will lack the guide of a manual, and my English is rather poor, so probably no matter I explain how it works in the first posts of this thread, the combat mode input system will be a bit difficult to master at first: whatever is not clear gameplay wise, don't be afraid to ask about it here, I will be glad to answer you. And I promise, once you master the input system, if you are a fan of timed turn based RPG combat, you will really like it.

This demo is very limited, there are only very few screens, in which there is only the first battle against your fanatic foe within Kildon's army, and another one against a couple of orcs. Once you recruit the whole party, and the true adventure really begins, the demo ends up (you are sent back to the initial screen). Of course, in the complete game, the whole Tyon Valley, all its dangers, mysteries, enigmas, and arcane and challenging places, awaits for you to explore it, new clues about this fantasy story will be revealed, and many bosses will need to be faced and defeated, alongside many other battles against fierce ogre-like and evil undead creatures, and few ester eggs secret battles which are there as well once your party reached the higher levels of power. Then you'll face the epilogue, with a story changing decision which needs to be taken, and only you, in pure RPG style, are the one entitled to chose your final actions.

As Beau stated in the production thread of this game linked above, this is a game I really care about: even if the developing time was kind of reasonably short for an homebrew, the design of this game it is the output of a well clear will I had since a long time: without the will to prove myself able to design a Sword and Runes RPG NES videogame, I would never face the learning of anything about assembly. If I do have some valuable game designer skills (which I honestly believe to have, else I would not design all this), this game buyers reception will tell. I hope you will appreciate it.

Thank You for supporting this project.

- Jack

To recover 50% of your energy lost the combo is button A + button A.
Recover energy too late it is too late, but too soon it is kind of worthless.

To (try to) escape (25% chance of success) the combo is button B + button B.

To cast the Fire! spell on all enemies perform the left + left combo: push left, release, push left again.

---
 

Combat System

In combat mode, you have your characters on one side, right of the screen, and the enemies on the other side, left of the screen. Your party will include up to four protagonists (which is the full party).
The enemy formation you face is composed by a number of enemies in range 1 to 8.

The combat is turn based, with the sprite having the action highlighted by an arrow (or another icon maybe, still have to decide on this).
Each sprite has an Hex id #: #00 to #03 are for your party; #04 to #0B for the enemies.
After the action, the id # shifts by 5, which means the turn order is not 00-01-02-03-04... but 00-05-0A-03-08... and returning to 0 after giving a turn to each id #s.
If an id # is not part of the combat (if not in your party, not in the enemy formation, or is already ko), the id # skips to the next in the sequence until finding an available id #: f.i. if the last to act was #04 and there are less than 5 enemies (there is not a #09), then it will jump to (9+5=14-12=2) #02, which is a player character id #.

Since the id # active will change only from this routine, the last id # acting in the previous fight is the first to act in the following one.
Since a character of your party should be the last to act in every fight, you will always have the initiative, but for the reasons explained above, the game will follow many different turn sequence scenarios: in most cases you'll see the arrow indicating the turn to act jump apparently randomly to every character on screen returning at the first one at the end of the cycle (even if it is not random at all, and if you are fast enough with math, you can easily predict the next one up).
 

Combos

In your turn to act, which is when it's a party characters turn, differently from other RPGs, you don't have a menu of options: you must enter a combo to perform any action. A combo is simply a combination of 2 inputs on the joypad: Up+Up is a combo; Down+A is another.

The game use 18 easy to perform combos: AA, UA, DA, LA, RA, BB, UB, DB, LB, RB, UU, DD, LL, RR, UD, DU, LR, RL.

All the possible actions and relative combos to trigger them are visible on screen.

Each time is the turn of a party character to act, you have 256 screen refresh, which is a bit more than 4 seconds in NTSC if my math is correct, to make up your mind about what you wish to do, and enter a valid combo.
The enemies will always use all their 256 screen refresh to pick their action.
If you miss entering a valid combo within these about 4 seconds, or you enter a combo not valid, or the combo you entered is relative to an action you can't trigger, a  Fail icon  (red diagonal bar) will appear on screen next to the active character, and that character loses its turn.

Physical Attack

To physically attack an enemy you perform the arrow + button combo next to its sprite: push the arrow, release it, and push the button (f.i. the combo left arrow + square is: left, release, button B).
In all combos icons, the circle is button A, and the square is button B.
Performing an attacking combo on an enemy not there or Ko will result in a fail and the loss of the turn.
 

Spell Casting

If a character can cast spells, you see the icons of the available spells and the icons of the relative combos on screen too.
All the spell combos are arrow+arrow, either twice the same (f.i. Up+Up) or the second opposite (f.i. Left+Right).
Performing a spell combo of an unavailable spell will result in a fail and the loss of the turn.
 

Energy Recover

To recover 50% of your lost energy the combo is button A + button A.
Recover energy too late it is too late, but too soon it is kind of worthless.
Performing the AA combo when at full Energy will result in a fail and the loss of the turn.
 

Escape

To (try to) escape (25% chance of success) the combo is button B + button B.
Performing the BB combo will result in a fail and the loss of the turn 75% of the times.
Note: it is possible to escape this way from any encounter, see below.

 

Stats and Math

Physical Attacks

Each character and enemy has a Power (P) stat, in range 0 to 255 (Hex 00 to FF).
Actually P is always above zero, and maximum 243 (Hex F3).

The enemies have each its own Power stat.
Zhor and Lyvn, the two arcane masters, have P = 128 (Hex 80), which means they have 50% of chances to hit.
Khan and Shao, the two weapon masters, have P = weapon used.
Their starting weapon has P = 172 (Hex AC) which gives a bit more than 67% of chances to hit.
In the final release of the game, they will pick up better weapons, with higher Power.
The best weapons in game have Power = 243 (Hex F3), which gives a bit less than 95% of chances to hit.

When attacking, the Power is compared to a rng# in range 0-255 (Hex 00 to FF):
- if that rng# is below the Power, the attack hits the target; otherwise,
- if that rng# is equal or above the Power, the attack misses the target.

When the attack hits, the Hit icon (red sword) appears next to the target.
When the attack misses, the Miss icon (red shield) appears next to the target.
 

Energy and Damage

Each character and enemy has an Energy (E) stat, E=mc2, which is always in range 0 to 255 (Hex 00 to FF); any character or enemy goes immediatly Ko if its energy reaches 00.

When a character or enemy is hit, its energy decreases.

The formula is: - ( 7 + ( rng# / 4 ) )

Since it uses the same rnd# it used to check if the attack hits, the higher is the Power, the higher is the range of the energy damage to the target: f.i. with P = 128 the maximum damage is 7 + ( 127 / 4 ) for a damage range from 7 to 38; while with P = 172 is 7 + ( 171 / 4 ) for a damage range from 7 to 49.

All characters and enemies have their own starting maximum Energy stat (Emax), which is restored after each combat.

When reaching Energy zero, the character or enemy goes Ko for the rest of the combat, and a Ko icon (red X) appears next to it.

You are not aware of enemies energy (except if already in Ko status); while your party characters energy status is displayed by an Energy icon (gray cross) next to each of them.
That icon fills up with red the more the character energy decreases.
 

Energy Recover

The Energy recover action (combo AA) formula is: ( E + 1 + Emax ) / 2
which means that after the action the resulting character E will be the average between the (previous) character E and its Emax.
The +1 in the formula is there to round up the result, so in the case E = Emax-1 the character will gain that last unit of missing Energy.

Enemies never recover energy.

Note that ( E + Emax ) / 2 works in 8bit math only because the Emax of the four characters is way below 128.
 

Escaping

The Escaping action, combo BB, is successful if a rng# in range 0-255 (Hex 00 to FF) is below 64 (Hex 40), which means in the 25% of the cases; if the rng# is equal or above 64 the escaping attempt fails.
 

Spell cost in Energy

Spell math is a bit more complex, but not too much.

Whenever casting a spell, the character spends some of its Energy; it is not possible to go Ko casting a spell: if the Energy is too low (the whole gray cross icon is filled with red), in that case the attempt fails and the character loses its turn.
 

Spells and Immunity

Each enemy has an Immunity stat. This is a byte, each bit of which sets the immunity to a specific spell.

All elemental spells (fire, ice, bolt, water, wind) hit all the enemies for a damage = 7 + ( rnd# / 8 ), which is 7 plus 1/8 of a number between 0 and 255 (damage range: 7 to 38); this unless the enemy is immune to that specific element, in which case it takes no damage.

Doom instantly reduce to 1/2 the current energy of all undead enemies on screen, which means shifts right (E = LSR of E) the energy of all the enemies not immune to doom.
Note that all the enemies, except for the undead, are immune to doom.

Death in 1/8 (12.5%) of the cases instantly gives Ko status (E=00) to all enemies on screen, unless immune to death. In the remaining 7/8 of the cases (87,5%) it has no effect.

Invisibility gives a 87.5% (7/8) chance of escaping, unless at least one of the enemies (no matter if already Ko) is immune to it, in which case it always fails, as it fails in the remaining 12.5% (1/8) of cases.
Note: "normal" escaping with the BB can always succed, also if it has only 25% of chances; while this spell has higher chances of success but some encounters you can't escape from this way.

 

Random Numbers

To generate random numbers this game uses the same method used in 1007 Bolts , already discussed in this forum.

The random numbers are generated by the gamer interaction in a way that tries to simulate somehow the roll of a die. All future outputs are (reasonably speaking) unpredictable from the current one.

First of all, there are 16 parallel pseudo-rngs, numbered from 00 to 0e (0 to 15).

Each of these pseudo-rngs (if executed 256 times) generates a sequence of outputs going trough all the values from 0 to 255, in a shuffled order; then, if executed once again it restarts again the same sequence from the beginning. Each output is the seed for the next output.

Each of these pseudo-rngs uses a different constant in its code routine, hence generates a different sequence of outputs; but all of them will generate a specific shuffled sequence of the 256 numbers in the range 0 to 255.

There is an index value, which has a value in range 00 to 0f (0 to 15); this value increases by 3 following the path:

hex: 00 03 06 09 0c 0f 02 05 08 0b 0e 01 04 07 0a 0d -> 00
dec:  0  3  6  9 12 15  2  5  8 11 14  1  4  7 10 13 ->  0

in each NMI (60 times per second in NTSC), no matter what the player does, or abstains to do.

In addition to this:

• In every NMI without inputs (no buttons are pushed), no matter in which game mode, all the pseudo-rngs are executed once, shifting so to their next output (hence seed); while,
• In every NMI with inputs (any button is pushed), no matter which button is pushed, the current game mode, or the need for a random number or not, the current output value of a single psuedo-rng (which one is determined by the value stored in the index address) is saved as the new random number, and the relative generator is executed once, shifting to its next output (hence seed) and breaking the synchrony between the generators (since all the others pseudo-rngs won't shift in this NMI).

In each NMI, no matter what the player does, or abstains to do, it will influence the next output.

Each output is always (reasonably) equally likely.

And it is highly unlikely to replicate the same sequence of outputs, or to be able to manipulate this method timing up actions to get specific outputs: triggering an action a single NMI later would generate a completely different output, and will drastically change all the following outputs too.


---

I hope all this makes sense in English!

---


Original Post

Hi all.

So after my tiny 1007 bolts, I'm starting today a more ambitious challenge: a brand new NES RPG.

Yeah, I know, pretty (uhm... extremely?) tough challenge for a non-programmer at its second experiment programming in assembly for the 6502 processor. However, I'm confident that if I can found enough free time to dedicate to it, keeping it simple and minimal*, it could maybe even be ready in time to participate (just for the sake of it, of course) to the next, 2015, NES homebrew contest.

*(to make it interesting, I'll rely on making it stable, focusing on the the game story and the game mechanics rather than overcomplicated graphics, sounds, effects, animations, sprite collision checks, and such "pro" things).

I have a generic idea of how to do everything, since I've been programming similar things for other systems, but any extra advice, tutorial, lesson, how-to-do-it-on-the-NES, on what I'm trying to achieve would be very useful and extremely welcome!

Progressing on the project, I'll point out what tasks I'm facing, and how, confidently hoping some of you more experienced and talented than I am will stop by to give feedback and precious opinions about what I'm doing.

Thank you all for your attention.

- user

Best of luck to ya! A fresh RPG on the NES would be great! If you need testers let me know, I would enjoy helping you with that.

Cool stuff! Challenges can be great motivators What is the first task on your list, or where is the project at currently?

Task 1: there is a map, which is big as much as 256 screens, that means 16x hor and 16x vert times the screen. No background tiles for now. I have a variable that memorizes the main sprite position on this virtual map, and keeps track of that position when moving the main sprite.

Task 2: of course, an item inventory is needed in a Rpg.

Every suggestion, idea, comment, or whatever else about these tasks is welcome.

Cheers!

- user

I asked a couple of friends to take pictures of them dressed medieval for the "boxart" (even if I won't bet it will actually ever be in in box). As soon as I have that, I'll maybe make a web page or something similar about this little silly project.

I was thinking, since you seem very confident writing in English, would you like to double check the game texts for me, when they will be ready and you will have a little bit of time to dedicate to that?

By the way, task 3: find a way to display a message n screen PRG style.

Thanks also to Oishii San for the feedback! A tester would be great in a while!

- user

I'd be more than happy to! Always happy to lend a hand. What is your native language?

"It's a secret to everybody."
Just kidding a bit.

Thanks! Appreciated!
I'll PM you in the next weeks about it. I'm comfortable reading English and translating from it (it's even part of my work), and I'm also reasonably confident writing it informally; but if I publish something, or translate to it, I prefer my English to be double checked and corrected where needed by someone more proficient than I am.

Thanks for now.

Cheers!

- user

Hi all,

Ok, for now I've done a bit of provisional icons: spartan warrior (in 3 colors), druid(ess), sorcerer, ogre, undead, avenger.
Can you say who is who? Tell me what do you think about them: are they kind of cute 8x8px icons, or just pathetic?

Any comment is welcome.

Cheers!

- user

edit: misspelling

Also, if someone can test it on a real NES, and tell me about the way the colors look, that would be great! Thanks!

Cheers!

- user

I don't see a lot of distinction between the sorceror and the druid.

I'm assuming the "avenger" is supposed to look like a ninja?

You are of course correct on both!

Yeah, pretty hard to make hood-style hats look different between them (there is only 1px different on the "forehead").
I thought druid green, sorcerer brown (as Radagast ah ah).
I'll see if I can differentiate them a bit more.

Thanks for the feedback! Appreciated.

- user

Edit: misspelling.

I guess the bigger question is in terms of game mechanics, what is constraining you to these 8x8 pixel sprites?

Awesome question. This challenge project is all about this!

Short answer: I have a pretty good idea about the time it takes to a "non programmer one man band" to finish a project such a rpg: so I think better minimal and working, than sophisticated and unfinished. I'm aiming to cut any unneeded feature (as for "building" 16x16px sprites) to make it work, then it is always possible, if the game mechanics are good, to make a better polished 2.0 version, if needed.

Long answer: for what said above, I'll skip this.

- user

OK, so this is basically a matter of going super-minimalist with 8x8 icons/tokens rather than 16x16 animated sprites?

What "style" of RPG is this going to be?

1. Yes.

2. Not a clone, that's the goal. However, is will have of course some features in common with FF, Zelda, Gauntlet, and such games. I have a brand new idea for the combat mechanics, if you wish to join few other users for beta testing when I'll be ready, let me know, you are really welcome to!

Cheers!

- user

You listed 3 games from 3 different genres

So is it an action-RPG?  Turn-based?


But yes, I would love to put my PowerPak to use beta testing the game.

In between. I told you it was something new. The generic idea is: since you manage more than one character, the combat is turn based, as in a rpg Final Fantasy style; but the timing of your actions (triggered by button combos) in combat is important over your character level and equipment, as in an adventure game Zelda style; and the exploration is kind of like Gauntlet style, with simple backgrounds and enemies visible (no sudden random encounters).

However, I still have to code all this in assembly (already done in basic once in the past) before the testing phase.


Thanks, this is welcome!

As already said, the goal is to participate (just for the sake of it) to the next homebrew contest.
I'll PM you as soon as I have something more interesting to test out combat wise.
In the while, you can check out this thread in the following days for more marginal improvements.
I'll cite the most involved beta-testers (interested to be cited) in the game credits somehow.

Thanks again. If you have a couple of minutes, please check out the colors combos on a real Nes and tell me what the shading looks like.

- user

I probably won't get a chance until Saturday, but I will let you know how it looks.
(also keep in mind all TV's are going to look a little different on the colors)

Since I've been asked about this in a PM, here a couple of notes about the color palette.

FCEUX -> Open Nes file -> Debug -> PPU viewer. You can see the palette I'm using.

So the items can be: gray/darkgray, yellow/brown, green/darkgreen, or blue/darkblue.
Plus each one of the four options above can have red highlights and black transparency.
Being the red always the last color, it makes it possible to change color option (in the four above) keeping the red highlight. And always keeping the same palette.

And here a note about scrolling and overworld map, being discussed in PMs too: I eventually decide for no scrolling at all, in Zelda style (or if you are familiar with Game Maker rooms).

If you exit west in screen one, you enter east in screen 0.
If you exit east in screen one, you enter west in screen 2.

This for a total of 255 numbered screens linking each to up to four other screens. This with an auxiliary view showing the whole (or only the known part of it maybe with the unknown part black?) overworld map in an "artistic" way on an extra static screen you can call pushing a button (as in FF), likely "select".

The positive this way it is that the whole map doesn't have to be rectangular: imagine being in Dallas, going north you arrive south of Houston. The whole map view shows dots about where the 255 screens are. Each of the 255 screens can have dungeons, encounters, locations, and other such rpg things.

If you wish to, please, let me know what you think about these two choices I've made and explained above.

I'm planning on publishing something a bit more interactive than the Alpha 001 version in few hours from now. Stay tuned.

Cheers!

- user

Hi all,

I added a bit of graphics, a routine to pause/unpause game with start, and input check so the main character moves four directions now. I wish to do a bit more stuff tonight, but I was busy somewhere else. The next update will be more interesting. Once figured out a good collision routine, I'll build up the combat mode, and make it kind of interesting to test.

All comments and testings are welcome, thanks for now.

Cheers!

- user

Nice, I'm diggin' the sprite-work so far.

Your opinion?


The first part, the collision routine, was done in a couple of lines of code, adapted from the 1007 bolts code.

Now I still have to decide if the collision happens:
- when overlapping the other sprite; or
- when touching the other sprite.

Next update should be the more interesting combat system.

As always, any comment is welcome.

Thanks.

Cheers for now.

- user

Hi all,

I have a task to do right now and Indexed Indirect and Indirect Indexed addressing modes are not really what I'm looking for.

Here some sprite data for 16 sprites (edit: removed now since useless), in each "zone", stored in ROM from address e100. Depending the zone you are entering specific 16 sprites are copied into RAM memory from $0200. Then transferred into the PPU in NMI. I hope this makes sense.

[I should be able to store up over 250 zones with 16 sprites each before hitting ROM address ffff (the end of my rom) if my math is correct; however, whatever the number is, that's not the point now, I can change the size of the ROM or the starting point, the only important thing is that the zone entered is specified by a single value from 00 to ff].

To simplify it a bit, my goal is to have a routine that loads the correct sprites when entering a specific zone. FI: you enter the zone 03, I need a routine that loads from address e100+03*40(hex),x in a loop where x goes from 00 to 3f, and copy each data byte in RAM starting from address 0200.

Like:
LDA address, x
STA $0200, x
INX
...

If only one room was there:
LDA $e100, x
STA $0200, x
INX
...

If only few zones were there, likely something like this would work:

LDA #$00
LDX zone
BEQ next

loop:
CLC
ADC #$40
DEX
BNE loop

next:
TAX
ADC #$40
STA temp

copy:
LDA $e100, x
STA $0200, x
INX
CPX temp
BNE copy

...

But with many zones, and with the x offset that can't be over FF, how can you do this without complicating too much the loops with a bunch more of math operations slowing down everything?
Thanks in advance to anyone has an answer!

- user

Solved. Pseudocode:
lo at $27(zeropage)
hi at $28 (zeropage)
zn at $29 (zeropage) [zone you enter]
- starting from hi=e1 lo = 00 do 16bit math to add 40 (hex) * zn (with carry from lo to hi)
- store in lo and hi the correct final values (f.i. z=3 then lo = c0 and hi = e1)
- set y to 0
- then loop transfers from y = 0 to y = 40 (excluded)

lda (lo),y
sta $0200,y
iny
...

Now the game:
- starts and goes pause with start;
- moves 4 directions;
- checks collisions relocating the main sprite in center screen;
- loads the next zone when hitting the edge, relocating accordingly the main sprite (fi east if exiting west)
There are 12 zones atm, pretty similar, but I know it switches correctly..
I've done a bit more of demo graphics, started some for the backgrounds too.
Next I have to make better positioning of the zones outer edges.

Then either I start building some zones, with background and sprites correctly positioned pushing the combat mechanics few days from now, or I start the combat mechanics mode triggering it when a collision is detected.

Attached Alpha 010. As always, comments are welcome.

Cheers!

- user

Indirect-indexed addressing is the answer. It's always the answer when you want to access data whose 1) location can change or 2) there's more than 256 bytes of.

If you dont want to do the multiplication to calculate the base address for the table (i.e. the $E100+zone*$40 part), you can do it with a lookup table:

zoneAddrLo: .byte <$E100, <$E140, <$E180, ... etc
zoneAddrHi: .byte >$E100, >$E140, >$E180, ... etc

Then you fetch the address based on zone number ("ptr" is a zero page memory address here):

ldx zone
lda zoneAddrLo, x
sta ptr+0
lda zoneAddrHi, x
sta ptr+1

And now you can use indirect-indexed to fetch the data for the zone:

lda (ptr), y
sta $200, y
iny
...

---

Another solution:

In this case it wouldn't be out of question to do the multiplication without using a lookup table, as well, since the multiplier is $40, which is a power of two. You could put the zone number in a 16-bit variable and shift it left 6 times (e.g. 5*$40 = 5<<6 = 320). Or, you could put the zone number in the hibyte of the 16-bit variable and shift it right 2 times (e.g. 5*$40 = (5<<8)>>2 = 320).