Some Analysis of League's Gameplay and Design Philosophies

Hey there, About Game Design returns.

As I mentioned in my previous article (posted quite a while back), I'm going to analyze a few of the key gameplay components and design philosophy Riot Games has built League of Legends around. Keep in mind none of this is confirmed by Riot, they are simply my own musings and analysis! It's up to you to evaluate whether the ideas presented here make sense. In any case, many of the principles I describe here are what League has done right - conventionally accepted game design strategies Riot has followed in its game.

Hopefully these design concepts resonate with you as evidence of what can make a great game. In a future article, I will give my opinions on what League can do better and needs to improve on.

One trait in common between all well-received games is that they have a single core mechanic or objective. It's important to clearly define your fundamental game mechanic and convey that to the player. League does this well - your objective is to destroy the enemy team's towers (and eventually their base) to achieve victory.

The core mechanic is simple and easy to understand. New players instantly know what to do, although they may not know how to do it; there are many different strategies and actions the player can take to achieve the goal of destroying the enemy base (depending on the champions chosen for each team, overall macro-strategy, etc.), and the novelty of approaching the objective in numerous ways keeps players interested.

And every champion brings something new to the table, something fresh - I'm not talking about each hero's gameplay, but rather his/her lore and backstory. Riot has created a wonderful universe with a massive cast of characters, each having a unique place. Each character has his/her own creative design and background; with 117 champions currently released, its extremely likely each player will find a hero they like thematically. Riot has done a great job exploring many fantasy character archetypes in their game, appealing to millions of players with varying tastes and preferences in the process. From a creative design perspective, League of Legends has done well. In LoL, the focus of the game is primarily on the gamplay, not the lore and backstory (for other games, the story is the foremost appeal); but Riot has used the game's story and champion lore to further their goal of creating an immersive gameplay experience.

Yasuo, the Unforgiven. Awesome, badass samurai struggling to restore his honor? Yes please.

League of Legends is an extremely popular game - so popular that's its become arguably the world's foremost esport. LoL is played professionally all around the globe; highly competitive teams within each region battle each other to be eligible to head to the world championship held each fall. It's important to recognize the balance between skill and chance Riot has defined in their game, now accepted internationally as an esport.

In fact, there are almost no game elements that rely on chance in League of Legends. Critical strike chance is probably the only truly RNG mechanic the game has, and even then it's designed to be pseudo-RNG (each successive hit that doesn't crit will increase your chance to crit on your next hit. Likewise, critting consecutively will slightly lower your chance to do so on your next attack). It wouldn't be too far fetched to compare League of Legends to chess - all the game 'pieces' are known in advance - nothing's going to jump out at you; the winner is purely decided through execution, teamplay, and strategy.

And that's what it takes for a game to be accepted competitively - skill has to be the deciding factor. This is an important design consideration in games - the balance between luck and skill. I don't want to go too deeply into this topic (there's tons of great articles out there already on the subject, and I've already discussed it a bit in some earlier posts), but to summarize briefly - luck can be very good design element to introduce. It keeps things fresh, keeps players guessing, and can create surprising and fun situations for the player (e.g. the airdrop crate killstreak in Call of Duty. You could get an AC-130 barrage, or a UAV >_>). Designing their game to be competitive, Riot made the decision to almost entirely eliminate random elements from League. Within the skill-driven gameplay however, Riot has allowed for numerous aspects of skill to influence the outcome.

There are essentially two types of skill in video games - strategic skill and "twitch" skill. Strategic skill is essentially high level macro and decision making ability - players who think deeply about in-game issues, theorycraft about the games they play, and enjoy analyzing the risks and tradeoffs of different choices gravitate towards games with a high degree of strategic skill. On the other hand, "twitch" skill is embodied by games like Rock Band and many first-person-shooters. It's all about precision, timing, and quick reactions to in-game events.

Rock Band, a great example of 'twitch' skill gaming. Timing and rhythm are key!

In League of Legends, both elements of skill are present in abundance. Thus, the game appeals to players from both ends of the spectrum! There's a great deal of strategic decision making to make in the game, whether it be in your team tactics, item builds, or even ability leveling order. Reaction time and precision are also extremely important elements when it comes to landing skillshots and avoiding dangerous abilities your opponents use. Highly cerebral players will enjoy the strategic elements while extremely mechanical gamers will love the thrill of landing that clutch spell. Some degree of competency is required in both areas to succeed, but players can focus on one of these areas to improve on - each player's champion choice may also reflect their preference towards one of these skill 'domains'.

