Thanks for confirming me I got it (kind of) right! Appreciated!

- user

Yeah I had already started writing the message before you posted yours, so got ninja'ed once again.

No, I appreciated your answer, and I learned from it a better approach of something I understood.
And as I said, I had confirm from a more experienced and skilled person that I was on the right track!

So, Thanks!

- user

Done. Added also the backgroud, the game interface starts taking place.

Features working:
- 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 to be honest.

Any comment is welcome.

Cheers!

- user

I hope U'll sell it with a numbered release. You should add an insert name RPG function too. If you do make a release add my name to the buyers list!

I hope your hopes come true.

If so, you'll get copy #1.

Cheers!

- user

With bridges too.




Enjoy!

- user

Great awesome let me know! Thank you!

I will. You are welcome.

Update:



Added a bit of graphics, letters, numbers. This is about the starting zone of the game.

I have now to change a couple of routines:
- when you hit an edge you should just stop
- when you hit a sprite it depends: pick up (items), talk (people), fight (enemies), move to the next zone (arrows).

Once done this last task, I'm done with the exploration phase routines, and I build up a demo game of few zones to test it out better, this will be likely the next update, version alpha 020. Then I'll have only to code the combat system, the dialog system, and then fill up the game with interesting contents: zones design and textual dialogs will take some time. Then it will be done.

As always, comments are welcome.

- user

This is an awesome solution! Thanks so much!

Not only for sprites x,y,atr,pat, but also for backgrounds, sprites proprieties (enemy with collision start fight, item with collision pick up, switch with collision change the main sprite x, main sprite y, or both x and y, ...) which not always have the same number of bytes. Also it allows to have different number of sprites each zone.

FI make a table for sprites type.

