#52WeeksOfCode Week 24 – Game Programming

Week: 24

Language: Game Programming

IDE(s): Twinery 2.0 Beta

History (official):

This is the only entry in this sequence which is completely open. Since I can use any language or platform I want, there’s nobody to pick on.

History (real):

When I was a program chair for our game software engineering program, I was given a lot of textbooks from optimistic publisher reps. One that stood out from the others was “Beginning C++ Game Programming”. (Dawson, Michael. Beginning C++ Game Programming (Game Development Series). Premier Press, 2004.)

We ended up not using the book because it didn’t target a particular platform like Windows or game programming framework like Unreal. But when I took a closer look at it, I realized it wasn’t actually about game programming.

It was about learning to code by programming games.  The book took you through basic programming concepts, such as control structures, loops, data structures and even object-oriented programming. These are all of the things that would be covered by a beginning to intermediate programming text. What made it different was that every piece of code was either a game or gaming-related (like a character generator for an RPG). It almost made me want to learn C++ over again because the book made it look like so much fun.

While technology and education methodologies have progressed substantially since I was a lad, programming textbooks still have really boring assignments. The success of gamification in learning as illustrated by Khan Academy, Code Academy  and Google’s Oppia project suggests that it’s time to bring that into the classroom at the college level.

Discussion:

The goal this week is to write a game. I can pick any language, framework or platform I want. I am, in fact, spoiled for choice.

When I was a lad and computers were the size of draft horses and ran on steam power, computer games were text-only. They were a lot like those “Choose Your Own Adventure” books and some of them, most notably from Infocom Games, were very sophisticated.

Though text adventures are not as popular as they once were, they’re still around, supported by an enthusiastic community of developers and storytellers. As a result, there are a number of software programs that make it easier for you to develop a text adventure and users post their files for others in the community to try.

At one time I wanted to try my hand at this and I used Inform, which was a powerful tool that included a scripting language and let you build very complex worlds. Unfortunately learning to program in Inform was definitely more work for me than my casual interest in creating a game so I did a quick project and never picked it up again.

We have more choices these days, however. A newcomer to the field is Twine, a tool that is more in the spirit of the Choose Your Own Adventure books and so not as sophisticated as Inform. Consequently, it’s much easier to build a game. There are two versions of Twine. One is a downloadable package for Windows or Mac OS X. The new version (which is still in beta) lets you do all of your development in a Web browser and then download your game as an HTML file. That looked like fun, so I started it up in a browser window.

Twine game editor

Twine Web-based game editor

The interface is a bit sparse so it took a bit of experimentation to get started. You are presented with a blank canvas. To begin you add a Passage, which is what I would have called a room. When you do, you’re presented with the Passage editor.

Passage edit window

Editing a Passage

You give the Passage a name. You can also add Tags, which contain information that is not visible to players but might be anything from a simple annotation to a link to run a custom script before the story starts. Tags are totally optional.

Unless you want the shortest story ever, you need to link to other Passages.  The easy way to do this is by adding the name of the Passage, surrounded by double square brackets, as you can see above. If the Passage you name doesn’t exist, it will be created and linked to the current Passage. You can put as many links as you want to other Passages. You can also create the new Passage directly in the editor and link to it later.

Continue creating and editing Passages until you reach an end point for your game. At any time you can play-test your game in the editor.

Starting the game

Starting up my game

Note that all of your data is saved locally in your Web browser so if you quit without saving then you’ve lost all of that work. Fortunately you can archive your work in progress by periodically clicking on the Home icon in your editor and going to your main work page.

Twine Web Main Page

Twine Web Editor home page

There you can also start a new story, import story files and work on other stories. Once you’ve completed your game, you can download it as an HTML file and either post it as a Web page or open it locally in a browser.

It was very quick and easy. Though I could have jazzed it up with stylesheets and javascripts, that’s totally optional. The thing is, I had so much fun putting using this that I can see myself coming back to it.

I may not have the Great American Novel inside me but there are plenty of short stories.

Advertisements

#Review – The New Hacker’s Dictionary

bogosity /boh-go’s*-tee/ n.

 

  1. [orig. CMU, now very common] The degree to which something is bogus. Bogosity is measured with a bogometer; in a seminar, when a speaker says something bogus, a listener might raise his hand and say “My bogometer just triggered”. More extremely, “You just pinned my bogometer” means you just said or did something so outrageously bogus that it is off the scale, pinning the bogometer needle at the highest possible reading (one might also say “You just redlined my bogometer”). The agreed-upon unit of bogosity is the microLenat. 2. The potential field generated by a bogon flux; see quantum bogodynamics. See also bogon flux, bogon filter, bogus.”

 

