Jump to content

Photo

Oracle Series engine in ZC


  • Please log in to reply
12 replies to this topic

#1 Zepinho

Zepinho

    Experienced Forumer

  • Members
  • Location:Trieste, Italy

Posted 27 April 2015 - 04:24 AM

This is a proposal and an attempt to get people involved in the possible group project which might emerge.

 

Basically my idea is to put together efforts from different ZC designers and scripters in order to create a quest template and a script set which could be used to create quests with almost the same mechanics as the Oracle Zelda games for GBC.

 

Of course we don't have to start from zero, since most of the stuff we need already exist:

the EZGBZ 2.5 tileset from Lightwulf (http://www.purezc.ne...=tilesets&id=79) has most of the graphical stuff we need, and we have many nice GB-like scripts in the database.

 

But still it would be nice to have a place where to put all this stuff together and where to discuss how to proceed, what to include, how to do things, etc... And the goal of having almost a replica of the Oracle games should avoid most of the discussions on what is nice and what is not.

 

In case of success, the final result would be really benefical for many people who want to recreate the Zelda GB atmosphere in ZC without having to spent most of time writing scripts and fixing bugs. Then for instance we might finally have a complete "third Oracle game" which many poeple started and nobody finished, probably just becouse of the too many problems in implementing tons of features via scripts...

 

What do people think?

Would this be feasible?


  • Shane, Sheik, Jared and 2 others like this

#2 Sheik

Sheik

    Deified

  • Members

Posted 27 April 2015 - 05:08 AM

I support this is idea absolutely, in spirit anyways. I lack the time resources to help out with this (and as far as scripting is concerned I lack the skill anyways), but it would be absolutely great to have something like this available.


  • Taco Chopper likes this

#3 SyrianBallaS

SyrianBallaS

    Defender

  • Members
  • Real Name:Samer
  • Location:Detroit, Michigan

Posted 27 April 2015 - 06:34 AM

I would probably just a completely new engine using graphics that are already available. It's a lot easier that way, scripting something with non-flexible functionality is very unfeasible. I'm still getting my head around trying to write some basic scripts that don't seem to be included on the database.

 

It would take massive planning and teamwork, yet this is for free and I doubt many people would want to do it.

 

I have no time though.


Edited by SyrianBallaS, 27 April 2015 - 06:36 AM.

  • nicklegends likes this

#4 Avaro

Avaro

    o_o

  • Members
  • Real Name:Robin
  • Location:Germany

Posted 27 April 2015 - 07:55 AM

I think the main difficulty here would be to make all the scripts user friendly and flexible. Also, what about alternative versions of scripts? Will this include only 1 version for each script, or mutliple ones the users can choose from? For instance, there are different pit & lava combo scripts, that work slightly different and have different set-ups.

 

Once the entire thing is done, there should probably be a general tutorial available that explains what to do and what not to do.

This is a definetly a good idea though. If there's enough interest, count me in.


  • Jared and SyrianBallaS like this

#5 Mero

Mero

    Touch Fluffy Tail

  • Banned
  • Real Name:Tamamo No Mae
  • Location:Rainbow Factory

Posted 27 April 2015 - 08:01 AM

I'm definitely game, In fact I call dibs on solid ffcs! Also I get to make the switch hook too. We also have your GB Scripts Library you happen to share with me. And I've written a few myself. LA King Moblin and the various Thwomps which are still a WIP. But hey gotta start off somewhere right?

 

But as one of the top scripters I say it's fully possible.

I might not be as good as blue knight, but nobody was as good as that guy which is surprising since Saffith , Gleeok, and myself I consider on the same level. And two of us are developers, and one of us thinks she's a developer and really isn't but has access to the source never the less. Damn you boss do you not like me. Just kidding kolt.


Edited by Mero, 27 April 2015 - 08:10 AM.

  • Avaro, Jared and SyrianBallaS like this

#6 SyrianBallaS

SyrianBallaS

    Defender

  • Members
  • Real Name:Samer
  • Location:Detroit, Michigan

Posted 27 April 2015 - 11:54 AM

function templates seem like a good idea for this kind of thing, you just replace the place holder with the object. Or whatever its supposed to be called in ZS.

The actual template should be commented out though because I don't think they work here.

 

Example

template <typename Object, Item<typename> &item> // Object is either Link, Game, Screen, or Item and Menu is a vector of items of type Item.

or something like that, that's C++ so I don't think it can be directly implemented something along the same concept.

 

It definitely cannot be used directly because there can't customized data structures on inheritance (classes/headers/.zh)


Edited by SyrianBallaS, 27 April 2015 - 12:01 PM.


#7 Zepinho

Zepinho

    Experienced Forumer

  • Members
  • Location:Trieste, Italy

Posted 28 April 2015 - 05:07 PM

Thanks to everybody for the feedback.

 

For SyrianBallaS: I'm not fully getting what you mean in your last post...

Then, about your concern that writing a new engine outside ZC would be easier, I'm definitely disagreeing: ZC has a lot of functionalities we can take advantage, and, apart from reduced screen size and Z3 screen scrolling, the rest of GB-like stuff can be reproduced with not too much effort with scripts. 

 

For Avataro: I don't think the scripts would have to be flexible. Shat I have in mind is exactlly the opposite: have scripts which are integrated with the quest template, so that the user does not have to setup anything and just place stuff in Zquest ;) So, ideally even a non-scripter could use the quest template and create a quest with all the Oracle game functionalities. So no multiple versions of scripts: we should just take the best version for our purpose.

 

For Mero: yes, as I said we don't have to start from zero. We have a lot of stuff there, and we just need to put it together in anice way, as a first step. Then we could make a list of what's missing and share the work to implement it. Example of missing stuff: Ricky, Dimitri & Moosh, ring system, some items like Mermaid Suite, Switchhook... And then a lot of scripts would have to be tuned/fixed/combined, and the quest combos and times adjusted accordingly...

 

 

Now, general question: where (in this forum) do you think we could store the project? May be I should open a quest project, even it's not really a quest but more a quest template (so no story, etc...)? Any other suggestion? I think what we need is a dedicated kind of sub-forum to discuss what each contributor is doing and proposing + a place to upload from time to time the demos and the script set...

 

Then: in the end is anybody volunteering to contribute?

Is something still unclear about the goal and how to proceed?



#8 Sheik

Sheik

    Deified

  • Members

Posted 29 April 2015 - 01:23 AM

I suggest that you use a Quest Project Forum. When we debate things for the Firebird tileset we usually also do so in a QPF as well, in hidden topics in a hidden project - so nobody else is bothered by it. The QPF is really suited very well for this kind of discussion in one dedicated place. If you keep track of how you name topics and where to post what you won't get lost with it either.


Edited by Sheik, 29 April 2015 - 11:19 AM.


#9 Zepinho

Zepinho

    Experienced Forumer

  • Members
  • Location:Trieste, Italy

Posted 29 April 2015 - 03:14 PM

Ok, thanks for the suggestion Sheik.

I just opened a quest project: http://www.purezc.ne...projects&id=276

 

I will start to add stuff there soon!


  • Sheik likes this

#10 SyrianBallaS

SyrianBallaS

    Defender

  • Members
  • Real Name:Samer
  • Location:Detroit, Michigan

Posted 29 April 2015 - 03:38 PM

@Zephino

Almost the entire development process is thrown out when you can't make changes to software, if you don't work you won't know what it is.

Look into Waterfall Paradigm and AGILE, you are thinking making engines is like Waterfall.

Almost every kind of business uses the waterfall paradigm because all requirements are finished at one time. In software development,

Requirements change instantly, i.e., the evolution of software. If you think using making an engine using scripts is a good idea, it is 99% likely to fail.

What I've noticed is that ZScript works a lot like hacking, a.k.a., "Network Administration" like using the command prompt to force the computer to bend to your will.

 

If you think it's feasible go ahead, I'm just trying to save you a headache. Algorithm optimization and the factoring of classes is near impossible using a closed source engine.

 

Scripting also has security vulnerabilities because it doesn't use polymorphism or encapsulation, and all members are public. Anyone could easily rewrite it and destroy your computer or network.

 

Anyways good luck,

Samer


Edited by SyrianBallaS, 29 April 2015 - 03:43 PM.

  • Evan20000 likes this

#11 C-Dawg

C-Dawg

    Magus

  • Members

Posted 05 May 2015 - 11:09 AM

Really, all you folks need to do is code a scrolling algorithm that allows use of ZCLASSIC native entities like npcs, secret flags, and so forth. So, you know, basically a whole new engine.

 

EDIT: Here's the basic skeleton of such an engine.  Note that it would not allow combo animation or cycling as I've designed it, but you might be able to code up shortcuts.  

 

Define the size of the screen
(use an ordered pair to determine size in X,Y measured in screens.  This will define an x,y grid made up of the pixels taken up by those screens.)
 
Locate player on the screen
(On initial entrance, set where the player is using the x,y grid.)
 
Draw the screen
 
1 - Check player’s location.  Using x,y grid, determine which screen the player is on, and what portions of side screens might also be visible.  Call this the Visible(x,y)
 
2 - Get the ComboAt data from all combos on the screens overlapping Visible(x,y) and determine the proper place to draw each one.  Put these in a temporary X+1,Y+1 array.  It’s bigger than the screen because you might have to offset it by the player not standing directly on the 16x16 grid.
 
3 - Get the walkability data from all one-fourth of combos on screens overlapping Visible(x,y) and save them into an array of (x,y) so we know where the player can and cannot walk.
 
4 - Get the Screen “secret” status of each screen within Visible(x,y).  If it’s triggered, get the secret combo data from each combo overlapping Visible(x,y) and replace the appropriate combos in the X+1,Y+1 array you made.
 
5 - Get the Flags from each combo with in the Visible(x,y).  Store them in another X+1,Y+1 array mirroring the combo array you are building, for use this frame in checking for secret interactions.
 
6 - Draw each combo’s graphics to the screen.
 
Place Enemies and FFCS
 
1 - Check if any of the flags in the X+1,Y+1 array of flags you just made represent enemy flags that this script has not dealt with since the player entered the screen.  (Remember those that have been dealt with by saving the x,y coordinate of those you have dealt with).  If so, check the Screen data related to that enemy flag and spawn the appropriate enemy. 
 
2 - Check to see if your Visible Area now overlaps the x,y coordinates of any FFCs on Screens you have not yet dealt with.  If so, copy those FFCs and move them onto the screen with the player at the approprate x,y location and initiate their scripts.  (Remember FFCs that have been dealt with by saving the x,y coordinate of those you have dealt with).
 
3 - Check the array you’ve made of stashed FFCs and enemies that may have scrolled off of the screen.  If one of them is now on the screen again, load it up at the appropriate location and remove it from the stashed array. 
 
Player movement
 
1 - If the player is pushing a direction, first check whether the direction would push the Visible Area outside of the defined x,y.  If so, keep drawing the screen as it is.  Don’t move any enemies or FFCs or weapons.  Block the player from moving if the movement would take them into a part of your x,y grid that is set to non-walkable.
 
2 - If the player pushes a direction that will move the visible area without exiting x,y, and is not trying to walk into a non-walkable combo, and the player is sufficiently close to the edge of x,y, then do the following:
 
3a - Shift the Visible Area 
3a - Move all enemies, FFCs, and weapons equally to how the Visible Area is shifting.
 
4 - For each enemy, FFC, or weapon that moved, check where they are on the screen.  If they’re now scrolling off the screen, copy all relevant data of the entity and stash it in an array with its last location so you can recover it if you scroll back to that location in the future.  (Will reset FFCs, potentially, so if you want FFC scripts to keep working regardless of player location, build a way to have the FFC follow the player around into the code)
 
Secret Combos
 
1 - For each secret combo in the temporary array you built, check for the state or event the combo cares about.  For example, check to see if a sword weapon is next to a sword combo, etc.  If so, set secrets on the relevant Screen at that Combo.
 
Flags and Combo Types
 
1 - Check the flags and combo types of the combos on the screen.  If they have an impact on the player (conveyer, etc) then implement those effects in script.
 
Subscreen
 
1 - To avoid messing up the draw function, you can’t use a normal subscreen.  So, code up an entirely custom subscreen and map experience and implement this when the player hits “start” by freezing the enemies/weapons/ffcs/collision detection (might need a global variable for the latter) and using player input to interact with the screen.  

Edited by C-Dawg, 05 May 2015 - 11:35 AM.


#12 Mitchfork

Mitchfork

    no fun. not ever.

  • Members
  • Real Name:Mitch
  • Location:Alabama

Posted 03 March 2024 - 12:47 PM

impossible
  • Rambly and Taco Chopper like this

#13 Taco Chopper

Taco Chopper

    protector of the darn forum

  • Administrators
  • Pronouns:He / Him
  • Location:South Australia

Posted 03 March 2024 - 09:19 PM

impossible

what do you mean? that a long-term member of the ZC community has built a GB Zelda engine from the ground up, using ghost to create an 8-directional enemy knockback engine? that the engine is called stdMitchfork.zh? that it just works?

I agree with you. absolutely impossible.




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users