- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- May 2005
- April 2005
Author Archives: henk
One-button-RTS fans rejoice! The OS X and Linux ports of No Fun Games’ one-button-RTS Pax Britannica are finally complete, and you can pick them up at the new official Pax Britannica website. Single-player is still supported, but to get the most out of the game you really want to play multiplayer, up to four players on one computer are supported.
Pick it up, and let us know what you think!
Update: Visit the official Pax Britannica website.
Pax Britannica is No Fun Games’ newest work, a one-button real-time strategy game. It was programmed and designed by Renaud Bédard, Matthew Gallant and myself, with visuals by Daniel Burton and audio by Ben Abraham. It was written for Kokoromi’s gamma 4, a showcase for one-button games. Once we found out that it hadn’t been selected, we posted it to the TIGForums for feedback. We weren’t really planning on treating this as an official release, but it’s gotten enough attention that it’s about time I wrote something about it ^_^.
In Pax Britannica, you control one of up to four motherships taking part in an underwater skirmish. Each player uses one button (A, F, H, or L if you don’t have gamepads plugged in) to control ship production, with the ships themselves being AI-controlled.
To check it out, download the Windows pre-release. Mac OSX and Linux versions are on the way, along with the official release.
These simple mechanics lead to a surprising amount of depth, and we’ve gotten praise to that effect. Pax Britannica was shown on Bytejacker, my favourite video podcast ever, where it’s currently a contender for Free Indie of the Week. It’s been featured on IndieGames.com, Play This Thing!, Gamasutra, and GayGamer.net among others (thanks guys!). Also, an adorable little kid said it was good! (Thanks @CymonsGames!)
For a quick peek, check out Darius Kazemi’s video review (much appreciated!), embedded below.
Several new textual genres have emerged with digital computing and automation. Computer programs, complex lists of formal instructions written in specially designed, artificial languages, can be seen as a new type of the rhetorical figure apostrophe, the addressing of inanimate or abstract objects, with the magical difference that it actually provokes a response. Short, simple programs are often linear, but longer programs generally consist of collections of interdependent fragments, with repeating loops, cross-references, and discontinuous “jumps” back and forth between sections. [...]
Programs are normally written with two kinds of receivers in mind: the machines and other programers. This gives rise to a double standard of aesthetics, often in conflict: efficiency and clarity. Since speed is a major quality in computer aesthetics, an unreadable program might perform much faster than a comprehensible one. The poetics of computer program writing is constantly evolving, and through paradigms such as object orientation it inspires practical philosophies and provides hermeneutic models for organizing and understanding the world, both directly (through programed systems) and indirectly (through the worldviews of computer engineers).
From Cybertext: Perspectives on Ergodic Literature, Espen J. Aarseth (p11). Emphasis mine.
A Preliminary Poetics for Interactive Drama and Games by Michael Mateas discusses an interesting concept for video games called agency. Mateas describes agency as “the feeling of empowerment that comes from being able to take actions in the world whose effects relate to the player’s intention”. Basically, that means that the player is coming up with goals they want to reach (that is, they are forming intentions), and based on them decide on in-game actions to take which will move them towards their goal. A more simplistic way to say it would be that the player can do the things that they want to do, and have them cause effects related to what they were expecting.
Sounds great, how do we do that?
If a game gives the player agency, then the act of playing the game becomes more directed and enjoyable. But, how does a game make this happen? Mateas answers this by first bringing up two concepts from Aristotle’s theory of drama: material cause and formal cause.
Aristotelian what now?
Material cause and formal cause have opaque names, but they’re actually pretty simple concepts. Material cause means the components that make up something. In drama, this means things like the acting and dialog that you see when you watch it. By finding patterns in these elements, you can infer things about how the characters are feeling, and what direction the plot as a whole is going to go. This leads to the formal cause, which is the overall goal, or plan. In drama, this refers to the plot, or the theme. The author is the only one who knows the exact formal cause, but the viewer infers it from the material cause.
But wait, we were talking about games
Mateas takes adds player interaction to these concepts to map these concepts to video games. He redefines formal cause as being not only the game’s end goal, but also incorporating the goals of the player. The player forms new intentions as they’re playing, and those intentions shape what they do in the game. They become the “plot” of the gameplay experience. He also reevaluates the role of formal causation:
In noninteractive drama, understanding the formal chain of causation allows the audience to appreciate how all the action of the play stems from the dramatic necessity of the plot and theme. In interactive drama, the understanding of the formal causation from the level of plot to character additionally helps the player to have an understanding of what to do, that is, why they should take action within the story world at all.
That is, the context of the game which makes up the formal causation actually indicate to the player what actions they should expect to be able to take.
However, affordances given to the player given by the material cause also suggest actions to take. This just means that if you see something in a game, you expect to be able to interact with it and use it for something. This ties in with the concept of affordance from user interface design. For example, when a weapon drops in Super Smash Bros., not only do you expect to be able to interact with it, but its very presence suggests to you that you should do so.
What does this have to do with agency?
Mateas uses the concepts of formal and material cause to indicate how a game can give the player a sense of agency:
A player will experience agency when there is a balance between the material and formal constraints. When the actions motivated by the formal constraints (affordances) via dramatic probability in the plot are commensurate with the material constraints (affordances) made available from the levels of spectacle, pattern, language, and thought, then the player will experience agency.
The player will feel agency when the goals coming from the game’s plot or context match up with the things that the game mechanics allow and encourage the player to do. This is because the player’s long-term goals cause them to decide to take certain actions (to form intentions), and the material causes (mechanics, items) allow them to take these actions in a way that produces results. Not only that, but these results are then meaningful because they are relevant to the game’s plot or the game’s intentions (usually because the results were expected by the player). This means that the player is constantly driven to make meaningful decisions and getting meaningful results.
So, why do people play video games anyway? Of course there are lots of reasons, but understanding them helps when you’re beginning to design games. In reading “Video Games and Computer Holding Power”, a chapter from “The Second Self” by Sherry Turkle, a few cases come up which illustrate a couple of motivations. Keep in mind that the book is about 25 years old by now, so the games they are studying are Asteroids, Space Invaders, and similar. Most of those games focused on “hard fun”, but they still seem to be representative of many games today.
Games are systems which react to the actions of the player. The player gives the game certain input, and the game responds to it by behaving in a certain way. As the player figures out how the actions and reactions relate to each other, they are able to control the game state, to make it do what they want it to. For example, when you play Super Mario Bros. you learn where to jump and how to move to beat the enemies and get to the end of the level quickly. In Tetris you learn to place blocks so that you can destroy them well and get a high score. As players master a game, they start to feel control over it. The player feels control over the game’s micro-world much more than they would normally feel in real life.
Fun games can take advantage of this by leading the player to learn how they work, while continuously providing new obstacles to overcome. This way the player is always increasing their mastery of the system, while never running out of things to learn.
Deep concentration, or Flow
Sherry also describes an altered state of mind involving deep concentration. Though the chapter never actually uses the word, this altered state matches very well with Csíkszentmihályi’s notion of “flow.” There’s a good deal to read on flow (notably Csíkszentmihályi’s own “Flow: The Psychology of Optimal Experience”, which is a very interesting book), but the gist of it is that the entirety of your self is focused towards one activity, and everything else is pushed out of your mind. In this state, outside worries disappear, you lose self consciousness, and the flow of time moves at an unusual pace. Strangely, the state of flow can also make your mind feel “free”, as it’s not limited by its normal thought processes.
To begin this state of flow, the activity needs to be hard enough that it’s not too easy, but not so hard that it becomes frustrating. Video games have a unique advantage in this since, as they are backed by a computer, they can adapt to the player to offer them the ideal level of difficulty. In fact, many of the games mentioned, such as Space Invaders, Pac-Man, and Asteroids, are written to get harder and harder forever, so that in theory there’s no end to the challenge (actually, Pac-Man wasn’t quite infinite, there was a bug on the 256th level where the entire right side of the screen had corrupted graphics, making it pretty unplayable).
Since games usually give you a measure of how well you played, they make it easy to track your improvement. “The games require total concentration [...] at the same time as they provide a stage for excellence.” The combination of the two can be really addictive!
May was pretty awesome. I managed to stay committed to working on projects. I’ve noticed that the best days are when I get up early (around 7 preferably), and manage to be at my desk working by the time I’m fully awake =). When I can pull that, I’m able to keep focused and finish the day early, leaving free time to spend on other things.
Even if it worked well, it didn’t go perfectly. I kept up the habit of working continuously, but I didn’t keep a great sense of direction. Last semester at school, I started the habit of keeping a todo list, and mapping out when I would do what at the beginning of each week. I had so many different things to work on that I needed to do this to reduce pressure and get everything done.
This summer, though, I’m usually focusing on one project at a time, so I unconsciously dropped the habit. As a result, even though I’m productive a day at a time, I often don’t have a good sense of where I’ll be at the end of the week, and small tasks that aren’t part of my main project (like cleaning up -_-) often get put off too long.
In June I’m going to continue what I was doing in May, working 6 hours a day five times a week, but I’ll also work on longer-term task management. One way I’ll do this is to keep a scheduled todo list which I map out at the beginning of each week. The other way is something I’ve been experimenting with recently.
For whatever project I’m working on, I’ll put each task on a single index card, along with any notes I decide to write about it. I can lay these out on my desk, easily sort them by priority, and keep whichever one I’m working on in front of me so that I can’t forget what I’m supposed to be doing =). If I find myself working on something with no card, then it’s probably not important, and if it is then I can make a card for it on the spot. I found this to be a really satisfying way to manage tasks, especially when you can take a card and write DONE in big letters, while putting it into your success pile ^_^. It also helps to maintain focus since you know exactly what you should be doing at all times.
For the last four years I took full-time summer jobs, giving me four summers of servitude. Servitude that was somewhat enjoyable, and taught me a lot, but always servitude. This summer I’m going to do things differently. Instead of finding a job, I’m going to spend the time working on what I really want to.
Specifically, I’ll be doing indie game development. Why? Because it’s what I’m passionate about. I’m going to start out with short prototyping projects, probably about one week each, to try out different ideas. This summer I should have fun, come up with good ideas, and learn lots, improving my technical and creative skills.
The downsides to not working as an employee are that there’s no structured work environment, no outside pressure to excel, and no salary. Nevertheless I think it’s going to be a net win, since 100% of the effort I put in goes to stuff of my choice, the effort I put in directly benefits myself instead of some big corporation, and I can make the work fun!
The biggest worry I have is that since there’s no outside pressure, motivation will fade to laziness. To avoid this it’s very important to keep the work fun and cultivate my motivation.
My monthly goal for May will be to put a substantial effort into the projects I’m working on. Specifically, I’ll put in six hours of work, five times a week. This is similar to January’s goal of timeboxing 3 hours of time every day, but this time I’m going to aim to devote the entire 6 hours in a given day to a single project, which should let me focus and really get in the zone. I’ll have the option of changing what I’m working on from day to day, so I’ll still have the freedom to mix things up if I get worn out on something. This six hours is a minimum, not a fixed amount, so some days I’ll likely put in more. It’s a bit less than a full-time job, but I plan to use that extra space to allow my schedule some flexibility, not to slack off.
April was Fail. Actually, scratch that, as much as it sucked I got a hell of a lot done. The bummer is that with a sanity-crushing load of school projects followed immediately by competing in Ludum Dare, I haven’t had any time to think about April’s monthly goal.
I have big ideas for May and the rest of the summer, so I need to start building momentum right now. To start off, I’m going to spend the rest of April getting back to waking up early. The near-sleepless CS Games and end-of-semester rush knocked me out of any regular schedule I’d managed to build up, so my first goal is to straighten it out.
Last weekend I wrote a small game called “Extinguish” for the Ludum Dare 48-hour game development competition. You play on the side of advancing Evil, which is trying to engulf everything. The invadees aren’t so happy though, they’ve set up barriers which Evil can’t cross! Your job is to destroy these defences so that the conquest can continue.
Download it for:
- Linux (32-bit)
- Source .love file (run it with LÖVE or rename it to .zip to extract)
- Alternate .love file for OS X users, which uses [shift] to shoot instead of [control], which is often reserved.
The game was written for Ludum Dare, a game development competition. The idea is to write a complete (but small) game, mostly from scratch, over a 48-hour period. It’s free to participate, there are no prizes (except for your game!), and all of the post-competition judging is done by the competitors. Our theme was “advancing wall of doom,” which I think I kept to pretty well. I’m happier with Extinguish than I was with either of my previous two Ludum Dare games, but there’s still definitely room for improvement.
With my previous Ludum Dare games, the main problem was that I was driving my game design with technical ideas. This was especially true with Mininode, where I had awesome (or so I thought) ideas about how I could hook different components together into graphs and have them interact in strange ways. The problem was that once I’d implemented the technical side, I ended up having no good ideas for interesting gameplay. Needless to say, it didn’t turn out very fun.
This time, I started thinking about the actual gameplay from the beginning. With a lot of work I was eventually able to turn it into a game. This time, I had a different weakness: direction. Although I had a general idea of where I was going with the development, I didn’t take the time to break the task into milestones. The most important part of being productive is knowing what you’re doing at any moment, and what you’ll be doing next. You need to have concrete goals, or mini-deadlines. I didn’t know where I was aiming to be by the end of Saturday, so I ended up not doing as much as I could have. This made Sunday all the more frantic, and although I finished the game, I would have liked to have time to add more features, such as sound and better graphics.
I learnt a lot this weekend, and it will help me to do a better job during the next competition. If you can code and want to compete in either the next mini-competition (in May) or the next main one (in August), check out the Ludum Dare website or check out the IRC channel.
Finally, a timelapse of the development of Extinguish!
Cel Damage is a crazy cartoon car-combat game, and one of my favourite GameCube games, but it got terrible reviews and generally didn’t do very well. In my opinion there are two reasons for this. The first is the difficulty; it’s a pretty hard game, where even on the easiest mode it’s tricky to win. The other thing, though, is that you die a lot. Like, dozens of times in a few minutes.
A typical deathmatch game has you living for at least maybe 30 seconds on average (longer in many, like Counter-Strike). In Cel Damage, you’re lucky to live longer than 10, and it’s not uncommon to die while spawning! Dying can be especially frustrating for a few reasons:
- many of the weapons in the game are one-hit-kills
- some of the weapons can kill you from halfway across the map
- whether or not someone succeeds in killing you is dependent on how good the other player is, not on how good you are at defending
Basically, you can die through no fault of your own, often with no warning!
The trick to enjoying Cel Damage is realizing that it’s normal to die! What matters is who else you’re able to take out before it happens. In Cel Damage, death is not something you can reliably avoid, and that doesn’t matter.
The issue is that most games are based on survival, where dying either gives a substantial penalty or means game over. Neither of these are the case in Cel Damage, but the attitude of dying is bad is carried over when you start to play it. The game’s failure is not in how liberally it deals out death, but in not communicating to the player that dying is normal. When you’re breaking an established game design rule, you have to make it clear, otherwise the player will assume that either the game is broken or they’re doing something wrong.
As a result of my first two monthly resolutions, my time’s becoming more and more structured: a good thing! One downside, though, is that things which I never consciously decided to do before are getting ignored. Gaming was one of those things I never decided to do, I just did it. It was like breathing, you don’t set aside time for that! Now that I’m actually doing the things I decide to do, gaming isn’t happening because I’m just used to thinking about it that way. This is a problem because
- I like playing games,
- I want to make games,
- to design games I need to play games!
Therefore, gaming is important to me! The answer is obvious: play more games by scheduling time to play them! My goal for March is to play games every day, for at least 30 minutes. 30 is conservative, but it’s really a lower bound, there are some days I might not really be able to spare too much time/energy while keeping up the appearance that I’m working hard =p. I hope to score much higher on average. Besides, I can treat it as education!
At the beginning of February I set the goal of getting up at 8 every morning, even though, at the time, I was in the habit of getting up around noon. It was a bit scary, and I ended a zombie for the first week. I managed to keep to the goal except for two days, one which I excepted for a special event and the other where I woke up, then fell back asleep until 9 (no AAA for me). At the end of the month, I’m really happy I made the goal!
Getting up at a set time early in the morning (early for me at least) cuts my laziness by a lot. Managing to pull myself out of bed each morning motivates me to do things, instead of just. . . not doing things. Also, it means that staying up late has serious zombie consequences, which helps me resist surfing aimlessly late into the night. Overall I feel like I’m making much better use of my time now.
I’m definitely going to continue getting up early, though I’ll let up a bit and let myself sleep in every once in a while. I’m actually thinking of moving the time earlier. I probably would have already except for the fact that I have a couple of classes ending at 22h or later, which wouldn’t allow me much sleep. In summer, it would be nice to get up closer to sunrise!
One of the hardest parts of getting things done is actually working on problems, instead of just thinking about them. Some amount of thought obviously helps, but at a certain point you have much more to learn by tackling them head on than by being overly cautious. Not only does this help to learn about the practical issues you face, but after finishing any challenge, no matter if it’s perfect, you can move on. You can start new projects, and your experience with completing previous ones can lead you in directions you couldn’t have predicted. It’s stimulating to finish things and then move on, it keeps you motivated.
For example, the theme currently on my site was one I was thinking of for a while. I threw around designs, fiddling with ideas for months. But then I decided to actually go and write the theme. If I hadn’t taken that step in implementing it, I’d probably still be stuck with those same ideas now. But after getting it done, my mind’s moved on, and I’m thinking of new theme ideas that hadn’t even occurred to me before!
Both failure and success are learning opportunities. At least by tackling the problem head-on you can give yourself permission to move on.
I’m going to start analyzing games, to find the parts of their design which make them fun. By doing this, I’ll start to understand how a well-picked set of mechanics come together to make a fun game, so that I’ll have a better shot at making fun games myself =).
The two components of a game’s design I’m going to look at are the core and the mechanics. The core is the game’s central theme, it defines the type of experience the game will deliver. The mechanics are individual features or activities in the game which support it’s core.
I’ll treat the mechanics as areas of learning: every mechanic provides a learning opportunity to the player. The better the player gets at exercising each mechanic, the better they play the game. The challenge is to provide an optimal learning curve, where the mechanics are intuitive and easy to pick up, but aren’t immediately mastered. As long as the player is improving, they can enjoy a continually changing experience.
I’m going to start off by analyzing a great indie shooter, rRootage, by Kenta Cho of ABA Games. It can be downloaded for Windows from its web site, and Linux and Mac OS X ports are available. Use the directional keys to move, Z to shoot, and X to use your alternate ability, which depends on the mode you play.
The core of a game is, put simply, what the game is about. rRootage is a 2D shooter where you maneuver through complex volleys of bullets in order to defeat boss enemies.
Player movement in rRootage, despite having a very simple interface (just the directional keys), is actually very deep. Although the mechanism for controlling your movement is easy to understand, learning to make effective use of these controls in dangerous situations is hard.
Because the movement controls are digital, you only have one movement speed. In practice, you often need to move a very small distance, or move at a slower speed than the default. For example, you might have to navigate through a small opening in a volley of bullets. To properly navigate through, you need precise control over your motion. The way to succeed is to learn to move in small bursts, by just tapping the movement keys with good timing.
Another thing to keep track of is your overall position on the screen. In order to win, you have to destroy the enemy by firing at it. Since you can only shoot straight forward, you have to position yourself directly in front of it to hit it. You also do more damage the closer you are to the enemy, which puts you in a more vulnerable position. What’s interesting is that this issue varies in importance as you play, since when you are in danger of being hit you tend to focus on survival, whereas when you are safe you can make an effort to move back to forward centre. This automatic adjustment means you’re never bored while playing, because you can vary the difficulty of play based on where you move.
Recognizing Repetition and Patterns
The first few levels are pretty simple, as the enemies don’t fire too many bullets at you. As you get farther, though, they fire more and more, until you have entire clouds of bullets flying toward you. They aren’t just fired randomly, they have an order to them. You can’t keep track of each bullet coming at you, so you have to look for patterns in order to figure out how to avoid them. On the other hand, when bullets come close to your ship, each individual one could mean death, so you have to keep track of them individually.
As a result, you’re always torn between two opposites: keeping track of the bullets which are right around you, so you can maneuver around them, and keeping track new volleys being sent at you, to predict where they will go and how to avoid them. The first keeps you alive in the short term, but unless you plan ahead you end up being swamped with nowhere to go.
rRootage has four modes of play. In addition to the basic mechanics of movement and pattern recognition, each mode adds a mechanic of its own.
NORMAL mode gives you three ‘bombs’ to use. Setting off a bomb puts up a temporary shield around you which absorbs enemy bullets, and every time you die your bombs are replentished. Each bomb gives you one opportunity to avoid death, if used at the right time. Finding the right time is hard, though: if you use them too often, they’ll run out, leaving you defenceless, but if you’re too sparing you end up dying with bombs left over, which is also a waste.
PSY mode lets you ‘graze’ enemy bullets: if you move very close to one you get a small amount of charge from it. Fill up your charge meter to become invulnerable for a short time. Using your special ability, you can trade some movement speed in order to increase your graze radius. Lowering your movement speed can even be useful to tighten your controls. This mode encourages you to take risks and put yourself in dangerous situations, because you can use the temporary invulnerability to fly through a solid cloud of bullets you wouldn’t normally be able to navigate.
IKA mode is inspired by the excellent shooter Ikaruga. Enemy bullets are coloured either white or red, and your ship has a shield which you can alternate between the two colours. If you come near a bullet with the same colour as your shield, it’s absorbed and deals a little damage to the enemy. As you’re permanently protected from half the enemy bullets at any time, this mode throws much denser volleys at you. This means that to survive you need to keep switching back and forth between the colours. This is a challenge, because every time you change colours you have to mentally switch, to avoid the other colour. The sudden foreground-background switch is something you get used to to some extent, but it makes this mode feel much more urgent than the others, since it requires more quick thought.
Finally, there’s GW mode. GW mode is similar to NORMAL mode, except that you have an infinite number of bombs. The catch is that each bomb takes about a second of warmup before it fires, and there’s a several second cooldown afterwards before you can fire it again. On the upside, these bombs absorb bullets and damage the enemy in the same way IKA mode’s shield does. You can obviously be much more generous in your bomb use than in NORMAL mode, but because of the warmup delay they can’t be used as safely for escaping emergency situations. Instead, you have to think ahead and plan when to use them.
rRootage is a pretty simple game, but the variety of different levels and modes makes it last a good long time. Because of that, it’s been one of my favourite shooters for a few years now. Go check it out, and if you enjoy it (or think I missed something important), please leave a comment!
So January’s over, and so is my first trial of timeboxing three hours every day. That trial gave me mixed results: on many days, I got my three hours done, and felt really good about having accomplished tasks I needed to. On some days, though, my schedule was so cramped that I couldn’t find time in the day to do the hours. On yet other days, I just couldn’t work up the energy to do them at all. I definitely want to continue timeboxing, but there’s something I need to add: a schedule. One of the things which made it hard to timebox when I was feeling lazy is that I didn’t have any particular time assigned for it.
My February trial will be to timebox 2 hours every day, but with a catch: Those two hours will be spent right after getting up at 8h every morning! This is a big deal for me, since my schedule until now has been so late. My earliest class is at 13h15 this semester, with all of my other ones starting after 18h! As a result, my sleep schedule’s been to get up around 11-12h every day, which gets me off to a very lazy start. Shifting that back to 8h is going to be a challenge, but fixing my wakeup time should help cement my schedule in place, so that I can start to form new routines. At least I’m getting a good start with today. =)
The reason I want to schedule the timeboxing right after I get up is because there’s no better way to start the day than by getting things done. It initializes your mind for productivity, which influences it for the rest of the day. Also, since I have nothing normally scheduled for that time (except on Saturday, where I might need to compromise), there’s no excuse not to do it.
Programming languages should be simple, based on a small and flexible core. Why is simplicity important? A simple language is easier to learn than a complex one, and a simple language lends itself to a simple implementation, which is easy to modify.
What does it mean for a language to be simple? The way I judge the complexity of a language is by the number of special cases the programmer has to be aware of while using it.
A language such as C++ is definitely not simple. The sheer number of rules you have to know in order to fluently write C++ is astounding, especially where templates come into play. A loose specification, where implementation behaviour is undefined in many error cases, means there are many traps you have to know to avoid, since they can be difficult to find your way out of after you fall into them (see some examples of problems you can run into when dealing with the linker). The slow but incessant growth of features over the years coupled with an obsession for backwards compatibility leads to a monster of a language.
A language like Scheme is comparatively simple. It has a very homogeneous syntax: almost everything is a function call. There are only a few built-in syntactic constructs (things like conditionals and definitions), no keywords at all, and no operators to worry about.
Simplicity Makes Languages Easy to Learn
The most immediate advantage of having a small core language is that it’s easier to learn. If you can learn all of the language constructs and exceptions in half an hour, then you can turn your attention to what’s most important: understanding how you can use the language to write programs. It’s not that a simple programming language makes programming easy, it just prevents it from being artificially difficult. Programming is hard enough without the programming language providing its own obstacles. Programming should not be about memorization, it should be about problem solving.
Simplicity Makes Languages Easy to Modify
If the language is based around a simple core, it’s likely to be easier to implement. Besides saving the initial implementor some amount of work, a small implementation is easier to change. This allows experimentation with new features. It encourages people to make modified versions of the language, which will foster innovation and research. In the long run, that’s good for the future of Computer Science as a whole. For example, though Lisp is a minority language now, its influence is felt all over computing. Wikipedia lists over 15 different Lisp variants, and some of them, such as Common Lisp and Scheme, have more than a dozen implementations.
It’s not likely we’re going to come up with the perfect language anytime soon. By making languages simple, we can at least compromise by making it easy for others to correct the imperfections.
Getting things done is often a problem for me. Not because I can’t work effectively, but because I don’t work effectively. I sit around with a vague idea that I should be working on things, then don’t actually work on them. Instead, I lazily read e-mail or RSS feeds, feeling sort of guilty about not doing what I should. Because of that guilt, I don’t even enjoy being lazy! It’s not that I don’t want to work on things, since once I start something I really get into it and get a lot done. What’s difficult is putting together the energy I need to make myself start working.
What’s lacking is direction. In a work environment, it’s easy to find direction. Since you’re working as part of a team on a larger project, there are always tasks waiting for you. Having other people working around you also provides direction. In university, though, there’s no one around to tell you what to do. You have to provide your own direction, whether it leads to schoolwork or to personal projects.
Timeboxing is a simple concept. Instead of setting achievement-based goals, you set time-based ones. For example, instead of deciding to reach a certain milestone for a school project, you set aside three hours and devote that time entirely to the project.
Timeboxing helps in two ways. First, it forces you to make conscious decisions about how you spend your time. If I want to read RSS feeds, then that’s okay. I’ll just set aside a half-hour and focus on exactly that. Since I’m making that decision consciously, I won’t feel bad about it. The second way it helps is by providing immediate direction. Even an hour devoted to reading RSS feeds or playing video-games is better spent than an hour wasted without a clear sense of direction.
The way I see it, if I can get myself to start working like this, I’ll have no problem getting what I need to done. So, my trial for January will be to time-box a minimum of 3 hours each day, for whatever tasks I choose. It doesn’t have to be 3 hours at once, or all for the same purpose, but the total should be at least 3 hours. Not all of that time has to be school-related, but I’m confident that since I’ll be conciously deciding how to spend my time, work isn’t going to be neglected in favour of leisure.
It’s a bit early to post a new year’s resolution (I think it has to be new years eve >_>), but this one takes a bit of preparation.
In every month of 2009, I’ll run a 30-day trial. Not the shareware kind, the personal development kind. Every month, I’ll make a commitment to do something differently, just for that month (this means that February will actually be a 28-day trial, but oh well).
Having a different goal each month gives the resolution flexibility. If I pick a goal which is too easy, then I can pick a more challenging one the next month. On the other hand, if I pick one which is too hard, well, after 30 days it’s done, and I can move on to something else. 30 days is long enough to form a new habit, but it’s short enough that I’m not stuck with the goal if it doesn’t really work out.
This resolution also has the advantage that I’ll get a variety of experiences from it. Twelve months means twelve experiments with forming habits. Even if only half of them turn out a success, it’ll make a huge difference.
So what’s the preparation? I still have to finish figuring out what do to with the first month XD. I’ll be back later with January’s trial.