In my opinion, the strongest game design element a developer can include in a game is that of giving the player choices. Game designers should facilitate and encourage players to make choices;  player decision making leads to excellent and robust gameplay. Whether it be in Runes, Masteries, and of course, choosing what champion to play, players have many avenues to make unique and meaningful decisions both in and outside of the actual match.

The final topic I want to discuss isn't exactly a game design element, but it's something which is fundamentally critical to game design all the same - iteration and revision of game mechanics. League of Legends is well known for its game balance patches; but even these patches themselves go through multiple stages of revision and testing before they are pushed onto the live servers. Each champion, during its development, has numerous evaluations and tests done on its creative design as well as gameplay patterns. These tests are conducted in-house and through public beta playtesting. And even after release, the iteration doesn't stop! Community feedback and in-game statistics are analyzed by the designers to further refine the gameplay.

Game design cannot be done in a vacuum; it would be folly to implement things from concept to completion without testing the idea and getting feedback on it at regular and frequent intervals. You can't truly know how a game element works until you playtest it - any number of factors can make the idea come out worse in-game than it sounded in your head.

Riot is fantastic when it comes to practicing the principle of iterative design. Their final releases may take more time than other companies, but the end result is almost always quite polished and clean (and even more so in recent months).

So that's about it for this article, I hope you got something out of it. These are just a few of the game design principles used well in League of Legends, there's tons of other awesome stuff going on (like with social/community interaction, art, etc.). I just wanted to touch on a couple for now, I may revisit this topic again in the future. For my next article, however, we'll switch things up a bit by discussing some of the gameplay in League of Legends which I think could be improved >_>. No game is perfect! (iteration, remember?) It'll be more technical - I'll talk about some specifics within the game - so check back soon.

That's all for now. Leave your comments on this post or a suggestion below, I appreciate any and all feedback! Peace,
Kannan

League of Design

Hey there, About Game Design is back.

So, League of Legends. Currently the most played video game in the world in terms of numbers of hours globally spent in-game. What makes LoL so good? Why are people willing to dress up as Teemo and sit in crowds of over a thousand people to watch a professionally commentated League of Legends match? We probably won't ever discover the reasoning behind the Teemo costume, but there are a number of reasons why the game is played so much. Now, keep in mind I'm just a beginning game designer, by no means an expert on building something like League. But I've got a few ideas as to why the game is so fun and widely played:

• Expansive roster of champions (in-game playable characters) which appeal to many, many different interests that player may have. I'm sure you'll find a character which sparks your interest - and if not, the list is still growing!
• Clear, intuitive gameplay. Well, Riot (the creator of league) has some room to still improve on this, but they've done an amazing job keeping the game clean, minimizing clutter, and emphasizing the core gameplay goal - destroy the enemy nexus, using any means neccessary.
• Skill-driven at its core. In League of Legends, the better player will demonstrate why he/she is stronger at some point in the game. There are very few 'random'/'lucky' mechanics in league; players will vividly see improvements in their gameplay and win/loss record as they continue to play more and get better.
• Free to play. The FTP business model is probably the best method to attract players and make money - you can spend as much or as little on League as you'd like; people from all economic backgrounds, with access to a machine that can run the game, can enjoy league.
• Lots of social interaction. This isn't always a good thing (there's a fair bit of bad publicity about LoL's community), but the team nature of the MOBA genre encourages communication, collaboration, and teamwork in order to achieve victory. Ultimately, no man is an island - people like to interact with each other and do well.
• Constantly updated with new content. Every 2-3 weeks, the game is patched with live balance updates, new artwork, game modes, champions, and more. The game just doesn't get stale.

Thus far I've spoken at a very high level on the reasons for League's popularity. Next time, I'll start to dig into point #2 and try to pull out the core gameplay philosophies in the game underlying systems.

That's it for now.
Peace,
Kannan

Quick Aside - The Goblin Catch Design Experience

Hey guys, wanted to make a quick post on the game design process with a specific example - our good friend Goblin Catch. Also, playtesting OP.

First, you might want to check out the current version here (currently in version 2.5).

Version 1.0, as I discussed in an earlier post, was heavily effected by randomization. Players would simply hit 'reset' until the first goblin that appeared was a purple, and then hope the next two goblins to appear were also purple - that was the optimal strategy, and, when lady luck was smiling upon them, it would yield a fast time. With v2.0 came the advent of the high score board, and now the competition grew even more fierce! Which was a good thing, actually; but with the gate into the high score board simply being randomization (and how much time you put in so you could see the ideal random cases), things were a little frustrating.

