The Book of Softcode Challenges
Welcome to the Book of Softcode Challenges!
The goal of this book is to present a set of projects for softcoding in a graduated order of difficulty/challenge. The idea is that a new softcoder could undertake each of these challenges in order and develop new skills by learning the techniques necessary for doing each.
You can contribute to this book in several ways!
You can write a challenge page, and try to clearly outline a project for a coder to do. Please specify your estimate of the difficulty of this project as:
- Beginner - projects that teach very basic softcode concepts
- Advanced Beginner - projects that someone familiar with concepts but lacking experience should try
- Intermediate - projects that introduce less-common or more powerful functions and coding idioms
- Advanced Intermediate - larger or trickier projects that require coordination of multiple objects
- Expert - complex "systems-level" projects
You can comment on a challenge page to make suggestions to improve it.
You can even post softcode snippets or entire objects that meet the challenge, as examples to others.
Javelin will edit things into their proper order and organization in this book.
Go to it!
- Printer-friendly version
- Login or register to post comments
Click 
Yeah, i could agree to all th
Yeah, i could agree to all that, we should go through the MUSH Manual and pull out everything in it, update it to current codebases, and then re-release it.
The MUSH Manual has some pret
The MUSH Manual has some pretty strong licensing on it, which anyone planning to copy bits from should read carefully first. (I doubt it'd be much of an issue these days, but it never hurts to be careful.) Wouldn't be a bad idea to at least read through it to get some ideas, though. I know some of the examples are obsolete - IIRC there's a softcoded 'follow' command, which Penn obviously now has hardcoded - but there're still a lot of things people could learn from.
Advanced Coding Philosophy, an Example
Let us begin with a few assumptions.
First, let us assume we're developing some system level package (econ systems seem to be popularly recurring system level challenges, so we'll roll with that idea for now), such as "Penny MUSH".
Next, let us assume (per the premise of this website) that we're developing it for Pennmush (ala the pun above).
And further, let us assume our package develops a userbase and begins to become popular (joining the ranks of Myrddin's Bboard, Keran's Weather, et al).
Popularity growth on one platform (Pennmush), inevitably results in requests for ports to other platforms, either by word of mouth praise/advertising, or by those who want to convert their game to some other platform (not that we'd encourage people to leave Penn, but...).
Thus, I am of the opinion that, at some level in this "Big Book" (one or more of the most advanced levels), multi-platform compatibility issues should be included as a supplemental challenge to whatever else the proposed challenge may contain; or, perhaps be included by default as a condition for that "level". For example the 'advanced' level challenges could have 'make the resulting code work in both Penn and PlatformX' as a supplemental exercise; and, the 'expert' level could imply it as a required feature (what's the point in calling oneself an 'expert' if one is not considerate of the broader MU-community?).
Furthermore, having one's softcode be multi-platform compatible makes it easier for people to migrate TO Penn (as opposed to the earlier notion of migrating the other direction). And, the more such packages that exist, the more chance Penn has of being on the destination end of a migration (per above).
This, then, also implies that some of the exercises could be to 'migrate packageA from platformX to Penn without breaking it on platformX'. (licensing issues will apply, of course, so be prepared to submit the result as a 'patch' to the original developers or whatever)
@function library - a group project
Yesterday on M*U*S*H there was discussion of ways to streamline softcode i/o issues. That is... somehow make it simpler for people to do common softcode input errorchecking so they can spend more time on other softcode needs of their project(s). My proposed final suggestion for this was that of making a library of softcoded @functions as an add-on package for Pennmush, pointing to the WARPEDcore Manifesto where I had already laid out a philosophical framework for doing such a thing (note: hyperlink is to archive.org, so may be slow; later, as I start adding more to my blog thread, I may also deal with finding a better home for these files).
This morning I had the notion to place this idea here as a softcode group challenge. That is... to start a thread here where people could actually contribute such code pieces. Others could offer suggestions for improvement, blah blah blah... and hopefully end up with something real and tangible fore people to use.
It is important to note that good softcode documentation will be vital to this project (ala Eratl's contributions here, as well as those philosophical tenets in the WARPEDcore).
Okay... now... to get the ball rolling I'm going to offer a piece of poorly written, incomplete, nonfunctional softcode. The FIRST assignment of this group challenge will be to add replies to THAT subthread until it is refined and ready to use (for this first example, a competent coder can probably do most of the work in one reply, with very few 'tweak' posts thereafter).
The purpose of this FIRST assignment is to lay out the framework for others to follow, via realtime example; and, further, to illustrate that contributions don't need to be brilliant, powerful, or even operational. If you have an idea for a @function, can describe it well, and can offer a piece of crudely fashioned softcode to illustrate it, then you have a contribution!
Roll up your sleeves gang, this MIGHT turn into a real challenge!
.pmatch()
This is my proposed 'dot-pmatch' function (see the Manifesto, referenced in the parent of this post). The idea is to simplify one piece of errorchecking to a standardized output. Although this particular example may end up being useless to many games, the purpose of doing it is still valid and important (i.e., let's screw it up here, then fix it here, before we go on to other more useful/important contributions).
This contribution (in the form of an idea, illustrated by incomplete and non-functional softcode) is intended to make player-match errorchecking easier... by offering a standardized 'display-ready' output. Here's my code (notice it's not even a @function yet; that remains to be done)...
The result of this exercise should be a function with the following syntax:
which returns the result of something like this:
switch( pmatch(%0), #-1,No such player as '%0'., #-2,I don't know which '%0' you mean., #$ )making it easier for someone to get to the meat of their process such as...
On your mark, get set, ...
Vehicles
Although I haven't seen them used too often lately, vehicles used to be a fairly popular thing to code.
In their most basic form, they just show messages to players both inside and outside whenever someone enters/exits the vehicle, along with a 'drive' command that can make the vehicle move.
To make it slightly more advanced, you could add a 'take wheel' command which sets a certain player as the driver; only that player can 'drive' the vehicle. You can also lock it so that only a certain number of people can get in (5 for a car, 2 for a motorbike, etc).
Housekeeping...
This challenge suggestion (roughly drafted here) is intended for the 'cleanup' of semi-private areas -- i.e., personally owned rooms where you sometimes invite guests, but don't want them camping out.
read about drop-to (help drop-to), sticky, home, etc.
Make players/puppets/things go home when the room isn't in use (i.e., please take your pet rock home with you after the party.)
Make the room 'spill proof' (can't drop anything, preventing the necessity of a cleanup of other peoples THINGs - i.e., I must insist that you keep your pet rock in your pocket)
Make allowances for your own things (darned maid service! my 72 inch holographic 3-D theater system with surround sound STAYS, I say!).
Presently uncertain if this is best served as a sequence of challenges or not (e.g., one 'beginner' with tweaks and one 'advanced beginner' with tweaks, or just one advanced beginner with all the tweaks); willing to defer at this point.
Advanced Evaluation Lock
I had to code this one just a few days ago (thanks Mike!) and it was somewhat tricky. It requires two separate PLAYERs to test.
Code a link-lock (@lock/link) on a ROOM so that only other ROOMs can be linked to it (for drop-to cleanups). There may be an easier way to do this than how I did mine; so if you find a quick-and-dirty way, maybe post it here in a comment below the page. (you always pass your own link-locks automatically, so you can't test this with the owner of the room)
Category guess: Advanced Intermediate (just a guess - if it turns out to be an easy challenge, downgrade it I guess).
Doesn't @lock/link here=type^
Doesn't @lock/link here=type^room work for that?
That doesn't work, unfortunat
That doesn't work, unfortunately - it restricts it so only a room can issue the @link command, rather than restricting so that only a room can be linked.
Intermediate Softcode Challenge
Difficulty: Intermediate
&Number`1 Display=One|Ichi|Uno|Un|Eins
&Number`2 Display=Two|Ni|Dos|Duex|Zwei
&Number`3 Display=Three|San|Tres|Trios|Drei
&Number`4 Display=Four|Yon|Cuatro|Quatre|Vier
&Number`5 Display=Five|Go|Cinco|Cinq|fünf
&Number`6 Display=Six|Roku|Seis|Six|sechs
&Number`7 Display=Seven|Nana|Siete|Sept|sieben
&Number`8 Display=Eight|Hachi|Ocho|Huit|acht
&Number`9 Display=Nine|Kyuu|Nueve|Neuf|neun
&Number`10 Display=Ten|Juu|Diez|Dix|zehn
Write a function such that:
think u(Display/line,Number`1)
Yields:
(Only English(1st), Spanish(3rd), and German(5th))
In red, green, and blue, respectively.
Requirement: Write the ufun() so that it uses only -eight- function invocations to extract and justify the attributes like this.
Fewest Invocations, a cross-medium challenge?
After having had some time for this challenge to ferment, I've got a suggestion.
Make a book page, in the "Advanced Intermediate" or "Expert" categories (I'll defer to Jav on this, but if I had to choose, I'd say Expert). This page will, itself, have sub-pages beneath it, each of which can contain an individual 'efficiency' challenge, similar to this one (i.e., fewest number of invocations to accomplish <task foo>). When someone writes a unique version of the 'fewest invocations' (i.e., I wrote a version which only use <#> invocations. And it's different than <so-and-so>'s, which uses the same number), the solution could be placed on an object on M*U*S*H for viewing (I suggest this as an alternative to posting all the answers to all the challenges here).
Anyway... that's my constructive suggestion for this challenge (and others of its type).
And here's my token offering of a specific challenge in this same category -
Write a user-defined function (UFUN) which will, using the fewest possible invocations, swap the contents of two attributes.
For example: obj/va contains a '1' and obj/vb contains a '2', write a ufun which will put the 2 in va and the 1 in vb, using the fewest possible invocations.
(NOTE: the solution to this is actually very useful in a few unique places and I always forget I can do it ... also works well with %q-registers).
... and to all a good night!
Advanced Beginner challenge
Code a game of Tic-Tac-Toe.
Hint: There are only 8 ways to win a game of Tic-Tac-Toe: Three vertical, three horizontal, and two diagonals. Don't over-complicate it.