Author Topic: OmniRPG - Coding (Read 67175 times)

Xeda112358 · « **Reply #195 on:** February 20, 2013, 08:19:35 am »

For my Samocal RPG it wasn't difficult to make a general AI. In this case, we will need a variable to keep track of which player is attacking and from that we can figure out which players it has to choose from for attacking. If I can find the time, I won't mind trying to work out a decent AI (and I know how to make it learn throughout the battle, too ^_^).

Matrefeytontias · « **Reply #196 on:** February 20, 2013, 08:29:48 am »

Also, I planned on coding the whole battle engine as a sole function. But I'll need your opinion on which prototype can be the best. For now I have this :

BeginBattle(playersSequence, enemiesSequence, rewardSequence, canRunAway) playersSequence : a pointer on a data giving info on who's in the battle, and structured as follows : number of players involved in the battle (1 to 4, one byte), then ID of each player (as many bytes as the first byte of the sequence). Basically, the ID would be used to assign the right stats and sprites to a character. enemiesSequence : exactly the same as above, but for enemies (involving different stats, sprites etc). rewardSequence : a pointer to a data giving info about what you obtain after winning the battle, and structured as follows : number of items gained (up to 255, one byte obviously, excluding money, which in my opinion should be given after every battle you win), the amount of money obtained (two bytes, I do think that we should use a 3- or 4-bytes number for the player's money), then each item's ID (as many bytes as the first byte of the sequence). canRunAway : a simple flag set to allow the flee and reset to forbid it.

What do you think of it ?

Streetwalrus · « **Reply #197 on:** February 20, 2013, 02:57:19 pm »

That's exactly what should be done, IMO. Also, a neat feature would be zone specific effects in the battle (eg weather, local elements, disabling lightning summoning attacks in caves, etc.).

willrandship · « **Reply #198 on:** February 20, 2013, 04:24:18 pm »

A specific boss might deserve its own animation, for example.

Xeda112358 · « **Reply #199 on:** September 10, 2013, 08:22:38 pm »