I love words. I’m always looking for new phrases and jargon, the more evocative the better. After I read Steven Levy’s Hackers, one of the things that stuck with me was how this group had developed their own language.

Every field of expertise has its own jargon. For hackers, though, English is just another programming language, just with looser rules. It’s a system. Hackers explore and manipulate systems, either to achieve a specific goal, see what happens or just to have some fun.

The New Hacker’s Dictionary originated in 1975 at Stanford as a simple file maintained by Raphael Finkel, collecting hacker jargon from various branches of the community. Like any language, ‘hacker-speak’ has dialects. The file was copied around the community, each group adding their own entries to what was becoming a shared history of the hacker culture. Eventually it was collected and published by M.I.T. Press and that’s when I got my hands on a copy.

Normally you don’t read a dictionary for fun, but this one is different. It’s a snapshot of a period of time that transformed not only my own personal and professional life but that of the world.

Consider this. The year the Jargon File was created, the very first personal computer was offered for sale.

It was the MITS Altair.

It came with 256 bytes of memory (expandable to 64K), had no keyboard or monitor and a single data bus. You had to key in your programs in low-level assembler code by flipping switches on the front panel one word at a time.

It sold as a kit for $297 (the case was extra).

Oh, yeah, I almost forgot. Microsoft got their start licensing software for the MITS Altair.

The year the Jargon File was finally published, more email was sent than postal mail in the United States and an IBM computer named Deep Blue became the first machine to beat a chess grandmaster.

The book includes a pronunciation guide, a guide to hacker writing and speaking style, a section describing hacker folklore and a guide to ‘J. Random Hacker’, which serves as a sort of spotter’s guide.

The words and phrases themselves range from layered and complex to playful and the book includes cartoons by Guy L. Steele, co-author and noted computer scientist.


Reference: Raymond, Eric S. The new hacker’s dictionary. Eric S Raymond. M.I.T. Press, 1996.

#Review – The Art of Unix Programming

There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all.

I was introduced to Unix in 1986. I was working at AT&T as a communications technician and my operations manager had just gotten hold of three 3B2 minicomputers. I was tapped to do something useful with them. So I bought a copy of Unix System V Bible, plugged a serial terminal into one of the 3B2s and started learning.

I still have that book, by the way.

This was my introduction to Unix. It was also my introduction to the Unix culture, and the wider world of the Open Source software movement.

Eric S. Raymond is one of the most eloquent supporters of Open Source. His book The Cathedral and the Bazaar was a seminal work on the emerging information economy and the changing model of software development. As Cathedral was a work of philosophy, Raymond’s The Art of Unix Programming was about practice.

As I’ve said before, I’m not a professional programmer. I write code for fun and to build tools for other work. I teach programming. I blog about programming. I read about programming. These are just some of the reasons that Eric Raymond’s book has a permanent place on my bookshelf.

Another reason is that Raymond is a damn good writer. He’s engaging, passionate and smart without being condescending. This book is nominally about writing Unix programs but on a higher level it’s a treatise on software design. Raymond uses Unix as a jumping-off point to discuss the larger topic of writing good software.

It’s not about a particular programming language. You can write Unix programs in any language you like.

One of my favorite sections is “Basics of the Unix Philosophy” where he lays out the rules of design for good code. From the Rule of Modularity (“Write simple parts connected by clean interfaces”) to the Rule of Extensibility (“Design for the future, because it will be here sooner than you think.”), they all represent solid advice for designing code with any language on any platform. I’ve tried to incorporate these rules in my own code.

In addition to offering guidance for current and would-be programmers, there is a section on design principles, including Modularity, Textuality and Interfaces. Naturally, there are copious references to Open Source, including a discussion of software licensing and best practices.

But it’s not all sunshine and relentless boosterism. Raymond takes a clear-eyed look at the problems with Unix culture and problems in Unix design. Bonus features include a section called ‘Rootless Root’, a parody of Zen philosophy complete with Unix koans and copious examples of code demonstrating the principles that Raymond outlines the book.

The Art of Unix Programming is not just a good book for coders but for anyone who enjoys reading about the philosophy of design.

 

References:

Raymond, Eric S. The Art of Unix programming. Addison-Wesley Professional, 2003.

#Review Hackers – Heroes of the Computer Revolution

Just why Peter Samson was wandering around in Building 26 in the middle of the night is a matter that he would find difficult to explain.