One day, I showed Goblin Catch to a couple people. After playing the game, they saw the high score board - and were immediately discouraged. Obtaining a spot on the leaderboard seemed out of reach, or more likely (as I believe they implicitly felt), out of their control. Getting a high score was only feasible if you spent hours on the game hoping for 3 purples in a row all within close proximity to each other.

Seeing some of my players a tad disgruntled, I wanted to change the gameplay a bit. Thus, I implemented 2 changes: 1. Changing the value of the purple goblin to 2 instead of 5, and 2. Decreasing the probability of the rare goblin showing up form 1/5 to 1/6.

The goal of these changes were to shift game away from its reliance on randomization and more towards twitch-skill reaction time (quickly moving the hero character towards the newly spawned goblins). After another day of testing, the high score board has been filled again with extremely fast times - I'm thinking that once again the probability of a rare goblin appearing must be lowered.

So what's the whole point of this post? I suppose it'd have to be the importance of getting people to playtest the game and give their feedback. I had originally thought that Goblin Catch was a completed project. But showing the game to other people allowed me to see the (numerous, *cough*) flaws in the game; without opening the game up for people to play, experiment with, and give comments on, Goblin Catch would've remained an unfun game (games with an element of luck can be fun, but too much reliance on the mechanic leads to frustration >___>).

Anyway, iteration on the game will continue (based on player feedback!). Next post should be the regularly scheduled League post I mentioned. Also, feel free to comment on this blog post with any feedback on Goblin Catch, I'll certainly take a look.

That's all for now - Peace,
Kannan

Skill vs. Luck/Randomization in Game Design Part 2

Alright, back to randomness vs. skill-based play.
One quick thing I want to mention is that all the topics in this blog apply to every kind of game, not just video games - board games, 'real life' games (such as tag), and even card games. Today, I want to talk about 1 card game in particular, probably the most popular trading card game of all time - Magic the Gathering.

In highschool I played Magic quite a bit; a few months ago, I picked it back up again and have been playing on and off. As I'm currently doing research and pondering on game design, I think I'm finally starting to understand some of Magic's nuances.

First and foremost, you will not win every game. It's essentially impossible. Even if you are the "better" player, or if you have a stone-cold superior deck, it's still possible (and even probable), that you can lose: you could get mana screwed (mana is a certain type of card that you need to play your other, main cards), you could have to mulligan multiple times because you lack mana and just slowly lose control of the game after your opponent has card advantage, you could get all of 1 type of mana when you need your other type, or (don't know if I've mentioned this yet) you could get mana screwed.

* Ahem *

Well, if this happens so much, why even play Magic? That doesn't sound like a fun game at all. Turns out there are some things you can do to remedy the possibility of having a bad start, but the real kicker is that, contrary to what most would expect, the variance in your card draws and unpredictability of the game make it pretty darn fun. You never know what kind of starting hand you'll get. You never know what cards you'll draw over the course of the game. Some card effects actually have random results as well! Even if it does happenstance you get 3 lands (i.e. mana; typically a great start) in your opening hand but none over the rest of the game, it's absolutely fine. The core experience is what's fun. And maybe next game, you'll get all your super strong cards and do well.

I suppose what I want to point out about Magic is that the randomness and variance are a core part of the game and are essential components in what makes it so much fun. There's always a possibility that a lesser skilled player could come out with the match if he/she gets a good draw. It's exciting, and keeps players coming back.

Ral Zarek. Quite possibly one of the most fun cards to play, specifically because of his completely random final ability. Fun times (both good and bad) were had.

A little while back, I had a discussion with a friend of mine about randomness vs. skill in Magic. He (a very experienced Magic player) told me it was about 70-30 randomness - skill. At first, this notion repulsed me. 70% luck? Really? For a brief moment, I considered dropping Magic because of this imbalance.

