Difference between revisions of "The Coding Proposal"

From LegendMUD
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
===LONG TERM DEPARTMENTAL GOALS===
+
= Preface =
To get the mud code in good enough shape to release publicly as a code base for other muds. To make it flexible, efficient, stable, expandable, and configurable.
+
Before continuing, ensure that you have read and follow [[The Immortal Proposal Process]].
*fix all memory bugs
 
*identify and fix bugs in the code
 
*fully comment all code
 
*a working mud economy
 
*capability to run on as many different platforms as possible
 
*better area file reader that is more flexible and has less cryptic error messages
 
*return the mud to the cutting edge of server design
 
  
----
+
Coders on Legend are responsible for the maintenance of the current server code for the mud and the addition of new features. All coders are expected to maintain and fix minor bugs and typos as well as comment code where possible. Full coders are expected to implement and support larger projects.
  
===I. Becoming a Coder===
+
= Basic Information on the Mud Base =
 +
Much of the invisible stuff that keeps Legend running has been redone from the original diku/merc base. One of the driving philosophies behind much of the coding that has gone into Legend is to make it a game for all types of players. It's not strictly one type of mud. It is not just for role players, it is not just for hack-n-slashers, it is not just for pkillers, etc.
 +
In any case, the thing to keep in mind is that configurability and customizability of the code base implies that code design needs to be modular, APIs and interfaces to it need to be simple and clean, and all associated data files and the like need to be intuitive, flexible, and easy to use. The code is currently all in C.
  
A. What Do Coders Do?
+
= The Coding Proposal =
Coders on LegendMUD are responsible for the maintenance of the current server code for the mud and the addition of new features. All coders are expected to maintain and fix minor bugs and typos as well as comment code where possible. Full coders are expected to implement and support larger projects.
 
B. Basic Information on the Mud Base
 
Much of the invisible stuff that keeps Legend running has been redone from it's original diku/merc base. One of the driving philosophies behind much of the coding that has gone into LegendMUD is to make it a game for all types of players. It's not strictly one type of mud. It's not just for role players, it's not just for hack-n-slashers, it's not just for pkillers, etc.
 
In any case, the thing to keep in mind is that configurability and customizability of the code base (as well as the ability to run it as various differing types of environment) imply that code design needs to be modular, APIs and interfaces to it need to be simple and clean, and all associated data files and the like need to be intuitive, flexible, and easy to use. The code is currently all in C.
 
 
 
----
 
 
 
===II. The Coding Proposal===
 
 
Remember that your proposal is voted on by coders and non-coders alike. It is your job to make sure that both coders and non-coders can understand your answers and can get a good enough sense of your skills, sense of balance, and style to make an informed decision when voting on your application.
 
Remember that your proposal is voted on by coders and non-coders alike. It is your job to make sure that both coders and non-coders can understand your answers and can get a good enough sense of your skills, sense of balance, and style to make an informed decision when voting on your application.
Make sure that your application is legibly formatted (Ascii text) and coherently written.
 
  
----
+
Make sure that your application is legibly formatted and coherently written. Submit answers to the following sections.
  
===Part 1: General Knowledge===
+
== General Knowledge ==
What programming languages do you have experience with? How much experience in each?
+
# What programming languages do you have experience with?
Currently, all mud development is done under Unix. While this will probably change in the future, there are no plans to change it in the short term. What experience do you have with Unix?
+
## How much experience in each?
Do you have access to a Unix machine where you can develop and compile software? (Does it have cvs, gcc, gnu make?) Can you use it to test code changes? Many ISPs, while having programming tools, get upset if you run your own daemons, even for short periods of time. What version of Unix does it run? While it is possible to do all of your development work on the Mud machine, we try to do as much as possible on other machines.
+
# Currently, all mud development is done under Linux/Unix. While this may change in the future, there are no plans to change it in the short term. What experience do you have with Linux/Unix?
Have you ever done any programming on a large project before? What? How many programmers were there? What did the program do? Have you ever coded on a MUD or any other type of game before?
+
# Do you have access to a Linux/Unix machine where you can develop and compile software?
 +
