Roguelikes

I keep threatening to post about the additional research I've been doing, but I'm so wrapped up in reading about it that I have yet to actually write a post.

That, and work has been a little harrowing. Everyone has wanted their projects completed by Friday this week, which crunches our schedule into a "drop-everything-else-that-was-not-immediate-and-do-this" nightmare. When it's one out of every ten jobs, this isn't an issue; but when it's six out of ten orders, it gets hairy.

Enough about boring work.

The title of this post may have gotten some attention already. Either you are wondering why I would stick those two words together in such a bizarre way, or you are wondering what it was that I found pertaining to this particular style of game (default: neither of these things, just get on with your point).

Roguelikes are a type of game that is based on the 1980's text-game Rogue. They encompass game features such as procedural map generation, turn-based gameplay, and sometimes permanent character death. More information can be found here (Wikipedia) and a basic chronology of roguelikes can be found here (also Wikipedia).

Anyone who has been around this blog for a while knows that I'm enamored with the design of MUDs. Roguelikes began in 1978 with the release of Beneath Apple Manor, the same year that MUD1 was released in England. Both styles of game have their own appeal, though MUDs are by far more intensive as far as content generation goes. I assume that part of what makes roguelikes so popular is the lack of a need for so much manual content generation. The maps of the earliest roguelikes were made up of text characters, as shown below.

Source: http://www.kathekonta.com/rlguide/index.html, which will be mentioned shortly in detail

The classification of roguelikes gets a little bit convoluted, considering there are a large amount of games out there that share some of the same qualities, but not quite all of them. Some argue that Blizzard's Diablo is a roguelike, and others say otherwise, and there are many other cases like this. But these games led to a genre of dungeon-crawling games, of which the goal is simply to traverse the generated maps, find all the goodies, and kill all the bad guys.

I was having a lot of fun doing my research about roguelikes. Somewhere in the midst of it, and I don't know what inspired me to do it, but I typed "how to program a roguelike" into Google.

I have been thrilled with the results.

First, I have to shout super kudos to my first resource. This guy took personal time to write, very candidly, a step-by-step process of programming a roguelike. And the advice he offers in this guide is not specific to roguelikes; it is advice from a professional in the field who is imparting some hard-learned lessons from his experience in software development. I think I find that equally as impressive as the time he has spent writing the guide.

Beginner's Guide to Roguelikes in C/C++

The guide is not complete, partially because of some issues in his platform (look on his blog for more information). Regardless, the 9 articles he has completed are packed with great information about developing a roguelike (or any program) with good structure and clarity.

I also found this article on RogueBasin, a wiki page dedicated to the roguelike genre. It does not go into anywhere near as much detail as the Beginner's Guide does, but it covers some really great points and gives something akin to a checklist for anyone planning to develop a roguelike. I enjoyed some of the considerations mentioned.

How to Write a Roguelike in 15 Steps

Of course, I have to post Archive.org's MS-DOS library. I think it is so neat that they have so many old games available to stream on their browser emulator. Here is a link to a playable version of Beneath Apple Manor, if anyone is interested in traveling back in time.


That about does it for me for today. I want to dive back into my programming exercises in the next couple of days, so hopefully I will have some progress to write about thereafter.

EXCITE

I got it to work!!!!!!

All I had to do was change the variable being tested for zero value, and the location of the test!!! I had designed it one way at first, and then changed a few variables around and forgotten to change that one very important detail.

The more I think about it, the more this program is probably extremely hackish. The whole point of the project was to create a program that would take a whole, non-negative, non-zero number and repeat it back in reverse order.

In the book, my hint was to use a do loop to continuously divide the input by 10 until it reached 0. That was fine and all, but every time it divided by 10, it would give me answers like 9876, 987, 98, 9. If I only used modulo to get the remainder, I would consistently get the last digit.

So I started thinking: if I needed the last digit of each result of dividing the entry, why not use mod?

From this frame of thinking, I realize that I probably went the extra mile and made this more complex than it should be. Here is my first working program, though:

#include <stdio.h>

int main(int argc, char* argv[]) {

int entry, right_digit, left_digits, MOD, DIVISOR;
// these are named to reflect the position of the digit in the input

printf("Enter a whole, non-negative number with any amount of digits: ");
scanf("%d", &entry);

MOD = 10;
DIVISOR = 10;

// This takes care of the right-most digit, and prints it on the left

right_digit = entry % MOD;
printf("%d", right_digit);

// my hint is to use a do loop for the left digits

do {
MOD *= 10;
left_digits = entry;
left_digits %= MOD;
left_digits /= DIVISOR;
if (left_digits <= 0) {
break;
}
printf("%d", left_digits);
DIVISOR *= 10;
} while (left_digits > 0);

printf("\n");

return 0;

}

