I’ve been learning and using Python quite extensively for the past few years, and every time I mention that to someone they go, “ugh! that language with the indentation-based syntax”. And I’m like, really? That in my book is a quality of the language. Seriously, don’t you indent your code meticulously anyway? Python simply spares you from also having to bother with curly braces, or extra keywords.
But the fact that people complain about that mostly tells me they haven’t used Python enough to discover some of its real downsides. It has plenty, and they’re becoming quite familiar to me as of late. So let me give you some good reasons to hate Python, before I explain why I favor it over other programming languages anyway.
You know what HTML is, right? It’s the file format browsers read in order to show you pretty web pages, with all the bells and whistles you’re accustomed to. It can get quite complex, but at its most basic it nothing more than this:
Here is some bold text for your enjoyment.
Let’s look at the HTML that produces the text above. Tell me, is it
code or data?
Here is some <b>bold text</b> for your enjoyment.
It looks like data, right? After all, it’s mostly text, meant to be read by human beings. They even call these HTML documents! How could anyone think it’s code?
Well, I say it is, because it instructs your web browser to do five things in sequence:
- Display “Here is some “;
- switch to bold text;
- display “bold text”;
- switch to regular text;
- display ” to work with.”.
Does that look like programming to you yet? Maybe it’s not cryptic enough. Let’s see how the same effect could be accomplished with an older language called Troff, that they used in the mainframe era:
Here is some .B bold text .R for your enjoyment.
There you go. The exact sequence of instructions I listed above, made explicit — a big no-no nowadays, when we like to pretend computers are easy. But even if you just select the text and click “Bold” in your favorite editor, deep down you’re expressing the same thing — a little computer program.
Hello, everyone. We had a long weekend in Romania, courtesy of December 1st falling on a Monday, and I spent it meeting with friends. In exchange for the newsletter being late, I give you a new version of RogueBot:
Yes, after going in the wrong direction for weeks, I completely redesigned the gameplay, and it’s off to a good start this time. Even with just the absolute basics in place, it feels like a game. It’s frantic. It’s challenging. (If you want an easy game, try Buzz Grid.) It requires both dexterity and planning. And it feels like there’s room for improvement, both on the player’s and the developer’s side.
In other words, a success.
Felix just wrote a post on Seltani and its work to create a more accessible MUD experience.
There is another project which has similar aims, but more indirectly. It’s aimed at the developer who wants to customize their MUD completely, using a language that offers quick development: Python.
It’s called Evennia, and it brings a host of game-changers (pardon the pun) to the table.
I’ve entertained the notion on and off as of late, but when I finally acquired a gamepad it was a spur-of-the-moment decision (and possibly a bad one if my finances don’t improve). The tipping point was the double realization that supporting a gamepad is actually quite easy, yet relatively few Linux games bother, so I could add support in my own games — learning how it works in the process — and perhaps raise awareness of this issue with a platform that still struggles to gain acceptance among gamers.
There was also the fact that very little appears to be written about actually designing games to work with a gamepad versus mouse+keyboard, as if it was a simple matter. And that’s really odd, considering how the control scheme is usually the biggest complaint about games ported from consoles to the PC.
I’m conflicted about this. On the one hand, I’ve spent the last two articles complaining about the difficulties of writing portable software. On the other hand, I’ve spent five days porting Buzz Grid to PyGame, and it came out better-looking that the original!
This time, however, I was able to keep the gameplay unchanged.
Square Shooter was my first HTML5 game, and while that has allowed me to show it off easily (and brag about it when HTML5 was still fairly exotic), I always wanted a desktop version as well. And I made one! The most intense coding marathon I’ve ever done (500 lines of code in two days!) resulted in a game that’s easier to control and understand, and looks better to boot.
Let me tell you how I did it.
Alright!… so now we’re close to having a somewhat functional product. In that, we will have something that can accept connections and have some interactivity between those connections.
We talked about architecture, interthread communications, and network code. Now, let’s integrate a script language. The script language is going to be responsible for the game logic — basically, anything we want to be able to change really easily. For this example, we’ll use Python because it is very easy to integrate. (continue reading…)