Say a sprite has type 00 (fi: change zone and change the y coordinate of the main sprite when colliding keeping the x coordinate (as for an upper door), then load sprites for the new zone: just have 00 20 d3 (if 20 is the new y position, and d3 the next zone).

Knowing the zone is d3, just search for sprites of zone d3 on another table and load them. Ah ah!

Say a sprite has type ff (fi: start a combat): just have FF... and so on!

I mean knowing where each sprite type is located (from the collision routine, the x index tells you which sprite is that collided) when colliding you just jump there and execute!

So thanks! This helps a lot and makes things really easy!

I hope all this makes sense in English.

Cheers!

- user

Edit: misspelling

Not too much new:
- rewrote the code using lookup tables.
- added a bit of graphics.
- when hitting an edge now the sprite stops.

I'm now working on the game mode management (start screen, exploration, map overview, dialog, combat) and sprite collision events (trigger a switch, pick a thing, change zone, start dialog, trigger a combat, and such). I'm also done writing down the intro text for the game story itself.

I hope to publish a complete demo mini dungeon soon.

- user

Now the gamme handles the different types of collisions (zone switch, trigger fight, trigger dialog, pick up item, just stop against solid objects, and such...), and you can check out this now hitting an arrow (zone switch) or a solid object (all the others sprites on screen).

However, I have a doubt about backgrounds: see code.

All this of course works perfectly... well almost!

The background flickers for a fraction of second when changing zone (and the background with it), and I don't know if this is because of the emulator, or it would do the same on a real Nes: in this last case, is there any better solution to avoid that and make a smoother change of screen?

Any feedback or advice on the issue would be welcome!

Thanks for now. Cheers!

- user

I have this same issue, but haven't got around to figuring it out yet. I figured that I'd implement some sort of fade system; I think that there is an example in the CYOA tutorials, but haven't studied it too much. I'm curious to know if there is a way of smooth transitioning without a fade, though, as well.

Looking good so far!

Thanks!

Nice to know that other members follow the development and test it out a bit when having a couple of minutes of free time. It helps out beta testing and keeps high the will and motivation to finish it up as soon as possible and make it the best possible. Feedback is always welcome.

Really appreciated!


I think that _maybe_ a solution could be load the destination zone in the second background address then scroll from the first to the second. Just a guess, I never used Nes native scrolling feature so far (and I would avoid it if not needed).

I hope some of the more experienced Nes programmer can give an advice or opinion on this issue.

By the way, I think I also figured out how by myself a simple and nice routine to display text dialogs on screen when needed, using sprites instead of complicated backgrounds tiles.

So, whenever you are ready, let me have your opinion on the intro I sent you by PM, since the next step will be including the starting screen and the intro at the beginning of the game too.

Thanks for the help!

Right after I'll make a mini dungeon for testing purposes, and then face the combat phase next, the most interesting part of the code for me. So far, things are going smoother that I planned, which is a rare event when programming.

- user

Dialog system implemented and working correctly.



Go to the next "page" or exit from the last "page"(going in exploring mode) pushing the A button (in this demo there are two pages, and first and second page look the same; so you have to puch A button twice to exit the dialog mode).

Cheers!

- user

I added the whole intro dialog, let me know what you think about it, on both formatting and content.

Many thanks to SoleGooseProductions for checking it out and pointing out a couple of flaws (since I changed a couple of things at the end of it after his revision, if there are still few mistakes it's my bad).

Next, more interesting, update soon.

Someone asked me by PM the text routine, but I don't remember who, sorry.
Please ask again if you still interested.

Cheers!

- user

Ok, I got a second one.

Since I don't know how to attach a file to a PM, I'll just attach the code routine to this post for everybody interested, hoping that beside those asking me about it, maybe someone else could help me figuring out how to avoid the flickering when changing background (any comment or criticism is of course welcome!).

I use my own assembler, so the syntax is a bit different (f.i. ff means #$FF and asl $ meand asl on the accumulator) but it should be understandable. However, if interested but you have issues understanding it, just ask.

I just copy-pasted it from the whole game code, I hope it is not too messy to be understandable, I'm not a clean programmer, I know.

Enjoy!

Cheers,

- user

Hello all!

The game engine is complete, except for the combat routine and few other details.

I'm pretty satisfied about the short time needed to achieve this result, considering I started only two weeks ago to work on it.



Game Features you can test so far :

The game starts in Dialog mode.

Dialog Mode

A button: go to the next page, exit if last page and get back to the same place (x/y coordinates)

Exploration Mode

Start button: pause/unpause the game

Left/Right/Up/Down: move on the map

Hit a change-zone sprite: move to anoter specific zone to another specific x/y coordinate
(to test this hit an arrow or the harbor icon).

Hit a dialog-trigger sprite: start the correct dialog and save x/y coordinates
(to test this hit one of the last 3 sprites of the top row of 4 sprites in the first room).

Hit a solid sprite: stop motion
(to test this hit any other sprite).

Hit an Edge: stop motion
(to test this hit any edge).

Game Contents

You can check Khan, Zhor, Lyvn, and Shao intro screens.
Those should be the four protagonists of the game.
(you see them all aligned vertically in the combat mode, not in the exploration mode where you move only the group leader icon, in FF style).

As always, comments welcome and really appreciated.

Both posts and PMs are fine when giving me help and/or testing feedback; but please for requests of code routines or other quetions on the "how do you make this work?" style (which are welcome), use this thread instead of PMs. This makes my life easier, and allows more skilled and experienced people to enter the conversation to give better details.

Thank you!

Cheers!

- user

I took a look at your drawing routine, and I was having trouble understanding what was happening. The syntax is probably throwing me off as well. If it's fine, could you sort of explain what each routine is doing or describe the flow of the program? Thanks for sharing it by the way!

Disclaimer: I am not an expert NES programmer, I'm new to NES development, this is not a solution but it is actually a problem since the unresolved flickering issue, however it works, and you are asking about it. But you likely better ask better advice to more experienced and skilled NES programmers. I use this because of the lack of better alternatives.

Continue reading at your own risk!

Above !f000 Code there are only lookup tables and data stored.

Exiting the NMI (rti) you can have x = 00 or x = ff

If x = ff then go to SET then loop (exiting SET x = 00).

In set if mode = 02 then it's Dialog Mode (also named "text" or "talk").

In talk mode there is only a Sprite on screen and the background has a frame and two lines of text of 20 char each. Ldx 55 it's for the attribute (which in my last version can be also AA or FF). All the background has the same attribute which means only 3 BKG colors (+black transparency) are visible on a full screen of bkg.

 jsr <sprTalk

 ldx 40 jsr <Empty
        jsr <Header
 ldy 07 jsr <Frame
 ldx 00 jsr <TextLine
 ldy 01 jsr <Frame
 ldx 01 jsr <TextLine
 ldy 0d jsr <Frame
        jsr <Footer
 ldx 80 jsr <Empty
 ldx 55

I believe the frame part is quite understandable. And however, it's about the frame, not the text display routine.

TextLine maybe a bit less obvious.

>TextLine

 lda <text asl $

 cpx 00 bne <line+

 tax lda <Line-,x sta <lo
 inx lda <Line-,x sta <hi

 >findpage

 ldx <page beq <print
 > lda <lo clc adc 14 sta <lo
   lda <hi adc 00 sta <hi dex bne <

 >print

 jsr <FrameL+
 ldx 04 jsr <Empty

 ldy 00 > b1 <lo sta $2007
        iny cpy 14 bne <

 ldx 04 jsr <Empty
 jsr <FrameR-

 rts

 >line+

 tax lda <Line+,x sta <lo
 inx lda <Line+,x sta <hi

 jmp <findpage

First take the text number id to be shown, stored in "text" address.
FI for the intro it is 00.

Multiply x2 (addresses are 2 bytes!).

Check if it is the first or second line (- or +).

Save address: low byte, increment by one, and save high byte from the correct lookup table (- or +).

If the variable page (lower p) is 0 start from the beginning of the text, add 20 (14 HEX) bytes of text for each page already shown before (check out NN 16bit math).

Now, if this is confusing, you are right, I apologize for missing explaining this before:

 ldy 00 > b1 <lo sta $2007
        iny cpy 14 bne <

I didn't put indirect/indexed indexed/indirect addressing in my assembler, but since I would use LDA (foo),y and I know the opcode is b1, I just write b1 <foo .

Also in my syntax >foo means for the assembler: "store this address you are right now as foo", while <foo means "at address stored as foo".

Hence: b1 <foo == LDA (foo),y

Once you know the starting address, just copy 20 (14 HEX) bytes.

Exiting SET make sure x = 00 and you get back into the main loop.

In NMI, when in mode 02:

>KeyA cmp 08    bne <Exit
      cmp <key- beq <Exit            ; TALK mode (02): if key = 8 (A) and key+ != key-
      ldx <page inx stx <page
      lda <page ldx <text            ; switch to WALK Mode (01) if page = Page
      cmp <Page,x bne <text+         ; else go to the next page TEXT GO ONE PAGE FORWARD
      lda 01 sta <mode
      ldx 00 stx <page
      >text+
      ldx ff bne <Exit

If the KeyA (button A) is pressed, and it wasn't pressed the previous NMI, the variable page += 1.

If the number of pages (taken from the lookup table Page) equals the variable page all the text has been shown, set the mode to 01 (explore) and the page to 00. Else keep the mode as 02 and it will show the next page.

In both cases x = ff because you want to run SET again.

I hope this helps, if you need more details about something let me know.

By the way, in my syntax:

*23,key+

means that the address in zeropage $23 can be loaded and stored with <key+ .

*0200,sprite

means that the address $0200 can be loaded and stored with <sprite .

I like to have control over the ram (mostly zeropage) addresses also for debug purposes (check the HexDebug in FCEux), but I like to use text label as key+ rather than remember that $23 is for the last button pushed.

asl $

(without a hex numeric address) means asl on the accumulator.


Last notes

Hex values does not have #$. If you see 14, it is HEX 14 (hence 20 decimal).

Values with $ are addresses: $00 zeropage, $2001 direct, $0200,x indirect.

Ah... and you can write several instruction on the same line!


---

Cheers!

- user

It is just a silly demo of what the intro could be (English in dialogs still have to be checked).

Going on the harbor sprite

1) Krug shows up and talks not too kindly to you
2) After he attacks, so the fight starts (still have to do the routine)
3) Then finally you take the ship and get somewhere else.

