![]() |
Oh, you mean why weren't scripted ones made? Good question.
|
Baddies could only be made serverside under the constraints I was given. The only option for baddy movement was to use a move command that couldn't be interrupted by other events (like being hit by a sword). I.e. you could literally only hit a baddy when they weren't moving. There was also the translation of movement to the serverside, and it wasn't exactly trivial to map clientside movement to serverside movement because the clientside can check every frame iteration, but in order to check movement serverside, you have to ensure the whole vector of movement between move calls wouldn't put the baddy in a wall. There was some progress made, but nothing I was happy with (I'm not happy with iClassic's baddies compared to the original baddies either, even though I respect the work put into making them halfway decent).
Edit: I should add that even though move included a blockcheck, it was broken. I don't know what the constraints Thor and Dusty had, or what differences in GScript may have come about to potentially make things simpler, so I can't really speak to their implementations. I certainly wasn't given the option of built-in baddies by Storm, as custom serverside hit detection required custom baddies. However, iClassic's baddies seem to be implemented serverside with many of the pitfalls I faced unaddressed, and I imagine that took a **** ton of time. PC GtA's baddies seem to be implemented clientside, essentially bypassing all of those issues. |
Quote:
function onWa****() { this.x = this.x; this.y = this.y; } Serverside is pretty much mandatory, so to compensate I designed the ganis to have a larger "range" so I could setshape the baddies to a larger size, thus improving the compensation for delay with hit detection. I also implemented clientside hit detection that doesn't rely on triggeractions, but instead a buffer DBNPC that handles that data communication. I found none of the cache methods that move() offers useful. Eventually the positions will become different for players and will see the npc in different places. However could possibly use some clientside extrapolation to smoothen out the movement. As far as serverside AI goes, with scheduleEvent() you can now create more than just a timeout loop. So you can let the .1 timeout handle movement and set a slower loop to handle complex AI such as picking targets, pathfinding and so on. Also Stefan suggested not using onMovementFinished and instead set a timeout for the same movement time and using that instead. I started the graphics for remaking the old style baddies but never finished. Could be cool. |
Quote:
|
Quote:
Quote:
|
Quote:
|
Great discover makes the nostalgia comes to the players of the old graal. :)
|
Why did you guys move Avalon to the east?
|
5 Attachment(s)
Quote:
---- Well here's something I actually have the graphics and ganis saved for. A boat, and the ****ty level I built to test it in. I only ever implemented primarily horizontal movement with it. You could still move up and down, but you couldn't actually rotate the boat. Attachment 20813 If anyone wants to play with this boat on the PC Graal Editor, it was written before the first server wipe, in GScript1, so it still works within the PC Graal Editor. I've attached the files. |
1 Attachment(s)
I forget somewhat my plans for Master Lee, but I got someone to make sprites for him at one point.
Attachment 20826 For some reason he's in the folder with the Trident graphic and gani. |
9 Attachment(s)
Attachment 20843
I created this demo file that you can play with in Graal's level editor. This is a very early --slightly modified-- version of the warp ring script I created, along with associated graphics. It was further built upon as a concept. Of course, there's nowhere to warp, but this provides an example of how you could choose one of many locations to warp to. There was a warp jewel system created that would add/remove locations. I'm not sure if fixed warp locations would work very well on iClassic in regard to lag issues. I also very much liked this as the basis for a type of menu system in general. I'd probably prefer it to a lot of the current menu systems used on Classic right now, particularly if it incorporated click/touch as a shortcut beside arrow key and A/S/D controls. I think hierarchical menus became built-in at some point (i.e. choosing an icon, e.g. for sparring locations, leads to another set of icons). Before the first server wipe, the warp ring wouldn't really give you many options (see present PC Graal the Adventure, after the second server wipe, for example). |
1 Attachment(s)
GC Studio M ftw
Attachment 20849 There would be blocks (graphic was attackblock.png or .gif) over the black squares. Game Coordinators (i.e. you had a whole staff team dedicated to hosting events), could specify the HP of the blocks that you would have to eliminate, or they could be specified as invincible. It was intended as a multi-purpose event room, although it probably would have done better if it was a gmap with more space for combat in a similar layout. Different events held here included CTF, maze races, team PK battles, etc (the Game Coordinators had additional tools). |
I think GCs called it Maze LMS.
|
1 Attachment(s)
|
2004. Has Uncommon Society and Floydia. Can see the sinking ship mini-game west of Big City Volcano, too.
|
| All times are GMT. The time now is 12:42 AM. |
Powered by vBulletin/Copyright ©2000 - 2026, vBulletin Solutions Inc.