My first programming class was in 1977 at a local community college. What I took away from it was the idea that you could solve any problem, no matter how overwhelming, by breaking it down into smaller and smaller functional pieces, then reassembling the pieces into a solution.

The opening sentence to Steven Levy’s book Hackers: Heroes of the Computer Revolution neatly encapsulates the book’s theme. It’s about very smart people who are compelled to act in ways that are hard for them to describe to others and even sometimes to themselves. Some of them are looking for money, others for redemption,  On a higher level, it’s a book about exploration.  It’s about compulsion. It’s about obsession. It’s about passion. It’s about America.

It’s difficult to write about computers for a general audience. The problem is similar to what Hollywood faces when they use computers as a story element. Simply put, it’s hard to make typing seem interesting.

This is where Hollywood gets it wrong. Computing isn’t about the technology, it’s about the people.

A good technology writer understands this and Steven Levy is a very good technology writer. He was a senior writer for Wired magazine and chief technology writer for Newsweek. Hackers was his first book and it’s a very engaging read.

The story starts at M.I.T. in 1958 and takes us on a journey across the country and spans almost three decades. It describes a tumultuous time in our modern history, not just politically and socially but technologically. Levy takes us from the Tech Model Railroad Club at M.I.T. to the hardware hackers of the Homebrew Computer Club in Silicon Valley to the first computer game hackers and ends up back in Cambridge with the ‘Last of the True Hackers’. Along the way we see how what was once unimaginable became commonplace.

Most important to me, this book showed I wasn’t alone. I understood these people. They were flawed like everyone else but they had a passion and the skill to make the thoughts inside their heads into reality for the rest of us.

 

References:

Levy, Steven. Hackers: Heroes of the computer revolution. New York: Penguin Books, 2001.

#52WeeksOfCode Week 5 – Ruby

Week: 5

Language: Ruby

IDE(s): Komodo Edit

Background:

“I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.”

Yukihiro Matsumoto, the creator of Ruby, Google Tech Talk, 2008

““Anyone who has ever seen a programmer at work—any wife or husband of a programmer who has ever tried to interrupt a terminal session or a conference over a bug—knows that programming itself, if the programmer is given a chance to do it his way, is the biggest motivation in programming. ”

Excerpt From: Gerald M. Weinberg. “The Psychology of Computer Programming: Silver Anniversary eBook Edition.” iBooks. https://itun.es/us/H5erA.l

“The average person can’t see what makes code elegant or unorganized. In addition, our industry is very new. While humans have been cooking, making music, and building for thousands of years, archaeologists have yet to discover those cave paintings of Man at His Desk Typing.

So, metaphor has to become our meta-language. Not only is it how we connect the uniqueness of programming to the general public, but it’s often how we make decisions on how we approach our own software problems.”

Excerpt From: Ka Wai Cheung. “The Developer’s Code” iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=7687021FDF079E4460BC1CBEAA74BC02

There is a perception among non-technical folk that technical objects such as software, smartphones, computers and so forth are creations of pure logical mind, unsullied by subjective emotion, something something pure wind-swept mountains of something something intellect.

Ahem.

Okay, you know how when your boss says something so wrong that you feel obligated to correct them, even though this person may hold your career, your very life in their hands? How do you tell them? Rather than just straight out confront them with their wrongness, the best strategy is to simply say, “Well, that turns out not to be the case.”

Anyway, back at the pure wind-swept mountains of something something intellect….

Well, that turns out not to be the case.

Every creative person views the world as being filled with holes. When you willfully create something, you do so in order to fill one or more of those perceived holes. In short, whatever you create has to fit one of those holes and gets you one step further to completing your vision of the world according to you.

What I’m getting it is that technical innovations are as much a product of our psychology as they are of math and engineering. In fact, I would argue that many are primarily psychologically rooted in their creators, with just enough math and engineering for them to actually function out here in the real world.

Ruby is a good example. Its creator, Yukihiro Matsumoto, states:

“…there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language—how we feel while programming…Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That’s Ruby’s main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby.” [Emphasis mine.]