Have fun!

Cheers!

- user

Fighting Mode in development.




Ok, now the more interesting part of the program started, the combat system.

After scrolling the whole intro you start in Falkern (capital of Kildon) and try to reach the harbor where Krug shows up and talks not too kindly to you.

Right after he's done trash talking to you, you enter in Fight Mode.

The graphics are there, but it is not entirely implemented yet.

I explain a bit the combat system here, so you will understand the meaning of the sprites on the screen shot.

You have your characters on one side, right of the screen, (the whole party is here in this demo, in game at this point you'll have only Khan), and the enemies on the other side, left of the screen (only Krug in this example).

The combat is turn based, with the sprite having the next action highlighted by an arrow (or another icon maybe, still have to decide on this).

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 will use 16 easy to perform combos: UU, DD, LL, RR, UD, DU, LR, RL, UA, DA, LA, RB, UB, DB, LB, RB; or probably only some of these, not even all of them.

And all the possible actions and relative combos will be visible on screen in the turn of that character: in the screen shot above you can se that to attack Krug you (Khan) need to enter the Left+Right combo.

If a character performs magic you'll see the icons of the available spells and relative combos on screen too.

Escaping (likely R+R), breathing/healing/recovering (likely U+U) and such actions also are performed by combos.

If you miss entering a valid combo within 4.2 seconds (I use 4.2 because is divisible by 3, the concept is "about 4 seconds") that character loses its turn. You have about 4 secs to make up your mind about what you wish to do. The enemies always use all the 4.2 seconds (or whatever that time will exactly be) to pick their action.

On top of that, those 4.2 seconds are divided in 3 equal phases: starting from "too early" (1.4 sec), followed by "perfect timing" (1.4 sec), ending with "too late" (1.4 secs).

The phase you are in in your turn will be highlighted on screen somehow. If you _finish_ your combo in the "perfect timing" phase your action is enhanced: f.i. a physical attack makes +50% damage (or something similar).

I believe this is going to be fun to play.
I'd like to hear other people feedback once implemented.



Game Features so far


Exploration Mode

Start button: pause/unpause the game

  Left  / Right /Up/  Down: move on the map

Hit a change-zone sprite: move to another specific zone to another specific x/y coordinate

Hit a dialog-trigger sprite: start the correct dialog

Hit a combat-trigger sprite: starts a fight.

Hit a solid sprite: stop motion

Hit an Edge: stop motion


Fight Mode

B button: exit and get back to Exploration Mode
(this has still to be finished to implement).


Dialog Mode

A button: go to the next page, exit if last page and get back to Exploration Mode


---


The next version should be more playable fighting-wise.

Thanks for now.


Cheers!


- user

The combat system, part II

Back on how the combat system works: physical attacks.

At first I thought to use a ratio between attacker power (P) and defender shielding (S), something like:
P / (P+S)
hence with P == S (0.500) you would have 50% chances to hit.

Obviously the number in the fraction needed to be tuned up for 8bit divisions, to get results more like 50 (with a maximum of 100), or, thinking binary: 128 (max. 256), 8 (max. 16), 4 (max. 8), and such, rather than a decimal value as 0.500.

I made a couple of routines for divisions, and I wasn't too enthusiastic about; I even asked advice for better routines and I was addressed to very interesting links with better solutions, but then I realized divisions were not needed.

Programming in assembly is wonderful, it makes you discover easy solutions to whatever.

There is a random number in a 256 range, from 00 to FF. Decimal 0 to 255.

Let's use decimal and let's call that pseudo-random number Event.

Halfway of 256 is 128. So let's say, as a base, with Event below 128 the attacker hits.
That's 50% chance: Event 0-127 hits, Event 128-255 doesn't.

Let call that 128 limit as Fail.

Let say that the attacker has a better weapon, a weapon +32.
This will be added to Fail. Fail is now 160.
Anything below hits; anything equal or above fails.
Chances to hit are increased.

Let say also that the defender has a very tough shielding, a shielding +60.
This will be subtracted from Fail. Fail is now 100.
Anything below hits; anything equal or above fails.
Chances to hit are decreased.

And so on...

Also, the margin of success will influence the damage.
With a Fail of 100 and an Event of 80, the base attack damage is increased by +20.
With a Fail of 160 and an Event of 80, the base attack damage is increased by +80.

And so on...

Well, I think this is how physical attacks will work.

Cheers!

Have you plugged your new combat method into something like Excel and compared it with your original plan?

It should be pretty easy to chart a SUCCESS/FAIL matrix to make sure the odds are more-or-less the same.