I am not sure who all is in on the coding, except Matrefeytontias and I, but it might be a good idea for me to share what I am doing. For my tilemapper and all of the associated graphics including menus, text, rectangles, and most of the other drawing functions I have, they use a vertically aligned buffer instead of horizontally aligned. This means that instead of the bytes being:
0 1 2 3 4 ... 12 13 14 15 ... 24 25 26 27 ...
I have it as:
0 64 128... 1 65 129... 2 66 130... 3 67 131... .........
I am using this method because it is working a lot faster and the code is smaller (it's also easier, actually). Axe uses the former method, and I know there will be a bunch of Axe coding for this project. Because of this, I think the tilemap stuff should be vertically aligned and everything else can be horizontally aligned to make Axe coding easier. As an alternative, I can create graphics routines callable from the Axe programs that work with vertically aligned buffers.

Since I will probably be the one delegated to tilemap stuff, which functions should I create? I was thinking that the following commands might work:

LoadMap(basename,mapID). basename would be something like OMAP and the ID would be two bytes identifying the map number. This command would load all of the appropriate data and pointers required to actually draw the map.

MoveLeft() This would scroll the map right if the player is able to move to the tile to the left. Return the value of the tile currently being occupied, the tile.
MoveRight()
MoveUp()
MoveDown()
TileSel() returns the tile value that the player is facing. For example, if the player presses Enter or 2nd, this might be called to see if the tile is anything useful.
AddEvent()
DelEvent()

These would be routines that the Axe code would make a call to to update tilemap stuff. The tilemap I have is running from an interrupt, by the way. I found it to be very useful for updating animations at a fairly constant rate.

Matrefeytontias · « **Reply #200 on:** September 11, 2013, 12:43:33 am »

I think that each of these functions are required

btw you should make them an axiom, because then Axe will can interface with it. If we happen to have too much subroutines for a regular ASM program, we can use my PageSwap axiom to load functions from an app.

Xeda112358 · « **Reply #201 on:** September 13, 2013, 08:18:55 am »

Okay, I have a few other things to discuss about some code that I have from previous projects:

I have one compression/decompression algorithm that I may look into using for text and tilemaps. I am also working on a few more that look promising, and I will probably make routines for RLE and modified RLE encoding.
My tilemap routine allows for up to 128 unique animated tiles on the tilemap, via a pallet. There can be 256 unique tiles to choose from, though. I have 42 in all, currently, most of them from previous projects and they will be removed later.
I have a bunch of text display routines and menu routines that can use 'token strings' for words that are common in the game. For example, in Pokémon Amber, the word for 'pokéball' is 1 byte. It also uses a fixed 4x6 font (so that each char takes 3 bytes of data, making a total of 768 bytes for the whole font). DrDnar's Monochrome Font Editor can be used to create a new font for this project. I have been reusing this font for years

Attached is a very undocumented app so far.

Matrefeytontias · « **Reply #202 on:** September 13, 2013, 09:36:21 am »

We can't do anything with that, all ASM code must be Axe-friendly.

Eiyeron · « **Reply #203 on:** September 13, 2013, 12:13:52 pm »

FOr the Battle engine, I making one. I'll sure need help, but when done, you'll have a powerful and beautiful engine!

Xeda112358 · « **Reply #204 on:** September 13, 2013, 12:22:25 pm »

Quote from: Matrefeytontias on September 13, 2013, 09:36:21 am

We can't do anything with that, all ASM code must be Axe-friendly.

I know, but I thought I would post it to see if there were any routines that are desired (the jump table is currently empty). I can also write simple Axe routines such as :

Code: [Select]

Lbl IRCTI
.x,y,w,h
Lr1Asm(5623235E23234E232346C38640)

4086 is probably not going to be the actual address, but routines like this should be fairly easy to create. As well, the text routines can be modified to use the OS penRow and penCol to make text coordinates easier to manipulate. Otherwise, string displaying would be:

Code: [Select]

Str1Asm(CD8640)

(again, the adress will likely be changed).

Matrefeytontias · « **Reply #205 on:** September 13, 2013, 12:29:16 pm »

Quote from: Eiyeron on September 13, 2013, 12:13:52 pm

FOr the Battle engine, I making one. I'll sure need help, but when done, you'll have a powerful and beautiful engine!

I'm already working on it actually. What we can do is do our battle engine, then show it to other team members for them to choose one. What do you think of that ?

@Xeda112358 : for now I don't really see why we would need any of the rect routines since Axe already has everything we need. A specific text routine to display text in a dialog box with a character pic next to it would be nice IMO

Xeda112358 · « **Reply #206 on:** September 13, 2013, 12:48:39 pm »

Oh, the routines for all of the graphics in the app use a vertically aligned buffer, whereas Axe uses horizontally aligned. I do this for speed and memory, but this means that in order to draw text on the screen when the map is in view, or do any drawing on screen, you won't be able to use the Axe routines. This won't be the case for the battle engine stuff, though, unless you all would like to use vertically aligned buffers for battle animations and whatnot.

See this post above for a description of what vertically aligned buffers are.

@Matrefeytontias and other assembly programmers: Using this method, drawing a tile is as easy as:

Code: [Select]

drawtile:
     ld de,gbuf
     ld hl,tile
     ld bc,8
     ldir

As well, LCD updates are pretty small and gives you more time for things like grayscale.

Matrefeytontias · « **Reply #207 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

Eiyeron · « **Reply #208 on:** September 13, 2013, 01:16:37 pm »

My engine won't be finished before a long moment because it(s quite different from a typical turn based RPG battle, and needs to cope with the overworld thing (for in world hp loss for instance). Which kind of engine do you needs? Action? Turn based?

Matrefeytontias · « **Reply #209 on:** September 13, 2013, 01:21:56 pm »

IIRC we went for turn-based, thus simplifying AI coding and allowing for nice attacks animations

I planned to keep the idea I explained in this post, is it still okay ?

Author Topic: OmniRPG - Coding (Read 67175 times)

Xeda112358

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding

Streetwalrus

Re: OmniRPG - Coding

willrandship

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding

Eiyeron

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding

Eiyeron

Re: OmniRPG - Coding

Matrefeytontias

Re: OmniRPG - Coding