#* If so:
 +
## Does it have git, gcc, gnu make?
 +
## Can you use it to test code changes?
 +
## What version of Linux/Unix does it run?
 +
# Have you ever done any programming on a large project before?
 +
#* If so:
 +
## What?
 +
## How many programmers were there?
 +
## What did the program do?
 +
# Have you ever coded on a MUD or any other type of game before?
  
----
+
== Design and Miscellaneous Questions ==
 +
# Describe a coding project that you would like to undertake. (Examples might include a new skill or spell, automatic description generation at character creation time, or something else). Include details about implementation, but also game balance issues.
 +
# Seemingly out of nowhere, players start complaining loudly about something that you know is low down on the coder priority list. You're pretty sure that you know how to make the change players want, but your own project, though longer, is a higher priority. Would you stop work on your own project to go make this change?
 +
# Design the skill. Write up a design spec for three of the following skills, remembering that the design spec will be read and evaluated by both coders and non-coders. Your ideas should provide for interesting, flexible skills without being out of bounds (the mud isn't based around any one skill or set of skills).
 +
#* Autopsy
 +
#* Embroidery
 +
#* Falconry
 +
#* Hiking
 +
#* Hunt
 +
#* Locate Herb
 +
#* Make Pills
 +
#* Smelting
 +
#* Speed Draw
 +
#* Tackle
 +
#* Tailor
 +
#* Vanish
 +
# A player reports that after calming a mob they were killed by it in combat. They report this as a bug and ask for a reimbursement. You talk to the head PR who tells you that a reimbursement is fair if there is a bug. What do you do?
 +
## What steps do you take to try to track down the bug?
 +
# Write a new question (and give an answer to it) that you think would be a useful addition to the Coder proposal questions.
  
===Part 2: Design and Miscellaneous Questions===
+
== Coding Questions ==
Describe a coding project that you would like to undertake. (Examples might include a new skill or spell, automatic description generation at character creation time, or something else). Include details about implementation, but also game balance issues.
+
Not having experience with particular tools is not necessarily a problem. Many of the questions are asked so that when/if you become an immortal we have a better idea of your experience level and which tools you are comfortable with.
  
Seemingly out of nowhere, players start complaining loudly about something that you know is low down on the coder priority list. You're pretty sure that you know how to make the change players want, but your own project, though longer, is a higher priority. Would you stop work on your own project to go make this change?
+
# What is your favorite programming language?
 
+
## Why?
Design the skill. Write up a design spec for three of the following skills, remembering that the design spec will be read and evaluated by both coders and non-coders. Your ideas should provide for interesting, flexible skills without being out of bounds (the mud isn't based around any one skill or set of skills).
+
#* Keep it brief, we are not looking for religious war type argument.
 
+
# What experience do you have with gdb (the GNU debugger)?
Locate Herb Hiking Falconry
+
# What are the advantages and disadvantages of storing the object database as an array of OBJ_TYPE? As a linked list of OBJ_TYPE? (OBJ_TYPE is the struct used for objects.)
Hunt Tackle Vanish
+
# Explain how you would implement the three skills that you selected above. Include details about the data structures and algorithms that you plan on using, explain how the code would work, etc. We realize that you don't have much information about how the code is designed, but do your best without this information.
Tailor Smelting Autopsy
+
# What effects does changing a function call to a macro have on the performance of the code?
Speed Draw Embroidery Make Pills
+
#* What are the advantages to using a function call instead of a macro, and vice versa?
 
 
A player reports that after calming a mob they were killed by it in combat. They report this as a bug and ask for a reimbursement. You talk to the head admin who tells you that a reimbursement is fair if there's a bug. What do you do? What steps do you take to try to track down the bug?
 
 
 
Write a new question (and give an answer to it) that you think would be a useful addition to the Coder proposal questions.
 
 
 
----
 
 
 
===Part 3: Coding Questions===
 
  
 +
=== Code Commenting ===
 +
# Comment the following code as you would normally comment code:
 
<pre>
 
<pre>
 
Not having experience with particular tools is not necessarily a problem. Many of the questions are asked so that when/if you become an immortal we have a better idea of your experience level and which tools you are comfortable with.
 
 
What's your favorite programming language? Why? (Keep it brief, we're not interested in a religious war type argument.)
 
 
What experience do you have with gdb (the GNU debugger)?
 
 
Are you comfortable with programming under Unix? Have you used makefiles before? Have you written them?
 