Skip past all of the printf/scanf nonsense that comes before the actual maths.

The right-most digit of the entry is taken care of first, because it needs to be printed on the far left if the number is to be reversed. Assume we use the number 5932 as our entry. The remainder of 5932 % 10 is 2. 2 is printed first.

Once that's done, we move into the do loop.

MOD starts out at 10 for the first calculation. The first part of the do loop multiplies MOD by 10.

left_digits is then assigned the value of entry. I worked with the original value through this because I couldn't figure out how else to do it (granted, I also couldn't figure out what was decrementing to 0 to give me a floating point exception).

left_digits is then divided by 100 and the remainder is stored back into left_digits. Assuming the original entry is 5932, for example, the remainder is 32.

left_digits is then divided by DIVISOR, which also begins at 10. Because it is an integer, and assuming we continue using the example above, left_digits is assigned the value of 3.

There is a conditional here to end the loop prematurely if left_digits is less than or equal to 0.

left_digits is printed. Continuing with the example entry above, the value printed here is 3. So far, our reversed number is: 23

DIVISOR is then multiplied by 10, making it 100.

Since left_digits is not 0, we loop again!

MOD is multiplied by 10 again and is now 1000.

left_digits is assigned the value of entry again because of the way this works. You'll see the pattern, just hang on.

left_digits is divided by MOD, which is 1000, and the remainder is assigned back into left_digits. Using the example above, the remainder would be 932.

left_digits is divided by DIVISOR, which is 100, and assigns the value to left_digits. Using our example, the value is now 9.

left_digits is printed, as long as it is not 0. So far in this loop, our reversed number is: 239

DIVISOR is multiplied by 10 again, making it 1000.

So, you see??? I got it to work!! Is there a better way to do it??? Probably!! But it does work, hahahaha.

I wonder when it will be that I look back at this little fragment and say, "What was I thinking??"

Oh, and I wonder if it's worth noting that I also hand-calculated the entire loop path to see exactly what it was doing, and that's exactly how I found out why I was getting a floating point exception error.

[untitled]

I think about this blog frequently. I think about the different directions I've pulled it in; about all the directions I've been pulled in, myself! I ought to be more regular here.

I ought to be more regular in studying the things I want to pursue, too. Here's the hard truth though... When you're not in high school or college, but in the school of the self, there is no grading scale to push you forward. There are only two states you can be: Are you where you want to be? Or aren't you?

For me, I laugh at programmer jokes because I understand them. But can I sit down and write a program? Well, maybe a really short one. It might be good for a couple of computations, but you'll have to use the console to run it. I have a hard time calling myself a "programmer" at this point.

If I had spent the last year or so working nonstop on programming languages, namely C, I'd be able to say a lot more for myself than that, I think. But this isn't a pity party. This is recognition of the truth. If I had worked harder, I would have made more progress.

I took a few detours here and there, and dabbled some in HTML/CSS. It was a good feeling to be able to build my company a website, and, in turn, host my own website for a guild I own in Guild Wars 2. I've been commissioned for a third website by my father's band. I won't say that my time learning HTML and CSS has been wasted. Even so, I'm not very good at it, and other web developers will make me feel stunted because I don't know Javascript or PHP. I started learning PHP too, but got overwhelmed with keeping these languages straight.

Now, after all this time, I'm back in the C seat. There are several reasons for this decision: I have an applicable chunk of code that is open for manipulation. Every time I make headway in a chapter of a book, I go look at this code to see how much more of it I understand. This is my way of quantifying my progress. Can I write a program? Not yet. But I can start making a little more sense of how this program is written and that is loads more than I could do before I worked through that chapter.

I keep my Github updated with recent programs I've written with the goal of working through each programming project at the end of a chapter. Some chapters have 8 projects, but lately they have had upwards of 12 - 15. It's slow going, especially when I have a wedding to plan, a full-time job to work, and all I want to do when I get home is mindless stuff. But when I write a program, it goes there. Find my Github at this link, or in my bookmarks page.

I also want to expand on that bookmarks page a bit more. As I learn things and teach myself how to do more things, I want this to turn into a resource for other people in the same boat I'm in. Those who want to learn how to do this stuff because of a calling or an interest, but don't know where to start. I was inclined to delete the posts I made that were off-topic from C, but I will leave them. It just goes to show how sometimes, distractions happen. And even if you look back at them with some regrets, you still have the experience to show for it.

