Difference between revisions of "The Coding Proposal"

From LegendMUD
Jump to navigation Jump to search
m
(replaces bug tracking with new question)
Line 55: Line 55:
 
## Why?
 
## Why?
 
#* Keep it brief, we are not looking for religious war type argument.
 
#* Keep it brief, we are not looking for religious war type argument.
# What experience do you have with gdb (the GNU debugger)?
+
# What experience do you have with gdb (the GNU debugger)?# 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.)
# Are you comfortable with programming under Linux/Unix?
 
## Have you used makefiles before?
 
## Have you written them?
 
# 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.)
 
 
# 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.
 
# 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.
 
# What effects does changing a function call to a macro have on the performance of the code?
 
# What effects does changing a function call to a macro have on the performance of the code?
Line 112: Line 108:
 
</pre>
 
</pre>
  
=== Bug Tracking ===
+
=== Coding Exercise ===
# 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.
+
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.
<pre>
+
 
void sp_fly(int level, CHAR_DATA * ch, char *argument) {
+
==== Part I: ====
  AFFECT_DATA af;
 
  CHAR_DATA *victim;
 
  OBJ_DATA *obj;
 
  
  obj = NULL;
+
Write a function that does the following:
  if ((victim = get_char_room(ch, argument)) == NULL)
 
    obj = get_obj_here(ch, argument);
 
  
  if (victim == NULL && obj == NULL)
+
* Given the lengths of three sides, determine if the three sides can make a triangle based on their length
    victim = ch;
+
* takes 3 integers as arguments
  else if (victim == NULL)
+
* returns one of the following values (be they enums, integers, whatever):
    return;
+
      TRIANGLE_NONE
 +
      TRIANGLE_EQUILATERAL
 +
      TRIANGLE_ISOSCELES
 +
      TRIANGLE_SCALENE
  
  if (check_magic_sink(ch, victim, SPELL_fly, level))
+
For example:
    return;
 
  
if (!spell_success) {
+
If I were to call this function can_be_triangle(4, 4, 4) It would return the value TRIANGLE_EQUILATERAL
    if (is_casting)
 
      act(spell_fail_message, ch, NULL, NULL, TO_CHAR);
 
    return;
 
  }
 
  
  if (obj != NULL) {
+
==== Part II ====
    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)) {
+
How would you test the above function?
    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))
+
Provide the following:
    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;
+
* sets of numbers you would use as input values (4, 4, 4), (1, 2, 3)
  af.duration = 2 + level / 3;
+
* an estimation of the number of test cases it would take to fully test the function
  af.location = APPLY_NONE;
 
  af.modifier = 0;
 
  af.bitvector = AFF_FLYING;
 
  affect_join(victim, &af);
 
  return;
 
}
 
</pre>
 
  
 
=== Optional ===
 
=== 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).
 
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).

Revision as of 17:58, 4 August 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)?# 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.)
  3. 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.
  4. 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[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)
  • 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).