Comment the following code as you would normally comment code:
 
 
 
char *
 
char *
 
multi_check (char *argument, int *numtimes) {
 
multi_check (char *argument, int *numtimes) {
Line 109: Line 107:
 
   return argument;
 
   return argument;
 
}
 
}
 +
</pre>
  
What are the advantages and disadvantages of storing the object database as an array of OBJ_TYPE? As a linked list of OBJ_TYPE? (OBJ_TYPE is the struct used for objects.)
+
=== Coding Exercise: Triangle ===
 
+
Coding question... you may use any language with which you feel comfortable, however during part 2, assume that the function you are testing is in a strongly typed language.
Implement the skill. Explain how you would implement the three skills that you selected in part 2 above. Include details about the data structures and algorithms that you plan on using, explain how the code would work, etc. We realize that you don't have much information about how the code is designed, but do your best without this information.
 
 
 
The following bug was reported: "I was wearing a birdshape, and suddenly stopped flying without removing the shape." After a bit of investigation, you find that the bug was because the player had quaffed a fly potion and when the potion effects wore off, the fly from the birdshape wore off as well. Here is the code for the fly spell. Fix the bug. If you can't find the specific bug, explain the steps that you would go through to try to find the bug.
 
 
 
void sp_fly(int level, CHAR_DATA * ch, char *argument) {
 
  AFFECT_DATA af;
 
  CHAR_DATA *victim;
 
  OBJ_DATA *obj;
 
 
 
  obj = NULL;
 
  if ((victim = get_char_room(ch, argument)) == NULL)
 
    obj = get_obj_here(ch, argument);
 
  
  if (victim == NULL && obj == NULL)
+
==== Part I: ====
    victim = ch;
 
  else if (victim == NULL)
 
    return;
 
  
  if (check_magic_sink(ch, victim, SPELL_fly, level))
+
Write a function that does the following:
    return;
 
  
if (!spell_success) {
+
* Given the lengths of three sides, determine if the three sides can make a triangle based on their length
    if (is_casting)
+
* takes 3 integers as arguments
      act(spell_fail_message, ch, NULL, NULL, TO_CHAR);
+
* returns one of the following values (be they enums, integers, whatever):
    return;
+
      TRIANGLE_NONE
  }
+
      TRIANGLE_EQUILATERAL
 +
      TRIANGLE_ISOSCELES
 +
      TRIANGLE_SCALENE
  
  if (obj != NULL) {
+
For example:
    act("$p hovers briefly and falls back into place.", ch, obj, NULL, TO_CHAR);
 
    act("$p hovers briefly and falls back into place.", ch, obj, NULL, TO_ROOM);
 
    return;
 
  }
 
  
  if (is_affected(victim, SPELL_stoneskin)) {
+
If I were to call this function can_be_triangle(4, 4, 4) It would return the value TRIANGLE_EQUILATERAL
    send_to_char("You cannot lift someone from the ground if their skin is of stone.\n\r", ch);
 
    return;
 
  }
 
  
  if (!IS_SET(victim->affected_by, AFF_FLYING))
+
==== Part II ====
    act("Your feet float up off the ground.", victim, NULL, NULL, TO_CHAR);
 
  else
 
    act("Nothing seems to happen.", victim, NULL, NULL, TO_CHAR);
 
  
  af.type = SPELL_fly;
+
How would you test the above function?
  af.duration = 2 + level / 3;
 
  af.location = APPLY_NONE;
 
  af.modifier = 0;
 
  af.bitvector = AFF_FLYING;
 
  affect_join(victim, &af);
 
  return;
 
}
 
  
</pre>
+
Provide the following:
  
