« previous next »
Pages: 1 ... 13 14 [15] 16 17 18   Go Down

Author Topic: OmniRPG - Coding  (Read 68821 times)

0 Members and 2 Guests are viewing this topic.

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #210 on: September 13, 2013, 01:36:56 pm »
I have the idea to use real time hp/pp rolling meters. THey are constantly increasing/decreasing if the target doesn't match the currrent P. THus, mortal damage could be avoided.
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #211 on: September 13, 2013, 01:45:23 pm »
I don't understand what you mean .__.
Logged

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #212 on: September 13, 2013, 01:47:09 pm »
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #213 on: September 13, 2013, 02:07:55 pm »
Oh so you mean real-time battle ? I don't think this type of battle engines fits a calculator game ...
« Last Edit: September 13, 2013, 02:08:09 pm by Matrefeytontias »
Logged

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #214 on: September 13, 2013, 02:53:21 pm »
Not real time. Turncbased, but life is constantly flowing.
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #215 on: September 13, 2013, 03:36:01 pm »
That would require the use of states flags I guess ? Which will have an effect during the whole battle ?
« Last Edit: September 13, 2013, 03:36:34 pm by Matrefeytontias »
Logged

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #216 on: September 13, 2013, 04:08:41 pm »
Mainly HP. PP is too low to have a real impact. If you take more damage than your life, your life meter will ocnstantly go down, but you still can heal yourself and avoid death iuntil the rolling meter rolls down to 0.

The main flag is to detect if someone fall down during an action, and change the turn flow, like channeling the heal to someone else, or invalidate the action, even after the action animation.
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #217 on: September 13, 2013, 04:18:40 pm »
I still find that a bit overkill ... A turn-based system à la FFTA seems good to me though.
Logged

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #218 on: September 13, 2013, 04:46:08 pm »
Meh. If you'll play Mother 3, you'll start to love it.
Logged

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #219 on: September 14, 2013, 11:06:05 am »
Quote from: Matrefeytontias on September 13, 2013, 01:12:12 pm
The thing is that then, all Axe graphical commands will be unefficient with that method, and since Axe provides a fair lot of them ... You or anyone else (certainly not me, I can't do that) will have to rewrite from scratch all graphical routines the whole game would use to work with vertical buffers. I think that's an enormous time-eating task x.x
I have line, circle, rectangle, pixel, sprite (clipped), tile, text, menu, LCD updating, grayscale, tilemap. Anything else?

EDIT: Also, the battle engine itself could use horizontal buffers, too, so that pure Axe could be used. I could also make a routine to convert a vertical buffer to a horizontal buffer or vice versa, and I could make an LCD update that works with both types of buffers.
« Last Edit: September 14, 2013, 11:07:36 am by Xeda112358 »
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #220 on: September 14, 2013, 11:11:03 am »
Using two sets of routines doing the same thing with differently aligned buffers is a huge waste of space. You'll have either to make your tilemapper work with horizontal buffers and use Axe's graphical routines, or replace all Axe's graphical routines by yours with an axiom and all the project will only use your axiom to work with vertical buffers.
Logged

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #221 on: September 14, 2013, 11:28:52 am »
Quote from: Matrefeytontias on September 14, 2013, 11:11:03 am
Using two sets of routines doing the same thing with differently aligned buffers is a huge waste of space. You'll have either to make your tilemapper work with horizontal buffers and use Axe's graphical routines, or replace all Axe's graphical routines by yours with an axiom and all the project will only use your axiom to work with vertical buffers.
So, does this mean that battles and stuff will happen on the tilemap? I thought they would occur on their own setting, allowing you to use horizontal buffers for battle and vertical buffers for displaying the tilemap.
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #222 on: September 14, 2013, 11:44:55 am »
It's the case, battles have their own terrain, but then since it permits the use of horizontal buffers, we'll use Axe's graphical commands and the tilemap will use yours, so the final program will include two versions of the same routine, one for each buffer alignment, which is a huge waste of space.
Thus, we need to choose one buffer alignment that will be used for the whole game, else we'll end up wasting hundreds of bytes writing routines to handle both alignments.
« Last Edit: September 14, 2013, 11:50:29 am by Matrefeytontias »
Logged

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #223 on: September 14, 2013, 11:58:54 am »
Ah, that is true. I have been optimising for speed, so currently, all of the 'duplicated' graphics routines take 979 bytes. It is doubling the graphics speed while keeping it running smoothly, too.
Logged

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #224 on: September 14, 2013, 12:13:31 pm »
So the best solution would be to build an axiom with a vertically-aligned version of Axe's graphical routines, and use this axiom instead of all Axe's functions. Also, direct plotSScreen access will need to be done differently.
Logged
Pages: 1 ... 13 14 [15] 16 17 18   Go Up
« previous next »