Author Topic: OmniRPG - Coding  (Read 59798 times)

0 Members and 1 Guest are viewing this topic.

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: OmniRPG - Coding
« Reply #240 on: September 15, 2013, 12:05:57 pm »
wow, that is looking awesome O.O
You are sure good with 3D stuff :)

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

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 #241 on: September 15, 2013, 01:20:56 pm »
What I planned for data format is something like classes. Here's what I mean :
  • First there's the character. It has HPs, MPs, stats, a pointer to an animation and a set of pointers to attacks/skills/capacities (dunno how it's called in English).
  • Then, there's the attack/skill/capacity. It has a name, a cost in MPs (0 if not required), a byte to tell the effect (hurt, heal, change stats ...), one or two bytes to tell how much damage it does/how much HPs or MPs it restores/by how much a stat increases or decrease, a byte for the precision of the attack, a byte to tell if the target gets a special state (paralized, burnt, frozen etc), and finally a pointer to a bunch of code which will be the animation you see when you use this attack.
  • At last, there's the animation. It has a number of frames, and as many sprites as the number of frames.
That's how I see the thing. What do you think of it ?
« Last Edit: September 15, 2013, 01:21:19 pm by Matrefeytontias »

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: OmniRPG - Coding
« Reply #242 on: September 15, 2013, 03:18:38 pm »
Sounds good to me !

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 #243 on: September 15, 2013, 04:41:39 pm »
It's almoqt like every rpgs I olayed and dissecated the engine! ;) It should rock!

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 #244 on: September 15, 2013, 04:45:22 pm »
We should arrange all datas like that then :) I'll make sure to make a small test with that data format in my engine.

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 #245 on: September 15, 2013, 06:14:01 pm »
The only problem I have is the last bullet. I feel like the attack animation should not be restricted to sprites. Instead, I think attacks should be subroutines so that we can make attacks that are customised for graphics and whatnot. For example, a thunderbolt animation might strike several places on the field before attacking a character. Using sprites for this would take a lot of memory, whereas using existing routines for lines and stuff would be a lot smaller.

EDIT: Otherwise, it looks good :) Maybe the last two bullets could get merged, then...

Offline tr1p1ea

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 647
  • Rating: +110/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #246 on: September 15, 2013, 06:19:35 pm »
Yeah i agree, you shouldnt limit yourself to sprites. Perhaps you can have a small data structure that can be parsed when drawing animations which can reference sprites, lines, ASCII (or a combination) for its frames.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."


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 #247 on: September 15, 2013, 07:13:25 pm »
The only problem I have is the last bullet. I feel like the attack animation should not be restricted to sprites. Instead, I think attacks should be subroutines so that we can make attacks that are customised for graphics and whatnot. For example, a thunderbolt animation might strike several places on the field before attacking a character. Using sprites for this would take a lot of memory, whereas using existing routines for lines and stuff would be a lot smaller.
It's exactly what I meant <_< for example, an attack data would look like this :
Data(Str1r,5,0,300r,255,0,LAttackr)

And you would write :

:"Thunderbolt"->Str1
:
:etc
:
:Lbl Attack
:animation code for Thunderbolt here

Offline willrandship

  • Omnimagus of the Multi-Base.
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2953
  • Rating: +98/-13
  • Insert sugar to begin programming subroutine.
    • View Profile
Re: OmniRPG - Coding
« Reply #248 on: September 15, 2013, 07:47:29 pm »
That's not what you said, though.
Quote from: Matrefeytontias
At last, there's the animation. It has a number of frames, and as many sprites as the number of frames.

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 #249 on: September 16, 2013, 12:36:47 am »
Here we're talking about attack animation, not regular animation. The double use of "animation" confused everybody I guess ;D

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: OmniRPG - Coding
« Reply #250 on: September 16, 2013, 05:51:25 am »
I don't see a huge issue with dropping support for 83+BE models. It allows us to increase the speed by 2.5x, and have significantly more space to work with, and it's a fairly small subset of the community.

Matrefeytontias, there is plenty of room for an extra 1800 bytes of graphical routines, especially if it makes it significantly faster.

True, but I always suggest games work for as many models as possible. Besides, if you are creating a great game people besides Omnimagicans will likely be playing it. :) The TI-83+ is still the cheapest available model TI-supports. Not to mention how many old used models are running around.

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: OmniRPG - Coding
« Reply #251 on: September 16, 2013, 10:56:24 am »
Personally i don't think grayscale is worth dropping 83+ support. Sometimes it looks nice, but in general i think B/W looks much better.

Offline pimathbrainiac

  • Occasionally I make projects
  • Members
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1731
  • Rating: +136/-23
  • dagaem
    • View Profile
Re: OmniRPG - Coding
« Reply #252 on: September 16, 2013, 01:57:36 pm »
I think that grayscale should be a yes, heck, even interrupt gray. Just not GRAYLIB interrupt gray, ya know, because ti-83 support.
I am Bach.

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: OmniRPG - Coding
« Reply #253 on: September 16, 2013, 02:00:51 pm »
Maybe it could be made optional. ;)

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 #254 on: September 16, 2013, 03:07:10 pm »
I think that for users that have 15MHz models, they should be able to toggle 15MHz/6MHz, and we could add in grayscale as an option to toggle. If we do 3-level grayscale, it will be a lot easier to make drawing routines that can be toggled between grayscale and b/w. However, I do think b/w is the best option and the most memory friendly. Scrolling a grayscale tilemap would be quite a bit slower (though I might save some speed by combining the LCD update and screen shifts).