I hope to be able to post things that are less dreary and more fun in the near future. Fingers crossed!!

Code is Poetry

I found this on the Wordpress Website. I'm researching what it will involve to include a page on my company's website that will allow me to post updates on a daily or weekly basis. Wordpress has been mentioned in almost every resource I've read recently (that is anywhere near up-to-date), so I'm looking into it now.

Finding this at the bottom of their page was neat and I really like it. Click through the image to visit the Wordpress Codex, where I found this gorgeous little design piece.

Anecdotal Advice

My tunes for the night. This soundtrack is so amazing. The game is great, too. I thoroughly enjoyed it, and I look forward to playing the second game the same studio produced and released recently, called Transistor.

I promise I didn't come here to babble about video games, much as I'd like to. Instead, I want to babble about the furthering of ones' knowledge and skill.

This has been a recent discovery for me. I described it when I first felt it as "a desire so strong to achieve a goal that the relatively unenjoyable steps that need to be taken along the way are no longer unenjoyable". When I questioned my fiancé on what a feeling like that could possibly be, he merely named it "motivation". That's when I realized that I had not been truly motivated to do something for a very long time. Long enough to forget what it felt like.

That was in 2011. At the time, the feeling applied to my artwork, which I was using as an outlet for brainstorming a story that Andrei and I were working on together. I became enamored with the concept of MUDs after being introduced to one, and in 2012, I spent all of my time learning as much as I could about them. The desire I had to learn about them made me voracious for any information I could find, though it was quite thin by the time I started looking (most MUD information was out-of-date by 2007, with the massive popularity of emerging MMOs at the time). As I learned more about MUDs, I only became more fascinated by them. The majority of the old codebases were written in C, so I took the natural next-step and picked up C to try to fully understand them. The knowledge certainly helped when I started trying to script short programs into the MUD I build for!

Progress on that front has been halting, thanks to several projects I have on my plate that have been vying for priority. Now that I've made the overall decision to focus on HTML/CSS, I feel the same motivation driving me forward when I get stuck. I've grown to call it "possibility", personally. If I give up on whatever I'm working on, the possibility of anything coming of it will die. And, really... Anything is possible.

But, enough broad anecdote. What does that kind of motivation look like? Outside of the forward-driving force that is ones' own motivation, it looks something like this:

• Scouring shelves at bookstores for used and new books that could hold useful information
• Hunting for online resources; magazines, white papers, newsletters, blogs... anything.
• Stepping away from the games or TV shows a little earlier at night to fit a little bit of reading in before bed
• Keeping a digital copy open on the phone/tablet/computer on the off-chance that a 15-minute span of time pops up to allow for some quick reading
• Writing a lot of code
• Making lots of mistakes
• Reading or talking about those mistakes and finding industry advice on how to avoid them
• Making more mistakes, and hopefully, some visible progress

At least, that's what it looks like for me. I was lucky enough to stumble upon a used book published in 2004 for $6 that focuses on web standards for HTML and CSS. Inside, the author made heavy reference to his blog, so I went to see what he had to say. The blog hadn't been updated in a year or so, but even so... Thankfully, HTML and CSS haven't changed too much in the past 10 years, and the changes that have been made are very helpfully documented on the W3Schools Website. With that being the case, this blog is a fount of information. Additionally, the author often references a great deal of other resources. While reading through his blog, I found myself bookmarking every other page I visited for the quality of content I read. Some things were a little confusing, being marketed to web designers who have been in the industry for years. But, that unenjoyable feeling of being confused? It didn't last long when I reached a point in those articles when things began making sense. If I had given up and decided to come back when I had more experience, I'd have robbed myself of the opportunity to understand. It took more effort to continue reading something I legitimately didn't get, but the payoff was far greater.

This has been an incredibly rambly way of explaining why it's a bad idea to give up. If something seems out of reach, there are times that you give yourself an excuse to not work as hard. It is tough to keep the motivation going. But to throw the towel in because something is too hard or you don't get it is the wrong approach -- instead, figure out why it's too hard or why you don't understand, and go from there. And if that is way too much work, then start asking yourself if you've chosen the right thing to take up your time.

Some of the HTML/CSS references I found are listed below, for anyone interested. I wish all a wonderful night or day, whichever the case may be.

---

• SimpleBits.com Archive (aforementioned Blog)
• A List Apart
• ImpressiveWebs
• Smashing Magazine