(Venners, B. (n.d.). Retrieved from http://www.artima.com/intv/ruby.html)

Matsumoto, a.k.a. Matz, is a professional programmer and is comfortable with any number of programming languages but he saw a Ruby-shaped hole in the world.

This week’s code sample is a very simple client and server pair. The server program (Hello_World.srv.rb) opens up a network connection and waits:

macpro15:Week 5 tsinclair$ ./Hello_World_srv.rb

When the client (Hello_World_clt.rb) starts up, it connects to the server.

The server announces the connection, sends the greeting

macpro15:Week 5 tsinclair$ ./Hello_World_srv.rb
Client has connected!
Sending greeting....

and the client prints out the greeting from the server and disconnects:

macpro15:Week 5 tsinclair$ ./Hello_World_clt.rb
You are connecting from:
127.0.0.1
Hello World!
Closing the connection. Bye!

The sample code for the server is here and the code for the client is here. They are both pretty simple but as I’ve pointed out previously, the code isn’t the point of these weekly posts. However, this is the first network programming I’ve done and it’s primarily due to the ease of writing network-aware code in Ruby that I chose to do so.

#52WeeksOfCode Week 4 – Python

Week: 4

 Language: Python

 IDE(s): Komodo Edit

Background:

There are programmers and then there are programming nerds. (I use the term ‘nerds’ affectionately as I consider them to be my people.). Python is a scripting language created by and for programming nerds. (Note that his is not necessarily a problem.) This attitude is exemplified by the document PEP 20 – The Zen of Python.

The philosophy of the language is encapsulated into 20 zen-like aphorisms (only 19 of which have been written down):

  • Beautiful is better than ugly.
  • Explicit is better than implicit.
  • Simple is better than complex.
  • Complex is better than complicated.
  • Flat is better than nested.
  • Sparse is better than dense.
  • Readability counts.
  • Special cases aren’t special enough to break the rules.
  • Although practicality beats purity.
  • Errors should never pass silently.
  • Unless explicitly silenced.
  • In the face of ambiguity, refuse the temptation to guess.
  • There should be one– and preferably only one –obvious way to do it.
  • Although that way may not be obvious at first unless you’re Dutch.
  • Now is better than never.
  • Although never is often better than *right* now.
  • If the implementation is hard to explain, it’s a bad idea.
  • If the implementation is easy to explain, it may be a good idea.
  • Namespaces are one honking great idea — let’s do more of those!

Geeky mysticism aside, Python was designed with a very simple, clear, English-like syntax (making it one of the easiest languages to learn). In fact, our standard HelloWorld program can be written with one line:

print 'Hello, world!'

But it’s also very extensible, not only by making the addition of functionality very easy as well as allowing the user to modify or re-implement even pre-defined functionality. If I don’t like the way a built-in method or object works, I can just re-define it. This makes Python very scalable, suitable for use in small one-off scripts to large, complex projects. Python runs on multiple computer platforms and has been ported to other language frameworks including Java and .NET.

Anyway, back to this week’s code. Unfortunately (or not, depending on your point of view) with Python I’m really spoiled for choice. There is plenty of documentation available so there only remains to figure out what I want to do with it. (This is the hardest part of picking up a programming language, by the way – coming up with a project idea.)

I’d like to keep up my tradition of building on the ‘Hello World’ canon. In addition, I have to make it simple in order to make my self-imposed deadline and still keep my title as World’s Slowest Coder (™). Not only that but despite the fact that I can use a simple text editor to write my program I decided to try out the free cross-platform IDE Komodo Edit.

Using my personal mantra of “If you’re not sure how to start, do the dumbest thing you can think of that gets you at least part of what you want.”

(Granted, as personal mantras go, it’s not quite up to the standard of ‘Just do it.’)

So I whipped up a quick script that has the word ‘Hello’ sneak up on ‘World’ and swallow it. Here’s the code, if anyone is interested. It’s pretty crappy but it doesn’t require anything apart from the standard Python installation. (I will likely jazz it up in future however, since it’s kind of fugly as it currently stands.)

Epilogue:

I had some trouble finding a hook for this week’s challenge. But as I dug into the subject, I was reminded that while there is a rigorous scientific and mathematical foundation to computing, this is mixed with a combination of mysticism, spirituality and philosophy. Software is at its heart a pure product of mind, where a programmer can create their own worlds. But to create a programming language is to create your own universe, where you set all of the rules.

#52WeeksOfCode Week 1 – JQuery Effects

Week: 1

Language: JQuery

IDE(s): TextMate

Background:

The World Wide Web (does anyone still call it that?) was once a quiet, meditative place. After all, the protocols were originally designed as a cross-platform way that scientists could exchange research papers. (That’s right, kids. At one time ‘surfing the Web’ was otherwise known as ‘reading’.) Then, of course, the rest of us got hold of it and now it’s all about talking cats demanding fast food. Well, that’s progress for you.

At any rate, Web pages were originally static documents written using a relatively simple markup language known as HTML. You didn’t need any fancy tools or advanced knowledge to set up a Web site, a simple text editor worked just fine.

In 1995 Brendan Eich, a developer at Netscape decided that the Web needed to be a bit more interesting, so he developed a programming language that would run inside the browser. Originally called LiveScript, it was designed to add dynamic elements like buttons and text fields for online forms and was later renamed Javascript (which, despite the name, is not related to Sun Microsystem’s Java programming language). Now what was once just data was now mixed with active code. Some people had a problem with this.

I first encountered Javascript several years ago and at the time it was pretty easy to learn, particularly since I was already familiar with other programming languages. The main new thing I had to wrap my brain around was the idea of code running inside of a document. I haven’t used it since then and the language has evolved considerably due to its built-in extensibility. In addition, Javascript has moved beyond the Web browser to become more of a general purpose scripting language used in productivity software, digital media development and even game engines.

Extending JavaScript is actually quite easy. You simply create a JavaScript file  with the code you wish to be able to use and then tell your scripts where to find it. Reusable code like this is referred to as a ‘library’.(You’ll see this later when we get into our example code.)

JQuery is a library of prepackaged JavaScript code that works across multiple platforms and browsers and adds a lot of useful functionality to basic JavaScript, including functions to access Web 2.0 frameworks such as AJAX and easier ways of controlling animated elements on a Web page, which I’ll use in my demonstration code.

Setup: The best way to test Web software is with a Web server. I have several options for this but I wanted to set up a local environment so I could work without an Internet connection if I wanted. Once again, there are a lot of options for this but for me the easiest was MAMP.  This is Mac-based software that gives you a simple, turn-key solution for Web development (there are versions available for Linux and Windows as well.) It’s dead easy to install and set up so I was able to quickly set up my MacBook as a programming workstation.

(Before I get indignant emails, I do realize that Mac OS X has built-in Web and database services but with the latest release they’ve become more of a hassle to setup and manage. MAMP is pretty much plug-and-play as are its Windows and Linux versions.)

So I have my test server. How do I manage my code? I wanted to keep things simple, so I went old-school – a text editor. I used Textmate, the free cousin to BBEdit. BBEdit is one of the best standalone programming editors for the Mac and I’ve been using it for years.

(My favorite Windows editor is ConText and when I’m using Linux/Unix I just use vi but if I had to pick a feature-full GUI text editor for Linux both gedit and kedit are quite good.)

Coding: When I taught beginning programming, my students would often get stuck when starting a project. This is the advice I’d give them:

Don’t try to solve the entire problem – This is good advice in general but even more so when you’re trying to do or learn something new. Instead solve the smallest part of the problem you can manage and see where that takes you. So if you’re writing a program that is supposed to process text, start by writing just enough so you can open a file and print out its contents.

Start with what you know has to be there – Every programming language has a certain minimum amount of code that has to appear in every program. For basic JavaScript that means a Web page, like so:

<!doctype html>
<html>
<head>
<meta charset=”utf-8″ />
<title>Demo</title>
</head>
<body>
<script>

// Your code goes here.

</script>
</body>
</html>

However, we’re adding the JQuery library so we have to modify this a bit:

<!doctype html>

<html>

<head>

   <meta charset=”utf-8″ />

   <title>Demo</title>

</head>

<body>

   <script src=”jquery.js”></script>

   <script>

   // Your code goes here.

   </script>

</body>

</html>

 I put the JQuery package (jquery.js) in the same folder as my Web page and then added a line to tell the Web browser where to find the code when it processed my page.

Have a project already in mind – The best way to learn a programming language (or pick up any skill) is to have an idea of how you’d like to use it. If you’re planning a trip to Italy, for example, you’ll be much more motivated and focused while learning to speak Italian. Programming is the same. Fortunately the assignment for this week is very simple – use one or more of the JQuery Effects to animate some element of a Web page.

You don’t have to reinvent the wheel – There is plenty of sample code out there, in addition to code that you’ve written yourself for earlier projects so it’s a good idea to keep old code snippets handy for future occasions. The first place to check is the vendor documentation. You can also post your question to an appropriate discussion site.

According to hacker tradition, the first program you write should be some form of “Hello World”. In other words, write a program that outputs the stated phrase in some form or another.

So in the interest of keeping things simple, I wrote a quick script that will make the words Hello World slide down on to the Web page. The complete program is here. I adapted the sample code from the JQuery documentation. (Note that I gave them appropriate credit in my script.)

 As to what it looks like, I don’t yet have a public facing Web server set up but I can show you with this screen grab:

NOTE: I regret that this was a rather abbreviated entry. I got off to a late start on the coding challenge and wanted to keep to an ongoing deadline of midnight Tuesdays throughout the challenge. Future posts will be more detailed.