View Full Version : tLoZ: Dawn of Minora
I finally worked out most of the bugs in my quest. Here is the nonpassworded file for your enjoyment!
Happy Holidays folks!
Features include: Lantern, skateboard, 2 settings missile launcher, 10 sword selection menus, hp/mp/attack/defense up level upgrades, sword upgrades, and other things.
The defense stat is still not functioning though.
The rest of it works fine so far, along with the debug screen accessed by scrolling up on the mouse wheel.
Ventus
12-08-2012, 11:45 AM
Sounds neat, I'll be giving it a try later today.
Edit: Well its quite interesting. Its not a quest. its more of a debug type of thing. Which is pretty cool.
Moosh
12-08-2012, 01:33 PM
Can't seem to get the debug to work. I scroll up on my tracpad but nothing happens...
Can't seem to get the debug to work. I scroll up on my tracpad but nothing happens...
Yes, for some reason the tracpad on laptops and touchscreens doesn't activate the Z-axis like a mouse-wheel does.
I just ordered a Splitfish dual controller with tilt axis also so I might be implementing some balance feature for the skateboard.. Since Link gets around so fast with it though it might be too much of a burden to have that unless it's made very non-sensitive and forgiving in it's balance compensation.
This is actually going to be a quest eventually.. I've just been working mainly on the platform for the experience based levelling, debugger, and action scripts so far though mainly, it takes me a long time to make screens that are quality enough for me to like them, and when I don't like them they get erased.
Other features I forgot to mention were the Character switching from the screen with the portrait of Link on it.. and Zelda and Ganon's specific abilities. Zelda runs way faster, and can use MP to deflect enemies and their projectiles, and Ganon can do a Lunge attack like Twilight Princess's Link.
However, this quest file did start out as mainly a debugger for implementing into any quest for beta testing and severe enemy-hoard placement for fun. With a few little modifications it turns into a two player hack'n'slash game where one player can summon enemies, (with some sort of limitation for how many they are allowed to) with the mouse while the other player controls Link.
Feel free to use any of my scripts or graphics in your quests if you like them. I would appreciate a spot in the credits though!
Thanks for checking it out!
Moosh: you could modify the script file, it's right after the global's while(true) [line 421] where it says if(Link->InputMouseZ>0&&Link->InputMouseZ<3){Q();} or something like that and change the script so that it is activiated a different way.
Be at the dock between 8:10 and 8:20 AM to get the sword from the mermaid, then there's a Patra battle on the sideview scrolling screen when the player dives into the pool to the east of town.
I rewrote the sideview platform scrolling screen so that it can do multi-layer collision, i.e. multiple levels of walkability on the screens, and is now easier to assign graphic and collision as they match up with a single number on the prolonged x-axis.
I am going to write in a designation code for bitmaps and other forms of platform drawing today, so that any graphic can be assigned, or a whole screen can be assigned as the graphic, so that all someone will have to do to make a complete sidescrolling game is draw or copy/paste screens onto the map and write in the screen numbers every 240 pixels.
It works great and complete megaman-esque style games can be made in a few minutes with this code.
After I am done I will post a new demo, but that might be in a few days as I have decided to take a break from scripting and ZC in general for awhile.
The only thing that is upsetting to me about this whole concept is that the collision goes by every 8 or 16 pixels on the y axis, therefor a climbing/decending screen is not yet quite possible with this style of code. I would like to talk with the coders of ZC about being able to assign a combo on any Y axis position, that would definitely be awesome. As it is right now a climbing or decending level would be really choppy because the collision would be like limbo every other 7 pixels.
http://www.youtube.com/watch?v=-C-Gr26hC34
Here is the video of some progress I made with the sideview after some help from Saffith.
This scripting with some better graphics would actually make a really great game. The collision for the sideview platforms happens automatically now, so all the coder has to do is assign an x-axis number on a prolonged distance marker and the y axis and the script does the rest.
Edit
http://www.youtube.com/watch?v=9h2NnKrFxOI
an even better demonstration of what it does.
http://i156.photobucket.com/albums/t33/zim_indro/Level1EntrancePhoto_zps64878fff.png
Here's a screenshot of what will probably be the entrance to level 1 in the final.
I've been posting various videos of progress on YouTube lately, here's another one:
http://www.youtube.com/watch?v=XBUp07G_SJk&feature=youtube_gdata
It's an Arena feature that's going to be part of the game I'm making. Eventually, after being able to place bets on who will win the matches, Link might participate in the Arena himself, with a team. To do that though I will have to make some NPCs that will actually fire LWeapons instead of EWeapons, so they don't hurt Link, because any other method of bypassing the collision might make bugs that would cause him to become invulnerable to the enemy's attacks whilst his collision is disabled for his own team's enemies.
Anyway, the scripting for the baddies to duke it out in the Arena is done.
I finally got round to doing the 'passive-active' deal for the equipped items. The method I decided to go with, since I use PS style controls for ZC, 4 buttons on the front, four buttons on the top, is use ex1-ex2 to switch menus, ex3 &ex4 for action oriented moves, like quick hops, parry's etc. and L and R for A and Bs' equipment. Holding L brings up a menu with the inventory, which is scripted to never go outside the screen, it works just like the subscreen from there, except for holding the button down and using d-pad instead of pressing dpad then A or B on the subscreen to select item, the item the selector box is on last is the item equipped to link when the button is let go of, and followed by NoAction() so Link doesn't get to move while changing equipment. R does the same thing for the A button: HoldR+Dpad+RelR=Last item selector was on is equip to A.
http://www.youtube.com/watch?v=ZFpQlGmw9gQ
ALMOST enough original content (scriptwise) in this game to believe it will be a masterpiece someday, graphically it's still completely rehashed DoR with minor alterations, and not many screens I'd actually pass into a final draft myself.
http://www.youtube.com/watch?v=TdY3aw1E-1E
Here is video with all the bugs worked out. The only thing left for this script to be 100% is item tile assignment, and to make no graphic in the spot when no item is present, and change the framing of the box, of course.
https://skydrive.live.com/embed?cid=0894C6448C0633B6&resid=894C6448C0633B6%21198&authkey=ABJfF_1zCHN1Msw
Any questions about any of the scripting usage ask someone else. jk. good luck. :)
With a little bit more scripting the part of the code with the mario level 1-1 stuff could be continued with functions that would auto-generate mario-style levels by making the collision/graphics line up and make the code so that every gap in the bricks is always clearable and aside from that always random, this can be done using parameters for the mins and maxes the next bricks are going to be allowed to be away from the last ones, including the changes in elevation always having a way for 'mario' to be able to clear using whatever maximum jump you decide to set the player at.
I'm probably going to take another prolonged break from ZC again for awhile, if anyone reads this, the above file has all the coding I described in it, and you're welcome to continue evolving whatever code you might find useful to you. I'll get to writing the prior script stuff I described in this message myself if noone gets around to it and I get back to agn sometime.
A spot in the credits is always nice if this is useful to you in a production I'd appreciate that!
:)
There's now a color selection shop for Link's Tunic. There are 9 color options available via a small window after Link chooses to get a new color for 20 rupees a pop.
Future plans include a hair stylist and a shoe store as well, the possibilities are endless for other add-ons for the little hero/heroine, whether or not they will make any difference in the game depends on a few other factors that I have not worked out yet that may or may not be in the works, including altering homing factor of enemies if Link's tunic and other apparel are camouflaged with regards to his surroundings, and whether or not other events in-game might only happen if and when he's wearing certain clothing of certain colors.
There's now a color selection shop for Link's Tunic. There are 9 color options available via a small window after Link chooses to get a new color for 20 rupees a pop.
Future plans include a hair stylist and a shoe store as well, the possibilities are endless for other add-ons for the little hero/heroine, whether or not they will make any difference in the game depends on a few other factors that I have not worked out yet that may or may not be in the works, including altering homing factor of enemies if Link's tunic and other apparel are camouflaged with regards to his surroundings, and whether or not other events in-game might only happen if and when he's wearing certain clothing of certain colors.
Change Link's Cset? Cool! Also, I think it's a neat idea to give a bonus for matching the cset of the dungeon.
King Aquamentus
04-26-2013, 09:55 AM
http://www.zeldainformer.com/news/zeldaskate.jpg
Hells yeah
http://www.zeldainformer.com/news/zeldaskate.jpg
Hells yeah
Looks pretty sweet! Going to have to get more content done. Still very far off from a real quest though.
I'm going to be keeping the updates and videos to a minimum for awhile until there is at least a playable demo with a few levels to run through.
Thanks for showing me the shirt, that's pretty sweet!
There is a Lance for Skateboard Jousting in the plans. I haven't drawn or scripted for it yet though. A weapon a little longer than the sword that Link can hold out in front of him instead of have to repeatedly press the button, and possibly move around slightly by bracing with the strafe button and then moving it.. Although he won't move it significantly away from facing forward.
King Aquamentus
04-26-2013, 10:39 AM
Yeah, it's an obscure piece of merchandise, but when you mentioned "Link on a skateboard", it immediately came to mind. XD
I have made a few improvements to the game, and my first overworld map for this quest is at about 50% completion, minus a lot of layering touchups.
Newest features include:
a)enemies damage each other if not the same type of enemy, which could lead to areas where the player could rack higher experience than they could by actually beating the enemies themselves by dodging attacks long enough to rack exp.
b)the enemy's attacks when hitting each other also show hp- floaty little nifty dealios in numerical value.
c)the live-action no-subscreen item menues are perfected, and ready to go.
d)Link now latches onto walls in side screen like before, only when pressing towards the wall, if the player lets go of the direction, he flips off the wall backwards.
e)A dragon enemy boss is in the works, 25% of the graphics are done, 10% of his mobility.
f)3 entrances to dungeons on the first overworld map are there..no dungeons even started yet.
g)the "Arena" battle between enemies is going to be a classic at some point I think. Sortof like horse-racing, the enemies shoot at each other with projectiles at random until there is only one team standing. I'll implement some sort of rupee betting system eventually. Thusfar the teams have been even, but there will probably be 'underdog' matches in the works.
I haven't submitted any screenshots to SotW at all yet, so here is a short video of one of the ones I like.
http://www.youtube.com/watch?v=QpyTamiIAoM
I didn't want to just submit a picture because that doesn't do it justice. The bridge is swim-underneathable and walk-overable on the same screen due to scripting, and not a seperate duplicate screen.
Also there is a short demonstration of the live action button item menus with the bugs worked out.
http://www.youtube.com/watch?v=TMD3CzZzy2c
Here's a little demo about Ice Reflections. I saw/duplicated a really neat tileset with layering that caused a reflection in the water or ice underneath the pillars some years back, this script would compliment it nicely. The author of it gave a tutorial on how to use it on PureZC, I'm probably going to use something like that for a level in this game + this reflection script.
Just another update on things that are going on with my quest:
A)The 1st level dungeon is at 80% completion! Whee! Reflective glass floors, new door styles, and a boss that thusfar defeats me EVeRy time! (although I can see even an average player being able to win with some extra levelling up.)
B)New Door styles: Shudder doors that open when the enemies are all defeated! (You may be thinking, "that is already exactly like other doors I've already encountered, Zim! That's rediculous!", but this is different because:) The new door type is actually ran on an FFC, preventing Link's movement in the desired direction by proxi to the door and flags of whether or not it's open. I made this new door type for a few different reasons, it's unrestricted as to where it can be placed, no Combo Position limitation, and it can be triggered by ANY lil' ol' thing, like talking to grammy at 5pm on Day 6 gets a door open in Castle room A Dmap x, screen n. etc. etc.
C)Which leads right into new feature C, Small Key Doors FFC type! Again, you might think this is rediculous and redundant to re-create such minor details for a freeing up of placement by 15x15 pixels of movement, HOWEVER, this new door type is specifically to be rid of the idea that every time Link uses a small key the door disappears, along with the key. The doors CLOSE after Link leaves the room, and the keys are now REUSABLE. That is to say that if Link has a key that fits a certain door, or set of doors, the key does not vanish from Link's inventory when he uses it, and the doors do actually reclose, and open upon pressing the R button when standing by them.
Examples: Most of the doors in Lvl 1 are shudder doors that close behind Link when he enters a room, locking him in, and they all stay shut until all the enemies in the room are defeated.
The exceptions to this are when there are the doors that need the LvL 1 Dungeon Small Key, which are closed every time Link enters the room also, however, if the player decides to SAVE, or DIES, and CONTINUES, those rooms may be bypassed enemy-slaying wise as the player already will have the key to open the door still.
D)The Zelda character can no longer run on top of the water, in fact, water deters her movement altogether now and she won't step foot in the water. Also, character switching is prohibited whilst in the water. Ganon also doesn't go near the water.
E)Might as well be part of D, because it's the same thing, except for with regards to the skateboard. The skateboard no longer launches effortlessly over the water, instead, water combotypes act just like a solid combo, and Link's movement is blocked. IF Link happens to get the bright idea to jump into the water with his skateboard just to see what happens or something, he'll lose his skateboard and have to find another one.
Here's some sound bits for the enhanced soundtrack so far:
https://skydrive.live.com/redir?resid=894C6448C0633B6!201&authkey=!AKuee0nQLCO-gRM
https://skydrive.live.com/redir?resid=894C6448C0633B6!203&authkey=!AJMFPGzkAurMv_s
https://skydrive.live.com/redir?resid=894C6448C0633B6!202&authkey=!AL86R4W9l55l4II
And a deeper sounding last intro track:
https://skydrive.live.com/redir?resid=894C6448C0633B6!205&authkey=!ACBgu6rcAFtFT-s
It's the same track as track 3. I still have lots of mixing to do and to actually make the intro cutscenes before I make final decisions on how the arrangement will go.
One final mix for now:
https://skydrive.live.com/redir?resid=894C6448C0633B6!206&authkey=!AHNTl4WP3_s7An4
This will probably get edited a few more times before the game. ++ I actually prefer to play the guitar track live so when I get new strings (I am very poor and have no idea when that will happen.) I will record the track. :)
I hope you like these though.. Any feedback is welcome though for suggestions on improvements of how you think it should sound, and by that I mean by posting here, not yelling at me while I'm doing productions at home.
Something exciting for today: I finally completed (after a meer few hours of working on this) a surprisingly short set of functions that can grab the collision off of the maps drawn as they are and directly implement that into the sideview screen scrolling functinos I wrote out.
It grabs the ComboS of whatever map and screen and pastes it onto the current screen as it scrolls, pretty nifty.
What it looks like in action:
http://www.youtube.com/watch?v=FnY1CjPdUFM
Okay, I think I need help... I have the thing working perfectly except for the deal demonstrated in the Mario Lvl 1-1 video where he scales upwards into the clouds and the screen resets automatically to the center every time he lands on a new platform. The collision is working perfectly, and everything else in the scripting is the exact same as when I had to write in the collision except for that it's done by itself, all I have to do is draw the combos on the screen with ZQ and the scripting does the rest now.. It just won't recenter the screen anymore for some reason.
Are there any experienced scripters out there that would like to take a look at the quest file and help me find out what's going wrong with it?
note: Without the Y-axis scaling it's working beautifully, which is great because I planned on making levels without the Y axis scrolling anyway.
Since noone responded to my call for help since yesterday I decided to go ahead with Overhead Scrolling scripting, and it works perfectly!
The only thing it lacks so far is a new warp type that can actually set Link at the right place on the map.. I already know how I'm going to go about doing that though. It's break time for awhile now though.
It's official, with all the scripting I've done ZC can function like Z3.. With the exception that I haven't taken the time to write up the hookshot scripting for the scrolling segments.
All the collision is done automatically via script so all the user will have to do is tell the script code whether or not their DMap is using scrolling, and the top-left most screen of the scrolling segment, and what the dimensions are for the edges of the scrolling segment of the Dmap, because the same DMap can actually be used for more than one scrolling section, with different boarders for each segment, so the screen will stop scrolling when Link is at the edge.
Here's a short video:
http://www.youtube.com/watch?v=yLmyl2V8jKw
The enemies only have 4 modes of movement so far also:
1)Just like as if they were not modified and move like ZC enemies did before.
2)Going towards Link/homing.
3)Going away from Link/Running away
4)Circling Link.
Wall bombing, swimming (I even made the flippers equippable and Link swims faster overall with them on, and has a boost like LttP), the enemy and Link collision with walls, and Warp are all done. The user will be able to make tile warps in the scrolling screen by putting them on the ZQ the regular way.
The few things I have left to get done:
1)Hookshot for scrolling portions.
2)Pushblocks - The most challenging thing to accomplish: I could easily write up FFC, drawtiled, or other type of pushblocks.. Writing them up so that the pushblock happens automatically in the scrolling segments is a bit of a brain buster though.
3)Key Doors: Which is exactly like bomb walls so that's pretty much done - a slight mod of the other script.
I made that alternate key door and shutter door, but those are ffc and not modded for scrolling yet, also require a little bit more setup than just putting a door on the screen with ZQ.
4)Bush Burn: Also exactly like bomb walls so that's gonna be a quick fixup.
5)Pegasus Boots: I have everything I need for this script in my head already, just haven't got around to it yet. Also, I need to check out LTTP since it's been over a decade since I played through it and see how the behavior is. I recall him staying completely still, charging up to run, and then dashing in a straight line until a collision or the player stops.. Then I also have this memory of a stutter step forward whilst charging to run.. Maybe that was a different game though.
6)Block Maker Cane.
The rest of the things I have planned for my ZC stuff are all optional, and not really an essential to functionality..
Like lock-on boomerang, which is already done - some modding of the lock-on missile script, complete with multiple target selection.
Wolf-Link style lock on and lunging for scrolling : It's already done for regular overhead, sideview is okay also, nether overhead or sideview scolling can use it right yet though.
Since there are random weather patterns in my game, and the wind changes direction at random already, Wind-Waker type stuff is just one "baton" item in the box and a button/dpad press away from there.
A small playable portion of a game involving the clock, days, events, and the looping of those things: This is already done actually, the events I made in the original quest file weren't all that great though, there was a mermaid at the dock and people talking about it if Link missed his chance, gave hints towards what time it was, etc.. Then he could restart the clock and go there and she'd be there and give him a sword... I had plans for a guy to be blocking the entrance to level 2 until 9 A.M. Day 1, regardless of Link's other activity.. That way he'd be able to access Level 2 pending the condition of having the game on for 1 hour, despite everything else going on, then make the ability to jump ahead some hours available after beating Level 2, so upon restart he could get there in a quick minute.
I have LttP Ganon sprited and ready for scripting. I think I'm not going to try to make him the exact same though. Probably a lot more difficult to defeat and quicker or something. I ran through LttP in approximately 2.5 hours in my younger days, 100% Completion, all items, hearts, etc, and it felt easy to do.
This stuff being said, I would like to hear some voices/read opinions about your take on making this scripting a package for quest creation. I know I've read more than one thread in more than one forum about people making LttP remakes, and they all said they actually don't do screen scrolling or other things actually LttP-esque, but moreso using the graphics.
So I went and get the LttP tileset and checked it out.. It's not really that good because the NPC are their usual size and Link for some reason was crunched into a 16x16 pixel space instead of using a hitbox offset and an extended tile.
Pending an actual modification of that tileset, (Since I usually lack the patience to rip and grab all that stuff myself I would use it as a base, *hope to get full permissions first*), it would maybe be most optimum to use that tileset in conjunction with this script for a bundled quest making package.
The modifications will have to be a) Putting in all the graphics for stuff that isn't in it already for 'Essential' things, mainly the debugging portion, and a few other things. That way if someone picked it up, even if they didn't/don't like my graphics they would know exactly what's going on and change the tile numbers or copy over mine. b)Make Link's tile the normal size. It's actually totally ridiculous looking to see all the normal LttP stuff and this crunched Link in the middle of it.
I'm using the DoR tileset and I like it. The LttP tileset would be great to use too though.
I've read a lot of stuff now about LttP remakes.. I would actually like it a lot to see this happen. It'd take me a year working non-stop to tile out the whole game myself though... Which is why I'm going to start a new thread about this topic.
Edit: The only "special" setup for this whole scrolling screen process is that when Link is warped to a DMap with scrolling, he actually needs to be warped to the DMap and screen directly -1 of the DMap of layer 0, and the quest creator needs to put in the Screen X and Screen Y of the scrolling screen parameters. So for Screen 0,0 of Dmap 2, scrolling a 6x4 screen, he or she would have to warp Link to Screen 0,0 of DMap 1, and input 6 and 4 into the scrip that when Link is on DMap 1, Screen 0,0, the X parameter is 6 and Y is 4.
int M[100];
int MU[100];
void MULVAL()
{
M[0]=AxB(A,N[0]%10);
M[1]=AxB(A,(N[0]%100-N[0]%10)/10)+((M[0]%100-M[0]%10)/10);
M[2]=AxB(A,(N[0]%1000-N[0]%100)/100)+((M[1]%100-M[1]%10)/10);MU[0]=(M[2]%100*100)+(M[1]%10*10)+M[0]%10;M[2]=(M[2]%100-M[2]%10)/10;
M[3]=AxB(A,N[1]%10)+M[2];
M[4]=AxB(A,(N[1]%100-N[1]%10)/10)+((M[3]%100-M[3]%10)/10);
M[5]=AxB(A,(N[1]%1000-N[1]%100)/100)+((M[4]%100-M[4]%10)/10);MU[1]=(M[5]%100*100)+(M[4]%10*10)+M[3]%10;M[5]=(M[5]%100-M[5]%10)/10;
M[6]=AxB(A,(N[2]%10))+M[5];
M[7]=AxB(A,(N[2]%100-N[2]%10)/10)+((M[6]%100-M[6]%10)/10);
M[8]=AxB(A,(N[2]%1000-N[2]%100)/100)+((M[7]%100-M[7]%10)/10);MU[2]=(M[8]%100*100)+(M[7]%10*10)+M[6]%10;M[8]=(M[8]%100-M[8]%10)/10;
M[9]=AxB(A,(N[3]%10))+M[8];
M[10]=AxB(A,(N[3]%100-N[3]%10)/10)+((M[9]%100-M[9]%10)/10);
M[11]=AxB(A,(N[3]%1000-N[3]%100)/100)+((M[10]%100-M[10]%10)/10);MU[3]=(M[11]%100*100)+(M[10]%10*10)+M[9]%10;M[11]=(M[11]%100-M[11]%10)/10;
M[12]=AxB(A,(N[4]%10))+M[11];
M[13]=AxB(A,(N[4]%100-N[4]%10)/10)+((M[12]%100-M[12]%10)/10);
M[14]=AxB(A,(N[4]%1000-N[4]%100)/100)+((M[13]%100-M[13]%10)/10);MU[4]=(M[14]%100*100)+(M[13]%10*10)+M[12]%10;M[14]=(M[14]%100-M[14]%10)/10;
M[15]=AxB(A,(N[5]%10))+M[14];
M[16]=AxB(A,(N[5]%100-N[5]%10)/10)+((M[15]%100-M[15]%10)/10);
M[17]=AxB(A,(N[5]%1000-N[5]%100)/100)+((M[16]%100-M[16]%10)/10);MU[5]=(M[17]%100*100)+(M[16]%10*10)+M[15]%10;M[17]=(M[17]%100-M[17]%10)/10;
M[18]=AxB(A,(N[6]%10))+M[17];
M[19]=AxB(A,(N[6]%100-N[6]%10)/10)+((M[18]%100-M[18]%10)/10);
M[20]=AxB(A,(N[6]%1000-N[6]%100)/100)+((M[19]%100-M[19]%10)/10);MU[6]=(M[20]%100*100)+(M[19]%10*10)+M[18]%10;M[20]=(M[20]%100-M[20]%10)/10;
}
Here's an add-on for the calculator script that does the multiplication. You'd have to integrate it yourself, and thus far only does 1 digit multiplied by 20 digits. You could go power genius on this and use those other conversion scripts already included to make it do more.
crazyal02
07-12-2013, 10:41 AM
Wow, this looks really cool! The scrolling in particular is impressive
This project is pretty jaw-dropping. Is it just me, or are your side-scrolling bits trying to mimic Metroid more than Mario? Because Metroid is a cooler side-scroll game anyway, especially when RPG elements like equipment are involved.
This project is pretty jaw-dropping. Is it just me, or are your side-scrolling bits trying to mimic Metroid more than Mario? Because Metroid is a cooler side-scroll game anyway, especially when RPG elements like equipment are involved.
It's wall kicking for sure. After some adjustments and decision making I decided on no kicking off the same wall twice, which isn't exactly like Metroid, and can be changed quickly, and that ex2 (i think) allows the character to grab the wall and cliffhang.
The game file is ready for other users to make quests with.. I'm pretty much done with further development until I get a new laptop (because I smashed my 4 core toshiba in a fit of rage) and I learn more about .dat file writing.
In it's current state, with minor alterations, it could mimick anything from Mario to Megaman X.
Thanks for the compliment! I appreciate that!
edit: Which reminds me, anyone interested in buying a motherboard or memory chips from a P755? (which btw ran this quest at 50+fps even with the scrolling and 10+ baddies on the screen.
In any case it's still a Zelda game at this point though, although that scrolling snippet fornula could be used in just about any game engine to link screens together with slight modification.. i.g. using a variable for bmp sizes where it says 256 and 176 to draw bmp of any size on the screen as they are needed.
I actually published it as is so other makers could use it... All the other details about enemy patterns and stuff are their choice anyway.. also, it could even use ghost.z like I described if someone were careful enough with the modding.
Next year though I'm planning to make the Zelda and Ganon chars dissapear and give those abilities back to Link, making the "wolf" transformation for lunging instead of Ganon, and bring the "bunny hood" to ZC, because Zelda's faster running is basically the same thing.
Posting about the lock-on targeting and missile launcher a few quick notes for coders out there that may have used it..
If someone were to make a dummy missile path with the exact proportionate velocity of the script using a lerp code multiplied by some number in order to check for a collision with the target npc or Link, for a baddie using the missile, and compensate for the way that the dummy path would possibly miss the target for to the speed of the missile check going past Link in one frame by making a dummy collision circle on the target expanded by the size of the total distance the dummy missile moves in one frame, in order to check for a cleared path for the actual missile upon launch, since it should obviously donate on collision with a solid and no-one wants that, the npc or Link would have to dodge or take cover after launch, and the npc would never fire else-wise, and link could have a green ridicule for clear path and red for collision with obstacles..
:)
I'll get back to actually doing this myself later, but thought I'd post it here just to share the idea in case someone else might like it and make sure i is somewhere I'll notice later.
Doing this for all three targets seems like it would be best, although applicability wise I'm thinking an a.i. to not fire at random mostly.
After this check, of it fails, the npc is to check at x amount of points around itself at n amount of intervals in z distances for possible routes to obtain a clear shot, possibly considering other factors like what weapons Link has used in the battle, are currently equipped, or otherwise are known to the a.i. as per storyline, so as to avoid imminent danger to itself in the meanwhile. This is going to be subject to how much code ZC can handle on the system without slow down.
Sounds, quiet ones, for grass stepping, other movements, etc., and npc that hear it within x distance, and move to the most nearby wall to take cover, then peek around the corner to obtain visual, then run at Link. They will also be alerted by sounds from other npcs that aren't within vision and do the same thing to them. Sometimes attacking if a different type of npc.
Random encounters of npc battling each other and changing target to Link if he intervenes.
Sometimes, depending on npc type and/or circumstance, both, all, or some of the npcs react to Link's hostility by attacking him, other times some of them take the opportunity to flee, act as if Link has rescued them and desist violent behavior, or continue attacking their previous target with Link.
Of course Link will be looking for items to loot and battle experience, so he will have to be very selective about what to do. Some npcs are looters themselves, so he's going to prefer to be in the action mostly, but sometimes it might be beneficial to observe and time his participation accordingly. Battle points will not be given for npc vs.npc deaths, and a counter for each npc that keeps track of damage done by Link will diminish the amount of bp Link gets proportionate to that of counter if not 100%,, yet the multiplier for on-screen enemies will remain in effect. Most npcs will never respawn quickly, and some won't at all unless a pair are left alive.
Standard elemental damage/defense stuff will still be implemented, and also have a role in npc-types conflict with each other in some areas, especially where climate change is a factor where hotter enemies meet cold ones that would extinguish their fire, and the fire would melt the ice the cold ones are used too, making either irritated or otherwise in harm's way, and other similar circumstance, like a lava ridden monster encountered by a dry plant.
Of course, some of the npcs will be hunting for food, predator style, and most will have a hunger counter, at least all of the more mobile types that are not fixed in the ground or otherwise fed through some other magical means.
Some "dungeons" are going to be only possible to gain access to their areas with help from npcs, possibly by alternate means upon obtaining skills and items, skills with items, etc. and as the title might suggest, the timeline will reset in the event that the circumstance Link gets himself into prevents him from moving on.
This will also, since this game is not going to be a three day time span dependant on Link saving a town with a terminal condition via Majora, make way for an almost endless amount of possible opportunities for Link to explore involving waiting around with limited npc involvement except for slight level ups after days, weeks, or even years for them to spawn, and maybe even evolve. For example also, a man might appear from it off town on day 5 only if Link doesn't progress through the storyline to x dungeon because he can't yet, but does have the item he obtained from a dungeon he couldn't get to until day 6.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.