Soon after, I realized that it's simply the nature of the game's design and formula. It keeps things interesting. I can certainly say that I have triumphed against opponents who (very clearly) knew more about and were better at the game than I was, because of this element of randomness. And it felt good! But the better player, given enough games to offset variance, will eventually win (and most matches are played in best of 3's, so that helps offset the random draws as well).

So in summary, Magic the Gathering is an example of a successful game weighted more towards "luck" rather than skill. But, skill is still an important component and is integral to each match's winner. The game was simply made to have this particular balance between the two components - and it's a winning formula. The game is fantastic.

Next week, I'll discuss a game weighted more on the side skill at its foundation - League of Legends. LoL is a personal favorite of mine, so watch out for that post.

Peace,
KR

Skill vs. Luck/Randomization in Game Design Part 1

Yo, I'm back with another post. I'm gonna start this one off with a quick story.

Several weeks ago, I made a small game called Goblin Catch with some friends. It was meant to just be a 'weekend hack' kind of thing, a small game that someone could burn 4-5 minutes on and have completely discovered its nuances. The objective of the game is to get a score of 15 by collecting goblins; but I guess one could say the actual objective is to beat the high score and collect the goblins in the shortest time. If you're interested in playing it, you can find it here.

Back at uni, I told a couple of other people about it and they tried it out, and I got a lot of very interesting feedback on the game, some good, some bad.

First off, Goblin Catch is almost entirely luck based. There's no real element of skill required, no mechanical prowess necessary, no real opposition to your actions by the game which you have to surmount, and very little meta-strategy. The reason I say very little, is that, in fact, there is a strategy that you can employ to maximize your chances of beating the high score, without wasting a lot of time - can you think of it? (Hint: make use of the reset button)

Watching some of my friends play the game led me to realize that luck-based games like this can be fun, but they can also be extremely frustrating. They can be fun because the results are unpredictable - you could get 3 purples in a row on one try and demolish the high score, and then a completely horrible finish time on the next (say, if you get 15 green goblins in a row). Having a skill-based game framework seems much more consistent and appealing, no?

Well, maybe. Chess, a game in which every single variable is known from the beginning of the game, is one of the most popular games played worldwide. However, it loses some charm because it can sometimes get predictable (some people would argue there is almost always 'one correct move' in a given situation). Thus, we see that completely skill based games can have their flaws as well.

I think that keeping a game interesting for a long time (high replayability) requires some element of randomness and variance, some particular aspect of the game that can change contrary to the player's expectations - or maybe even providing room for the player to vary his/her own actions, such as numerous customization options.

For now, I'll just say this: when designing a game, you want to minimize frustration and maximize fun for players - that's a fair overarching goal (of course, in order to achieve this in the context of your game, you'll have to deal with a boatload of unique design issues - but that's for another day). I think there has to be a balance between skill and luck in every game, allowing players to enjoy the game and succeed when they have achieved mastery, but still have that varying element that keeps players coming back and trying to surpass their own accomplishments.

That's a long post ^, I'll stop here, picking up next week in part 2, when I talk a little bit about the card game Magic the Gathering.

Peace,
Kannan

The Return of About Game Design and the Importance of Visual Dazzle

Hiya Folks, it's been quite a while. After an almost 2-month hiatus, About Game Design is back! Hopefully, with more frequent updates >_>

In any case, today I want to talk about Dazzle. Yes, dazzle - not the foremost element of development that comes to mind when you're thinking game design, but its significance can't be understated. 

A couple weeks ago, I picked up Dead Space 3 from the Origin Humble Bundle (Humble Bundles are great by the way - get cheap games, and almost all of the proceeds go to charities of your choice!). To quickly summarize, the game follows space engineer Isaac Clarke as he travels to an isolated ice planet to save the world from a zombie threat.

The key word in the above description is 'engineer'. Throughout the game, you'll be repairing ships, fixing energy issues onboard, hacking electrical interfaces (via a nifty little circuit minigame), and in general performing a ton of random repair tasks in order to advance the story and reach the end of your quest. After solving problem after problem, the game's formula becomes a little predictable: fix an engineering problem in your current location -> journey to a new location -> combat some zombies -> fix some problems there -> rinse and repeat. You'd think this would be a little boring, no?

Well, yes and no. It's true that the formula gets a tad stale. But there's something which makes each new rotation in this cycle absolutely amazing - Dazzle. The new environments you visit on each leg of your quest are absolutely stunning. Varied, vibrant, and bursting with enough detail to make you think you were in the game yourself, Dead Space 3 really impresses visually. Take a look at this scenic view from the planet's surface:

Take a break from fighting zombies, and enjoy the sunset.

I quite literally forgot my current objective (and whatever tediousness they entailed) at some points and just took in the environment - truly dazzling detail from the developers of Dead Space 3. I absolutely didn't mind following the frequent repair quests if it led me to environments like the one above.

In summary, dazzling your players is a great idea. Aesthetic appeal isn't by any means the end-all be-all of a game (I can assure you that I've played great looking games that were not fun at all, and low-res games which were so well designed I could play for hours), but it can have a big impact - and maybe shore up some other shortcomings of your game.