What effects does changing a function call to a macro have on the performance of the code? What are the advantages to using a function call instead of a macro, and vice versa?
+
* sets of numbers you would use as input values (4, 4, 4), (1, 2, 3) and their associated expected outcomes
(Optional) Show us some code that you've written. Anything at all. It can be any size 10 lines, 100 lines, whatever. (Well, try to keep it on the smaller side of things, we don't have time to look at thousands of lines of code).
+
* an estimation of the number of test cases it would take to fully test the function
  
Please feel free to ask us any questions on-line. Or, send e-mail to Rufus.
+
=== Optional ===
 +
Show us some code that you've written. Anything at all. It can be any size 10 lines, 100 lines, whatever. (Well, try to keep it on the smaller side of things, we don't have time to look at thousands of lines of code).

Latest revision as of 09:15, 22 September 2020

Preface[edit]

Before continuing, ensure that you have read and follow The Immortal Proposal Process.

Coders on Legend are responsible for the maintenance of the current server code for the mud and the addition of new features. All coders are expected to maintain and fix minor bugs and typos as well as comment code where possible. Full coders are expected to implement and support larger projects.

Basic Information on the Mud Base[edit]

Much of the invisible stuff that keeps Legend running has been redone from the original diku/merc base. One of the driving philosophies behind much of the coding that has gone into Legend is to make it a game for all types of players. It's not strictly one type of mud. It is not just for role players, it is not just for hack-n-slashers, it is not just for pkillers, etc. In any case, the thing to keep in mind is that configurability and customizability of the code base implies that code design needs to be modular, APIs and interfaces to it need to be simple and clean, and all associated data files and the like need to be intuitive, flexible, and easy to use. The code is currently all in C.

The Coding Proposal[edit]

Remember that your proposal is voted on by coders and non-coders alike. It is your job to make sure that both coders and non-coders can understand your answers and can get a good enough sense of your skills, sense of balance, and style to make an informed decision when voting on your application.

Make sure that your application is legibly formatted and coherently written. Submit answers to the following sections.

General Knowledge[edit]

  1. What programming languages do you have experience with?
    1. How much experience in each?
  2. Currently, all mud development is done under Linux/Unix. While this may change in the future, there are no plans to change it in the short term. What experience do you have with Linux/Unix?
  3. Do you have access to a Linux/Unix machine where you can develop and compile software?
    • If so:
    1. Does it have git, gcc, gnu make?
    2. Can you use it to test code changes?
    3. What version of Linux/Unix does it run?
  4. Have you ever done any programming on a large project before?
    • If so:
    1. What?
    2. How many programmers were there?
    3. What did the program do?
  5. Have you ever coded on a MUD or any other type of game before?

