New system do's and dont's

Claudius

I thought this would be a fun thread for people to kill time and up post count swag on.

Backstory: since returning from work-cation I decided to rebuild a system ground up.

For those who have gone through the arduous task (sometimes multiple times) of building from scratch or even just doing clean ups and revamps, what are the biggest pitfalls or pieces of advice you can give? How do you like organizing your system?

Also, in regards to autocuring what sort of priorities do you use for neutral and vs class specific setups?

And so on and so on.

For those who are or are interested in building a system or reworking your existing one, what questions are useful to you?

Iniar

Rule #1: Don't listen to me.

Shou

Rule #2: REALLY don't listen to Iniar.

edit: Categorize your stuff early on if that's what you'll want to do later. It's a pain to sort everything once it's all set up.

Khizan

#3: We're serious, Iniar is crazy. 

Iniar

Ok, some real opinions from building my own thing.

1. separate things out into different levels of abstraction early

 - this really helped keep things clean and easy to fix

 - I split things into 

(system - version control, general utility functions, options management, multiplayer management, clock management etc), 

(player management - track rebounding, variables, assignment, removal, curing of afflictions etc), 

(personal - this was split into: autocuring, free actions, limb system haha, defences, and classes)

2. autocuring

 - just have to fight to learn some new prios, i'm still learning (kind of, when I can be bothered to fight)

Claudius

Here's a generic tip. KISS. If youre like me, write it in sharpie on the top or bottom frame of your monitor.

Edit: and it's too late for me on the don't listen to iniar. When I started imp I stole all the guts out of the Super old eden file on zedbites and ported it to my client. Every once in awhile I'll dig through it and find weird **** of his lol

Septus

Event driven logic is the big thing that springs to mind that I've found works best over the years.

Given how many different things need to react to the same game events usually, it massively cleans/modularises things up.

Khizan

If you think you'll have to do something more than once, use a function/alias/etc to do it.

This is important because when you want to change how you do that thing, you'll only have to change it in one place. This becomes important when you have, say, 30 different attack aliases that all check your wielded weapon and you want to change how you do that. If you check in a function, you change the function once and you're done. However, if you just copy/pasted that code into 30 different attack aliases, you have to go change each alias separately, and that is awful. 

Claudius

Septus said:

Event driven logic is the big thing that springs to mind that I've found works best over the years.

Given how many different things need to react to the same game events usually, it massively cleans/modularises things up.

What do you mean exactly by event driven? I can guess but I feel like my idea is probably different than your own

Septus

Basically you register objects to a central manager then when you fire an event those that have registered to said manager get notified of the event firing (along with any associated information). Then each thing that registered gets to choose how to handle the event on a case by case basis. I.E. in my case I register a lot to the aff received/lost events, because a lot of different things need to know when that happens (priority switching, enable/disable clotting, warnings, etc).

Basically, it let's you decouple a lot of things so they can just do their own thing rather than mixing in a bunch of calls into various subsystems whenever something happens.

Madrigal

A lot of people complained about the drag in Mudlet's built-in event system but it looks like it's been cleaned up quite a bit since Mudlet 3.0. 

My two cents about system building - 1) Local variables are your friend.  Access time's a hell of a lot quicker and it makes for cleaner code, too.  2) Don't be afraid to break things.  Save a backup copy and have at it. 3) Don't expect to be a beast overnight.  Most of the best players I've seen/read about spent less time in the editor and more time playing the game.

Edit - Oh, and "Embrace ambiguity."  i.e. get really comfortable feeling like an efftard.  If you don't feel like an idiot at least 10% of the time, you're probably not learning anything.