Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   PlayerWorlds Main Forum (https://forums.graalonline.com/forums/forumdisplay.php?f=15)
-   -   The Process of Scripting? (https://forums.graalonline.com/forums/showthread.php?t=134258338)

Cubical 03-11-2010 05:27 AM

The Process of Scripting?
 
Every time I have started working on creating a server I have always started just making systems/scripts but I never did it in any particular order so nothing really fit right. I would always get to the point where I would say to myself 'How can I incorporate this with that.' and I would just get stumped and frustrated and either start all over or just give up. Here's what my question is; What process do you use when creating a server, by this I mean what do you make first then move on to making.
Quote:

Movement->
GUIs->
Item Database->
Health/Damage->
Hit Detection->
Item Creation->
ect
I would really like to know the actual process in creating a successfully running server so I don't keep making the same mistakes. I have the Ideas I just don't know what order to create them in. I'm sure this will end up helping other players as well.

Switch 03-11-2010 05:32 AM

Really it depends on the type of server you're going for.

Cubical 03-11-2010 05:44 AM

Could I have examples of modern and rpg?

WhiteDragon 03-11-2010 06:09 AM

It doesn't sound like you are having an issue with what order to create them in, but rather how modules should interact with one another. A bad plan in terms of module interaction would lead to that feeling of things not fitting right.


How I think about the flow of my scripts is via. input and output, in their abstract senses. For example, input could be normal mouse/keyboard input, as well as input from the the server (triggerclients, detecting attr changes).

Then, there would be some logic that combines different types of inputs, and eventually calls a function to ouput. Output would entail sending something back to the server, or to show an image, or to move the player.


Within both the input and output modules I would likely have further submodules, but keeping the overall seperation helps very much in overall design.

fowlplay4 03-11-2010 08:07 AM

You work on the most critical aspect before you can move on to other systems, this is typically the MUDLib/Item System/Player Statistics as the starting point, then the systems underneath it (Damage, Movement, Equipment, Attack/Magic).

It doesn't hurt to work on prototypes of your HUD and other GUIs when you're working on the Statistics/MUDLib.

This is by far the easiest part of creating a server though it's content that's a pain.

Elk 03-11-2010 12:37 PM

Do a mindmap...and order it according to its importance

Cubical 03-11-2010 12:42 PM

Quote:

Originally Posted by Elk (Post 1561819)
Do a mindmap...and order it according to its importance

Everything is important it's just things need other things in order to work.

Elk 03-11-2010 01:43 PM

Nah...first you need to plan the overall stuff and get to the inside as you progress...say, into detail

cbk1994 03-11-2010 01:49 PM

The hardest part is planning. When designing a server, think of all of the systems as one system since they will act together, and think up everything it will need to do, and leave room for it to do more things in the future (modularity)

xAndrewx 03-13-2010 12:00 AM

Quote:

Originally Posted by cbk1994 (Post 1561829)
The hardest part is planning. When designing a server, think of all of the systems as one system since they will act together, and think up everything it will need to do, and leave room for it to do more things in the future (modularity)


I think you're right, I generally create the weapons that involve around the player behind the scenes, then I create another weapon to display this information to the screen. The hardest part is thinking of the functions that you'll need.

An example would be creating a weapon called "-Items" which every function inside this weapon would revolve around items (dropping, adding etc) and then another weapon such as the "Inventory" or "Trading" which would just call the functions from "-Items" to display the information.

Cubical 03-16-2010 06:00 AM

Quote:

Originally Posted by xAndrewx (Post 1562119)
I think you're right, I generally create the weapons that involve around the player behind the scenes, then I create another weapon to display this information to the screen. The hardest part is thinking of the functions that you'll need.

An example would be creating a weapon called "-Items" which every function inside this weapon would revolve around items (dropping, adding etc) and then another weapon such as the "Inventory" or "Trading" which would just call the functions from "-Items" to display the information.

what's the advantage to creating a weapon called "-Items" over joining the player to a class?

DustyPorViva 03-16-2010 06:55 AM

1) Browse code gallery.
2) Browse collection of scripts I have gathered over time.
3) Copy.
4) Paste.
5) ???
6) Profit!

xAndrewx 03-16-2010 08:51 AM

Quote:

Originally Posted by Cubical (Post 1562858)
what's the advantage to creating a weapon called "-Items" over joining the player to a class?

Clientside functions ^^

HTML Code:

(@ "-Items").onDropItem(id, amount);
(@ "-Items").onGetItemCount();
(@ "-Items").onGetItemQuantity(id);


DustyPorViva 03-16-2010 08:56 AM

Quote:

Originally Posted by xAndrewx (Post 1562872)
Clientside functions ^^

HTML Code:

(@ "-Items").onDropItem(id, amount);
(@ "-Items").onGetItemCount();
(@ "-Items").onGetItemQuantity(id);


You can actually rename the object name of the WNPC in the weapon script so you can access it by a more... simpler name, instead of doing (@ "-Items"). I think it's name = "Items";... that could be wrong, though.

Also, player-joined classes have clientside functions if you put clientside functions in the class, lol. Just remember though, pretty sure all class-functions joined to a player are accessed by player.function, thus I tend to add functions that represent actions to a player(player.damage()), while putting item-related functions in a WNPC that is appropriately named(items.createitem()), as it would look odd for say, player.createitem().

Cubical 03-16-2010 09:39 AM

So the only real pitfall is pretty much personal preference?

xAndrewx 03-16-2010 09:39 AM

Quote:

Originally Posted by DustyPorViva (Post 1562873)
You can actually rename the object name of the WNPC in the weapon script so you can access it by a more... simpler name, instead of doing (@ "-Items"). I think it's name = "Items";... that could be wrong, though.

Also, player-joined classes have clientside functions if you put clientside functions in the class, lol. Just remember though, pretty sure all class-functions joined to a player are accessed by player.function, thus I tend to add functions that represent actions to a player(player.damage()), while putting item-related functions in a WNPC that is appropriately named(items.createitem()), as it would look odd for say, player.createitem().

Oh I didn't know about the player.joined classes had a clientside effect, thank you =D

cbk1994 03-16-2010 01:07 PM

Weapons are usually preferable since they don't have a few problems player classes on clientside have:
  • They lag behind when logging on since you have to join them clientside in an onCreated function on a weapon. This means you have to delay other scripts until the class loads.
  • They are notoriously hard to update. Often I have to restart my client, and sometimes the NPC-server, to make simple changes.

You will need to join the class to the player on clientside for the clientside portion to work.

Quote:

Originally Posted by DustyPorViva (Post 1562873)
You can actually rename the object name of the WNPC in the weapon script so you can access it by a more... simpler name, instead of doing (@ "-Items"). I think it's name = "Items";... that could be wrong, though.

PHP Code:

itemControl this



All times are GMT +2. The time now is 12:06 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.