Design and Miscellaneous Questions[edit]

  1. Describe a coding project that you would like to undertake. (Examples might include a new skill or spell, automatic description generation at character creation time, or something else). Include details about implementation, but also game balance issues.
  2. Seemingly out of nowhere, players start complaining loudly about something that you know is low down on the coder priority list. You're pretty sure that you know how to make the change players want, but your own project, though longer, is a higher priority. Would you stop work on your own project to go make this change?
  3. Design the skill. Write up a design spec for three of the following skills, remembering that the design spec will be read and evaluated by both coders and non-coders. Your ideas should provide for interesting, flexible skills without being out of bounds (the mud isn't based around any one skill or set of skills).
    • Autopsy
    • Embroidery
    • Falconry
    • Hiking
    • Hunt
    • Locate Herb
    • Make Pills
    • Smelting
    • Speed Draw
    • Tackle
    • Tailor
    • Vanish
  4. A player reports that after calming a mob they were killed by it in combat. They report this as a bug and ask for a reimbursement. You talk to the head PR who tells you that a reimbursement is fair if there is a bug. What do you do?
    1. What steps do you take to try to track down the bug?
  5. Write a new question (and give an answer to it) that you think would be a useful addition to the Coder proposal questions.

Coding Questions[edit]

Not having experience with particular tools is not necessarily a problem. Many of the questions are asked so that when/if you become an immortal we have a better idea of your experience level and which tools you are comfortable with.

  1. What is your favorite programming language?
    1. Why?
    • Keep it brief, we are not looking for religious war type argument.
  2. What experience do you have with gdb (the GNU debugger)?
  3. What are the advantages and disadvantages of storing the object database as an array of OBJ_TYPE? As a linked list of OBJ_TYPE? (OBJ_TYPE is the struct used for objects.)
  4. Explain how you would implement the three skills that you selected above. Include details about the data structures and algorithms that you plan on using, explain how the code would work, etc. We realize that you don't have much information about how the code is designed, but do your best without this information.
  5. What effects does changing a function call to a macro have on the performance of the code?
    • What are the advantages to using a function call instead of a macro, and vice versa?

Code Commenting[edit]

  1. Comment the following code as you would normally comment code:
char *
multi_check (char *argument, int *numtimes) {
char *arg_ptr;
char *temp_ptr;
int temptimes;

icheckptr(numtimes,argument);
if (argument == NULL) {
  /* special handling for null argument pointer so that we can
     set numtimes to zero so that whatever it is that called 
     multi_check will, god willing, not use the returned null pointer */
  _checkptr("argument",__FILE__,__LINE__);
  *numtimes=0;
  return NULL;
}

*numtimes = 1;

while (isspace (*argument))
  argument++;

if (*argument == '\0')
  return argument;
for (arg_ptr = argument; *arg_ptr != '\0'; arg_ptr++)
  if (isdigit (*arg_ptr) && (arg_ptr == argument || *(arg_ptr - 1) == ' ')) {
    temptimes = MAX (1, MIN (atoi (arg_ptr), 30));
    temp_ptr = arg_ptr;
    while (isdigit (*temp_ptr))
      temp_ptr++;
    if (*temp_ptr == '*') {
      while (*(++temp_ptr) != '\0')
        *arg_ptr++ = *temp_ptr;
      *arg_ptr = '\0';
      *numtimes = temptimes;
      break;
    }
  }

  while (isspace (*argument))
  argument++;

  return argument;
}

Coding Exercise: Triangle[edit]

Coding question... you may use any language with which you feel comfortable, however during part 2, assume that the function you are testing is in a strongly typed language.

Part I:[edit]

Write a function that does the following:

  • Given the lengths of three sides, determine if the three sides can make a triangle based on their length
  • takes 3 integers as arguments
  • returns one of the following values (be they enums, integers, whatever):
     TRIANGLE_NONE
     TRIANGLE_EQUILATERAL
     TRIANGLE_ISOSCELES
     TRIANGLE_SCALENE

For example:

If I were to call this function can_be_triangle(4, 4, 4) It would return the value TRIANGLE_EQUILATERAL

Part II[edit]

How would you test the above function?

Provide the following:

  • sets of numbers you would use as input values (4, 4, 4), (1, 2, 3) and their associated expected outcomes
  • an estimation of the number of test cases it would take to fully test the function

Optional[edit]

Show us some code that you've written. Anything at all. It can be any size 10 lines, 100 lines, whatever. (Well, try to keep it on the smaller side of things, we don't have time to look at thousands of lines of code).