Try to make your games/apps/websites visually appealing! You might be surprised at how well your players respond.

Peace,
Kannan

More Than the Sum of Its Parts

So there's a been a small hiatus on this blog - but we're back, and better than ever.

Last blog post, we talked about achievements, and how they can help in the classroom. I want to address an idea in the same vein as achievements - the notion of a reward system - and how tunneling on a reward system may be the wrong way to go.

Let's backtrack a bit. I mentioned earlier on that I am working on the concept of Gamification. This means, at its core, bringing games into other parts of our everyday life - in this case, integrating games with CS education.

To most people, gamification simply means implementing a reward system. Implementing a reward system is all well and good, and nobody is going to dispute that a great reward system is part of games; but there needs to be something more.

Preston Johnson at Sundog emphasizes that games are more than the sum of their elements. He asserts "Well-designed experiences - not elements - are what separate a good game from a great one."

Just standing at the top of a leaderboard doesn't necessarily make education amazingly game-like or fun. Both Preston Johnson and Jon Radoff (an influential individual in the game design sphere - you can read about him- if the website works - here, and watch an interview here) believe that it is the player's experience which is most important. "It's the journey, characters, and story that make games engaging. A holistic understanding of how players experience the game from start to end is crucial to effective game design."

So indeed, achievements and leveling rewards in the classroom setting are great. They provide motivation to get the student going. But there needs to be something more in order to make the gamified experience memorable, powerful, and awesome. Radoff insists that storytelling and player immersion is the way to go, and that may very well be the case; incorporating an interesting backstory in education could inspire the students, with Epic Meaning driving their actions. Or maybe the existing elements could build on top of one another, creating a seamless player experience that keeps each person anticipating what's to come.

Not sure yet. I'm still searching!

Thanks for reading. I'm trying to keep the blog posts shorter, but more frequent. Be on the lookout for more.

Peace,
KR

Achievements

Let's talk about Achievements.

Some people love achievements in their games, going out of their way to try and acquire every single one; others care very little for them, and are more interested  in the story/plotline or the actual game mechanics.
But I think they are very few people do who not enjoy achievements at all- almost everyone can appreciate a notification popping up, congratulating you on having completed a task!

 

This makes achievements the natural first option when trying to create game-like educational software. Achievements appeal to pretty much everyone, and have plenty of depth in terms of how they are earned, how many there, and their own tiers/classes.

I'd like to reference a piece from the Gamification Wiki on Acheivements, which you can check out here. It has some great questions to consider for a game designer wanting to incorporate Achievements into a game. Highlights include:

• Do you give Achievements often?
• Have you implemented a place for players to collect and show their Achievements, such as a Trophy Case?
• Do you have an Achievement Map to show the Achievements you have, ones you could earn, and available info on how you can earn them?
• Have you implemented Achievement Tiers such as the common ones like "Easy, Medium, Hard, Insane, and Unknown?"
• Do you use clever names and graphics on your Achievements to add Character? How about humor or wit not only in the names or graphics but also in how you obtain the Achievements?

I want to touch on that last one in particular. Whenever I think of achievements, I think of Xbox's Achievement/Gamerscore implementation and Playstation's Trophies - these two systems have pretty much shaped how I view modern achievements, primarily because they were so smooth, well designed, and the character of the achievements was extremely well done. For example, consider the game inFamous for the PS3. In the game, the player (endowed with the power to control electricity) acquires a power which allows for limited levitation/gliding, a useful ability when trying to get somewhere quickly. When the player travels a certain total amount of distance solely by using this power, the "Frequent Flyer" Trophy is awarded. All of the achievements in the game have some kind of unique, funny, or interesting title, and it's always fun for the player to discover these awards.

 

I can go into great detail about all the different facets of a great Achievement System, but I'll just say a little bit more to wrap up: Achievements are almost always great game elements to incorporate. They appeal to pretty much everyone, and even more so to those players and perfectionists who strive for 100% completion. Collecting things is fun. Game designers have to make sure to not only make the achievements themselves interesting, but the journey to obtain them fun as well.

This will be the first in series of posts describing various Game Elements, such as Achievements. Check back soon!
Peace,
KR

Core Aspects of an Introduction to Programming Game

Just wanted to put up a quick post today going over the most important features an educational programming game should have. These are the aspects of the game most likely to be represented in the final design, are quite broad and general, and are shared among many games already in existence.

