Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ZXodus][Engine
#1
[Image: 971988_518944744820483_1531283958_n.png]

The ZXodus][Engine is a game engine for 2D and 3D cRPGs (computer Role Playing Games) for the ZX Spectrum +2B. (It will run imperfectly on other 128s) I'm pleased to announce that the ZXodus][Engine will use ZX Basic for the game logic. All of the tricky stuff will be handled by the engine. It has the following features:

9x9 multi-color (8x1 attrıbute) viewport
16 column text window (6x8 font)
256 multi-color (16x16 pixel) 2D tiles
256 multi-color (16x16 pixel) 3D dungeon tiles
128x128 tile world map
36x36 tile mini-map viewer
16 town maps of 32x32 tiles each
16 NPCs per town
11 character classes
two spell systems
melee and ranged combat
Ultıma 4 style dialog system
AY music player
BEEPer sound effects

Happy to answer any questions.
Reply
#2
Exciting stuff.

Can't help but love the logo for starters Smile

Time for a bard's tale remake, anyone?
Reply
#3
Glad you like the logo. If you wanted to do a Bard's Tale type game you'd need to do an outdoor 3D tile set. However, the indoor one provided would probably be a reasonable starting point.
Reply
#4
This is awesome. I only own a Speccy 48K, +2 (grey) and +2A.
What's the difference with +2B? Why the incompatibility?
Reply
#5
boriel Wrote:This is awesome. I only own a Speccy 48K, +2 (grey) and +2A.
What's the difference with +2B? Why the incompatibility?

In all probability your +2A is actually a +2B. The real +2A is pretty rare. The +2A has the same motherboard as the +3 but partially depopulated. The +2B has the cut-down motherboard. The +2B fixes the corrupt sound on the +3/+2A. So for people with a +3/+2A they will need to do the sound fix or the sound will be distorted. For people with the toast rack or grey +2 (ULA 128s) they will need to replace the HAL with a GAL from Velesoft that changes the contention to match the +3/+2A/+2B (ASIC 128s). The ULA 128s contend every I/O access and different RAM pages. This doesn't always leave enough t-states per frame to keep the engine going with a large number of sprites, and the ZXodus][Engine pushes the machine to its limits.
Reply
#6
cheveron Wrote:16 NPCs per town
11 character classes
two spell systems
melee and ranged combat
Can you please explain how this will work?
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#7
LCD Wrote:
cheveron Wrote:16 NPCs per town
11 character classes
two spell systems
melee and ranged combat
Can you please explain how this will work?
Believe it or not, I was planning something like this with ZX Basic (not an engine, but a game). This is why I created ZXBasic in first place! Big Grin
Reply
#8
16 NPCs per town - each town has a table of NPC start positions. Each NPC has a dialog tree. You can script other behaviour such as giving and taking objects. Shops are handled separately.

11 character classes - mage, fighter, thief, cleric and all possible multi-class combos

two spell systems - magic and prayer. point based. points derived from skill stats.

melee and ranged combat - top down combat with ranged and magic attacks able to hit distant targets.
Reply
#9
boriel Wrote:Believe it or not, I was planning something like this with ZX Basic (not an engine, but a game). This is why I created ZXBasic in first place! Big Grin
If you let me know the requirements of your planned game I'll make sure ZXodus supports them. The engine is the second hardest thing after writing a decent plot so it would be good to get more than one game out of it.
Reply
#10
cheveron Wrote:16 NPCs per town - each town has a table of NPC start positions. Each NPC has a dialog tree. You can script other behaviour such as giving and taking objects. Shops are handled separately.

11 character classes - mage, fighter, thief, cleric and all possible multi-class combos

two spell systems - magic and prayer. point based. points derived from skill stats.

melee and ranged combat - top down combat with ranged and magic attacks able to hit distant targets.
Sounds good. Can it be also used with disabled Multicolor? We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left... But if 128K is supported, our next RPG will use ZXodus Engine.
@boriel: Really you are into RPG games too? I hope, you can finish your game.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#11
LCD Wrote:Sounds good. Can it be also used with disabled Multicolor?
The whole engine is built around the multi-color display. If you don't want multicolor then you're probably better off using a different engine.
Quote:We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left...
What kind of text compression are you using?
Quote:But if 128K is supported, our next RPG will use ZXodus Engine.
All the game data is stored in banked RAM and the ZXodus][Engine fetches it on demand, so that leaves most of bank 2 available for the game logic.
Reply
#12
cheveron Wrote:
LCD Wrote:Sounds good. Can it be also used with disabled Multicolor?
The whole engine is built around the multi-color display. If you don't want multicolor then you're probably better off using a different engine.
My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal. Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.
cheveron Wrote:
Quote:We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left...
What kind of text compression are you using?
There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.
cheveron Wrote:
Quote:But if 128K is supported, our next RPG will use ZXodus Engine.
All the game data is stored in banked RAM and the ZXodus][Engine fetches it on demand, so that leaves most of bank 2 available for the game logic.
This sounds good. When will it be released? Is there documentation of all features online?
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#13
LCD Wrote:My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal.
It's 64 bytes per tile. That's only 28 bytes more per tile. And tiles are stored in banked RAM. Plus if you're only using 2D or only using 3D you could leave one tile set out completely for an extra 16K.

Quote:Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.

The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?

Quote:There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.

I'd suggest using digraph compression (which is what the ZXodus][Engine uses). There's no depacking as such, just a bit trigger for printing letter pairs, and the compression is often better than dictionary word compression. http://foro.speccy.org/viewtopic.php?f=6...aph#p33001

Quote:This sounds good. When will it be released? Is there documentation of all features online?
Well there's the sticky part. First: it's not going to be ready for some time. There's a hell of a lot of work to do on it, I'm the only one working on it, and my priority for this year is to finish SE Basic 4.1. Second: I'm probably not going to finalize it until after the game that I want to release using it is written. That's going take even longer. Third: I'm not giving it a public release. I've put all my previous efforts out there for anyone to use and in return I've been publicly vilified by people who have benefitted from my work. Therefore I am keeping the ZXodus][Engine closed source, and I will decide who gets to use it. That said I'm happy to license it to yourself and Boriel. Licensees will get full techincal support. The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.
Reply
#14
cheveron Wrote:
LCD Wrote:My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal.
It's 64 bytes per tile. That's only 28 bytes more per tile. And tiles are stored in banked RAM. Plus if you're only using 2D or only using 3D you could leave one tile set out completely for an extra 16K.
Okay, that sounds not so bad after all
cheveron Wrote:
Quote:Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.

The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?
So it cannot be modified for another machine just by patching the code of the engine a little with few POKEs?
cheveron Wrote:
Quote:There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.

I'd suggest using digraph compression (which is what the ZXodus][Engine uses). There's no depacking as such, just a bit trigger for printing letter pairs, and the compression is often better than dictionary word compression. http://foro.speccy.org/viewtopic.php?f=6...aph#p33001
From the text it sounds exactly the same, but optimised for spanish texts. My routine I used in the 80's had also no depacking, just triggering.
cheveron Wrote:
Quote:This sounds good. When will it be released? Is there documentation of all features online?
Well there's the sticky part. First: it's not going to be ready for some time. There's a hell of a lot of work to do on it, I'm the only one working on it, and my priority for this year is to finish SE Basic 4.1. Second: I'm probably not going to finalize it until after the game that I want to release using it is written. That's going take even longer. Third: I'm not giving it a public release. I've put all my previous efforts out there for anyone to use and in return I've been publicly vilified by people who have benefitted from my work. Therefore I am keeping the ZXodus][Engine closed source, and I will decide who gets to use it. That said I'm happy to license it to yourself and Boriel. Licensees will get full techincal support. The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.
Excellent. How much % of the profit do you want for licensing it for comercial releases? Or is the licensing based on something other?
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#15
LCD Wrote:
cheveron Wrote:The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?
So it cannot be modified for another machine just by patching the code of the engine a little with few POKEs?
It all comes down to the contention model. The Pentagon has no contention at all and so it needs completely different display code. The ULA 128s contend all the I/O access and so they will occasionally run out of t-states per-frame, and they also have different banks of 128 RAM contended. Most of the time it won't be that noticeable and doing a ULA 128 specific build wouldn't address the I/O issue. I would hope that standard Pentagon timings would be sufficient for most Russian machines.

Quote:From the text it sounds exactly the same, but optimised for spanish texts. My routine I used in the 80's had also no depacking, just triggering.
Yes it does sound the same. I think I misunderstood you the first time around.

Quote:
cheveron Wrote:The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.
Excellent. How much % of the profit do you want for licensing it for comercial releases? Or is the licensing based on something other?

I appreciate that it's hard to break even on new releases for the Speccy, let alone make a profit. The percentage has to take into account a lot of factors: the actual amount of profit per sale (could be zero for instance), how much I contributed besides the engine, expected number of sales, and so on. But I will always agree the deal in advance before development begins so that the developer isn't left wondering how much of a return they will see on their work.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)