The Process of Scripting?

[Cubical]

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.

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]

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

[Cubical]

Could I have examples of modern and rpg?

[WhiteDragon]

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]

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]

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

[Cubical]

Originally Posted by Elk

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]

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

[cbk1994]

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]

Originally Posted by cbk1994

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]

Originally Posted by xAndrewx

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]

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

[xAndrewx]

Originally Posted by Cubical

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

Clientside functions

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

[DustyPorViva]

Originally Posted by xAndrewx

Clientside functions

(@ "-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]

So the only real pitfall is pretty much personal preference?