The first requirement for this game is the most apparent - the game must facilitate the learning of, or cover over the course of its play, the core ideas and concepts of the introductory programming course. All the concepts and information that were previously taught to the students via lecture slides should ideally be represented in some way, shape, or form in the game (for loops, conditionals, basic algorithm design, critical thinking, etc.). Lesson plans may change with the introduction of this new, gamified medium of learning, but those key topics should still be around.

Next, as in most games, there should be progression. This could be with regards to the levels, in the equipment that a player character obtains, etc. (this will all depend on the actual game of course), but there will be some development. As the student/player learns more and more about coding, his/her capabilities and skill will increase. The difficulty and challenge of the game must evolve along with the player; exposure to more thought provoking programming problems over the course of the game is guaranteed.

Rather than something that should be included in the game, I want to propose that there be a distinct lack of chance in a programming game. Many popular games have an interesting balance between skill and chance; random events can keep games interesting and fun, as there will always be a chance for someone to win out of nowhere (we've all experienced this). However, when it comes to education, students should always be able to concretely see the correlation between their existing knowledge, preparation efforts, and performance with their success or failure. A good educational game, competitive or otherwise, should 100% of the time reward players who have a greater understanding of the subject material. Now, I am not completely against random elements in an educational game (e.g. which problem is given to a student is chosen from a question bank at random), but when it comes to performance, results, and their corresponding evaluations, influential nondeterministic elements should be absent.

 Finally, as with almost all games, a programming game should provide immediate feedback. It is often the case in the classroom that coding assignments take some time to grade, which is suboptimal when it comes to crystallizing a student's understanding of a topic. In games, the immediate in-game responses to whatever the player is doing helps to illuminate the correct path. The ideal programming game should be based in an environment which can very quickly provide feedback on the student's solution to a programming problem.

That's all for now! The core aspects listed above may not be comprehensive - I will come back and update if need be.
Peace,
KR

Formal Elements of Games

What is a game made of? Well of course, there's the graphics, the physics engine, etc., but I'm talking about what really defines a game as a game.

From Game Design Workshop: Designing, Prototyping, and Playtesting Games, Fullerton/Swain/Hoffman, we have a list of the formal elements that make up a game. There are also dramatic elements (Story, Characters, and more), but I will skip over them for now and discuss just these core components, and how they relate to a potential programming game.

Formal Elements

1. Players
2. Objectives
3. Procedures
4. Rules
5. Resources
6. Conflict
7. Boundaries
8. Outcome 

For better or worse, I will consolidate Procedures, Rules, and Boundaries into just Rules. The three components are relatively similar, and though they each have their own nuances and deeper meaning, for simplicity's sake I group them as one. That leaves us with Players, Objectives, Rules, Resources, Conflict, and Outcome.

 In the context of a programming game, I am immediately inclined, for whatever reason, to design it for a single player (though from my own experience, I have enjoyed multiplayer titles quite a bit more). The question remains whether, from an educational standpoint, students will be better empowered playing/learning solo or in a group.

The overarching objective of this game is to learn programming...but insofar as the actual game's goal, that is still up in the air. But, we do know that every game must have an objective of some sort, a goal to be reached. The Rules and Resources with regards to this game are similarly still in development. The primary challenge in the design of this game (or any game for that matter) likely lies in the conceptualization of these components.

Next, we have conflict. This could simply be PvE, or, if the game is multiplayer, PvP. In either case, there must be some interesting challenge or obstacle impeding the player's "natural" progress. This is probably the most interesting part of game design for me; designing a programming game with some interesting problems to solve will be a fun task.

The last, and potentially most controversial formal element of games is the Outcome; in other words, the conditions for winning or losing. In games, having an unequal outcome is all well and good - many people play games for a sense of achievement, they want to be competitive. But competition has mixed results when it comes to learning. The challenge here will be balancing outcome, a core aspect of games, with the educational goal of learning and acquiring skills and knowledge in a fun way.

That's all for now, still have many more updates to come. If you want to know more about these game elements, I would suggest taking a look at Game Design Workshop or reading this wikipedia article: http://en.wikipedia.org/wiki/Game.

Peace,
KR

Greetings

 Obligatory "Hello World"

First blog post, just testing things out. I've created this blog to explore the art of game design and record my thoughts and ideas on the subject. I'll mainly be using this an open journal for my research at university, but I might post about some related game design/game making topics as well.

Thanks for visiting. Updates will come every few days or so, check back soon.

Peace,
KR