Still Protesting? Facebook Will Soon Force You To Switch To Timeline

Over the next few months, anyone still refusing to voluntarily switch to the Timeline profile redesign will be automatically migrated, Facebook tells me. Users could choose to adopt the redesign starting in January, but there have been some hold-outs who didn’t want their whole life becoming easier to access, or just hated change.

Soon they won’t have a choice, though. Facebook revealed to me it plans to complete the Timeline rollout by this fall as part of its photo revamp this morning. By waiting to minimizing the number of users it’s forcing to switch, and doing it all gradually, Facebook will have successfully avoided the wildfire protests that characterized its early years.

Source and Read more:

Hotmail = Outlook

Great… after the well trusted since 1996 invented Hotmail.

Its going to change, my first looks where that its not to great how they changed it.

Yes it is faster, yes some features are better like when deleting a mail going back to the inbox instead next mail. But why they had to mess up the GUI of messenger in your email. I loved the whtite background instead of now the horrible grey background.

Once u changed it, u cant go back…

By the end of this year everybody will be transfered to the new Outlook, plus allready 1 million user registrated with @outlook extensions in their email.
Your personal @hotmail or @msn will not be changed.

YoYo Games at GDC Europe

GameMaker: Studio Demos Taking Place at YoYo Games Booth No. 160 August 13 & 14

YoYo Games today announces that Russell Kay, chief technology officer and Mike Dailly, head of development, will present at The Game Developers Conference™ Europe (GDC Europe), taking place in Cologne, Germany August 13-15. Both Kay and Daily will present on two aspects of modern game development with insights based in part on their work developing recently launched GameMaker: Studio, the company’s cross-platform game development technology. YoYo Games’ booth is No. 160 and will be open August 13 and 14 for demos of GameMaker: Studio and soon-to-be-announced ground-breaking functionality.

In a presentation titled “Applying Retro Techniques to HTML5 Development,” Kay draws on tips and tricks that can now be used to ensure fluid, high-quality gaming experiences in HTML5. Dailly will be hosting another technical talk titled “The Voodoo Art of Dynamic WebGL” where he’ll be discussing WebGL and how to harness its power at a low level for the development of 2D games, and 3D particle effects in a 2D game context.

  • “Applying Retro Techniques to HTML5 Development” with Russell Kay – Monday, August 13 at 5:30 p.m.
  • “The Voodoo Art of Dynamic WebGL” with Mike Dailly – Tuesday, August 14 at 2:30 p.m.

For more about the YoYo Games presentations at GDC Europe, please visit:

GDC Europe is the largest professionals-only games industry event in Europe. GDC Europe is the essential platform for learning, inspiration and networking for the creators of computer, console, handheld, mobile, smartphone/tablet, social, and online games in Europe.


10 Steps to Great Game Design

by C.E. Forman

You’ve solved every Infocom game ever released. You’ve FTP’d countless text adventure games from Internet sites in a desperate attempt to quench your insatiable thirst for interactive fiction, but still it’s not enough. So you decide to take the final step, to write your own parser adventure. But–how do you know for sure that people will like it? How can you avoid making the same mistakes you’ve seen in many of the quests you’ve been playing for years? What exactly constitutes a “good” text adventure game?

That’s what I’m here to help you with. I’ve taken it upon myself to analyze my favorite works of interactive fiction, determine why they’re my faves, and compile a list of their common characteristics that first-time adventure writers can use for reference.

Keep in mind that this is not an article on programming a game. These ten tips deal exclusively with game design and the authoring of the game’s storyline. My intent here is to point out the most common mistakes beginners make, and identify methods of avoiding falling into these traps.

You may be asking yourself, “Who is this guy anyway? I’ve never heard of him in my entire life!” True, true. I have been a fan of interactive fiction since I was seven years old, and I have even written a couple of my own adventures. That you’ve never seen my name anywhere should tell you that my games have fallen prey to most if not all of the problems I’m pointing out in this article. (Of course, I was confined to using BASIC as my sole programming language. Plus I was only twelve at the time.) Right now, I’m working on a couple of new games, and perhaps this time they’ll turn out to be quite a bit better. Hopefully you’ll be able to learn from my mistakes, too.

1. Develop a good parser.

This is the single most important element of any work of interactive fiction. Unfortunately, it’s also the one most frequently neglected by beginners. Even the most cleverly designed adventure isn’t going to hold players’ interest for very long if they have trouble communicating what they want to do. The earliest adventure games, such as the original “Adventure in Colossal Cave” and the Scott Adams series, used crude, verb-and-noun parsers that accepted only two words in each command. Due to the limitations of computers in those days, a standard parser’s vocabulary was often very limited, leaving gamers dissatisfied.

The Zork Implementation Parser introduced by Infocom in the late 1970s is really the accepted standard for parsers today. If you’re using an IF design tool such as Inform or TADS, developing a good parser isn’t as much of a problem. If, on the other hand, you’ve decided to write your own parser, pick yourself up a good thesaurus and use several common synonyms for each noun and verb. Make your puzzles the challenge of your adventure; don’t force players to “guess the verb.”

In addition, the more options you can supply your parser with, the better. An “undo” command, built-in hints, the ability to allow players to configure the function keys as typing shortcuts, and automatic mapping will all contribute to the reduction of frustration on the part of the player.

2. Use good puzzle structuring.

Don’t just force players to wander aimlessly from one puzzle to the next, halting their progress completely until they solve the only available puzzle. Branch out your puzzle structure and make it as nonlinear as possible. Interweave your puzzles with one another and allow players multiple paths through the adventure. That is, don’t make players solve the puzzles in the same order every time; give them some flexibility. The only point in the game where there should be only one path for the player to follow is at the conclusion, where all the branches of puzzles come together to form a final challenge.

Puzzle connectivity is also important. Make sure each puzzle “fits in” with all the others. If you have an extremely challenging puzzle, but you can’t make it fit logically into your adventure, don’t just throw it in for the sake of using it. Save it and use it in another game, where it is appropriate. One of the biggest abuses of this that I’ve seen comes in the form of mazes. Often adventure writers will simply throw in a maze to make the game more difficult, when in reality it is totally inappropriate and has nothing to do with the game at all. Making maps of games is tedious, and mazes are generally frowned upon in adventure games today, unless they have a truly unique twist (such as the catacombs in “Leather Goddesses of Phobos”), or can be solved without mapping (such as the wet tunnels in “The Lurking Horror”). In summary, designers should ask themselves this: “Is this puzzle connected to the game in some way, or is it in the game merely for the sake of its own existence?” If it’s the latter, you should probably consider scrapping it.

3. Balance the difficulty of your puzzles.

What’s the fun of getting all the way to the end of an adventure only to discover that the final challenge is the easiest puzzle in the history of the universe? In most cases, the best adventure games are the ones that curve the difficulty of their puzzles. Keep ’em fairly simple at first, to allow the player to get into the game, then gradually raise the challenge as players go deeper into it. Don’t get me wrong. It’s perfectly okay to throw in a difficult or obscure puzzle or two in the early stages of the game, but the key is not to overwhelm the player at the outset.

Of course, the primary deciding factor as to the difficulty of the puzzles should be how difficult you’ve chosen to make the game as a whole. If you’re writing for expert players, design your puzzles accordingly. If beginners are your target audience, include a lot of simple, one- or two- step puzzles. In all cases, after a particularly arduous puzzle, reward the player with a few simpler ones. You’d be surprised at how many players lose interest when a game’s puzzles aren’t balanced.

4. Make your world and puzzles logical

This one is basically just common sense, but it’s still sometimes overlooked. If you’re writing a sci-fi adventure, pay attention to the laws of physics. Don’t let players enter the vacuum of space and survive without spacesuits. Realism is less of a problem in fantasy games, as much can be justified by the use of magic. The point, though, is to make sure everything makes sense in some way. This is especially important in the area of puzzles. Avoid making players do things that have no logic or purpose behind them. The more realistic your adventure, the more it will draw players in.

5. Be descriptive.

You’ve created a whole other world, so why not let the player enjoy the beauty of it? How many times have you played a game with such lame location descriptions as “You are in a forest,” “You are at the bottom of a tall cliff,” “You are outside a cave,” etc.? The term “interactive fiction” is not an arbitrary one–players are essentially exploring a form of writing, much like a good novel, and adding their own input to it. So let the player see the world you’ve created, much like your favorite fiction authors let you see theirs.

Take care, though, not to overwhelm your players with prose. If you give them little opportunity to interact, they just might decide that they may as well be reading a book. Don’t get too bogged down in descriptions. Usually half the screen is the absolute maximum for a room or object description, and this limit should only be reached on rare occasions. However, if a particular puzzle requires a lot of text in order for the player to see it, one or two full screens are acceptable. (A good example of this case is the mirror box in “Zork III”.) Don’t make players read the text over and over unless they want to, though. Make sure your parser has the option of changing the length of room descriptions. Using phrases such as “You are in the forest” the second time a player goes there is perfectly acceptable. (Just make sure that players can still get a better description if they want it.)

While we’re at it, I’d like to mention one variation on this subject. Most players, when writing good room descriptions, like to include several objects or features in each location (for example, a tavern might have a fireplace, a bar, and several tables and stools). Nothing is more aggravating than typing “EXAMINE THE STOOLS” only to be told, “I don’t know the word ‘stools.'” This is guaranteed to instantaneously shatter the fantasy and destroy any hope of players ever really getting into the game. Do this enough, and you’ll alienate them forever. If you’re going to put an object in the location’s description, you’d better let the player interact with it, even if it’s only in a limited way. Just a message saying, “There’s nothing special about the stools.” will suffice.

Incidentally, I feel that this is one of the biggest problems with the Zork-based MUDs I’ve played. Players see that term, “Zork-based,” and they telnet in expecting the same level of realism that Infocom gave us, and unfortunately, they rarely, if ever, get it. I myself have on occasion experienced difficulty in simply trying to interact with what the game claims is in the scene with me, and I’m afraid this is the rule rather than the exception.

6. Be fair to the player.

I know, I know. Life isn’t fair. Never has been, never will be. But adventure games aren’t real life; they’re a form of entertainment. And the only way players will be entertained is if they’re treated fairly. Here are some general guidelines you should follow to ensure that this is the case:

  • Don’t let the game get into an unsolvable state too much, without giving the player some indication of it. There’s no definite line here, so you’ll have to use your own judgment. As an example, consider the KULCAD scroll in Infocom’s “Enchanter”. (Warning! Spoiler to follow…) You are supposed to use this spell to dispel the illusion of the infinite winding staircase, as this is the only way to overcome this particular obstacle. However, you can also use KULCAD to get rid of the guarded doorway and the Gordian Knot around the jeweled box. If you do one of these, though, the scroll is gone and you can’t win the game. Despite the frustration that could be caused by this, I still don’t consider it unfair, because if you use the spell on anything other than the stairs, your master Belboz will appear before you and warn you that the evil Krill has been alerted to your presence. You receive a definite hint that maybe there was a better way. On the other hand, I’ve heard numerous complaints about the game “Curses” because you can inadvertently do something out of sequence and blow any chance of being able to win, and no indication whatsoever is given. So save yourself and your players a lot of trouble, and give some kind of message if they unintentionally do something to get themselves stuck. (On the other hand, throwing all your possessions off a cliff is not a very smart move to begin with, and players should be able to figure this out without a hint. Only tell them they’ve screwed up big-time if there’s a chance they can’t determine that for themselves.) Incidentally, a good way to allow players to keep going after they’ve lost an item is to allow them to re-obtain the item in the place they originally got it. For instance, allow them to pick another apple off the tree if they eat or lose the one they originally got. However, when you’re dealing with a unique item, such as the KULCAD scroll, this isn’t a feasible option. Again, you’ll have to use your own judgment here.
  • Don’t force the player to have too much foresight. Inventory management is a crucial part of an adventure game in which the number of things a player can carry is limited. Often players will wander into a new location and only be able to take so much along with him. Obviously, if they’re going into a dungeon they’ll need a light source, a weapon, and probably some food and water, but if they’re going to need something less obvious, you’d be wise to provide a hint beforehand. Of course, players can always restore, but going through a lot of moves to get back to where they was before can be frustrating, and too many save files can become difficult to keep track of. It’s best to give players a general idea of which items they won’t need and thus can leave behind. Don’t make them pick and choose too much. A few very good games I’ve seen are designed so that the player’s inventory is pretty much managed as the game progresses. That is, the player uses two items to solve a puzzle, thus removing them from his inventory. Then she finds another object and adds it, and later gets rid of it in another puzzle, and so on. If you have items that don’t have multiple uses, this is a good technique to use.
  • Don’t overwhelm players at the start. If you have a large area they can explore in the beginning, you’d be wise to point them in the right direction to start with. Legend Entertainment’s “TimeQuest” is a perfect example of this. With 80 different time-places to visit, any of which can be reached from the beginning, it’s vast enough to make the player feel burdened. But this game directs you to Rome in 44 B.C. from the start, which gives them a sense of direction and helps you establish a path through the game. In addition, the most crucial time-places are all listed in the game’s documentation, so the player knows where the important places are. This makes it easier to get started.
  • Don’t put off the entire reward until the end. Congratulate players when they solve a difficult puzzle, possibly by giving them a special item or power. According to Joseph Campbell’s monomyth, the challenges a hero faces become more and more difficult as his quest continues, but the rewards become greater. This should apply to adventure games as well.
  • Don’t create puzzles that absolutely have to be solved within a specific time frame, unless you give the player a reasonable hint.
  • Include good error messages in your program to tell players if they’re doing something wrong, but don’t insult players in the process. Be clever, but not verbally abusive.
  • Random events are good for spicing up adventure games, but never, EVER base the decision of whether a player lives or dies upon the outcome of a random-number generator. I mention this because I did it once. The player had to cross a pit by placing a wooden plank over it and then walking across. But you fell in 1f the time anyway. Talk about frustrating! The only instance where this is at all acceptable is when there is an alternative solution that is not random. For example, in Sorcerer, players have a 10% chance of successfully jumping a gorge, but if they use a flying spell, they’ll get across every time.

You might be saying, “Well, this is my game, so I’ll do whatever the hell I want, and I don’t care whether the player thinks it’s fair or not!” Keep sending this attitude, and pretty soon you won’t have any players who care about finishing your adventure. Book authors who don’t show respect for their readers don’t stay book authors for very long. The same holds true for interactive fiction writers. Players are your lifeblood; they keep your game alive. If you want to write games solely for your own pleasure, that’s fine, but you won’t gain any recognition from doing it. Treat your players as you would treat a paying customer, because after all, that’s essentially what they are.

7. Don’t be afraid to kill a player off.

At the same time, don’t hold the player’s hand all the way through the game. Let them experience a game death if their actions aren’t clever enough. Dying is a natural part of adventure games. Can you picture what the Zork Trilogy would be like without the constant threat of being eaten by a grue in a dark place? And just try to imagine “The Lurking Horror” without death! Which would you rather see after doing something intentionally stupid in an adventure–a detailed, possibly amusing, account of your alter-ego’s untimely demise? Or a lame message saying, “That would kill you, so I’m not even going to let you try it”? Believe it or not, it’s FUN to try to find new and inventive ways to kill off your character (especially after you’ve already finished the game). Pampering players with feelings of invincibility is only going to make them severely disappointed. And besides, this is one of the few ways you can get away with murder nowadays. If you’ve put an UNDO command into your game, don’t be afraid to let players use it.

8. Concentrate equally on creating challenges and building the story.

Puzzles are fun, but the story itself should be the main point of an adventure game. Rather than having the player wander aimlessly around solving puzzles, develop the story as the player moves along. An unexpected plot twist or the introduction of a new NPC can really liven things up, especially when it occurs in the midst of a good puzzle. Puzzles alone can only carry a game so far.

Another thing to keep in mind is that a game should have a good introduction and ending. Actually, an introduction is optional. Some writers may prefer to simply have the game begin as soon as it loads, much like “Zork I”, while others may choose to follow the route of “Beyond Zork” and have introductory text spanning several screens. A few games, such as “Zork Zero” and “Demon’s Tomb”, even have short prologues–opening sequences which play much like the game itself, but which exist for only a limited number of terms. Any of these methods will suffice.

A good ending, though, is indispensable. Is it worth struggling through a game just to be rewarded with the words, “Congratulations, you win”? A good game ending should tie up any and all loose ends the story may still have, pave the way for the sequel if you’re writing a series of games, and leave players feeling as though they have truly accomplished something. Good endings will be read again and again by players, but I can guarantee that a lame ending will only be seen once.

9. Include good information sources in your game.

Most of the time, when writing the game’s introduction, you’ll want to tell the players only so much about your world. Let them learn the various intricacies and details of it themselves. If your world is vast and complex, build several sources of information into your game to help the player accomplish this. You could implement an encyclopedia (Infocom uses these in several games), newspapers, a computer database, or some other form of information storage (the tape spools in Stationfall come to mind). In addition, you might want to make one or more characters act as primary information sources. The player could then ask those characters about various people, places, or things in the game. The more you tell the player about your world, the more complex and realistic it will appear.

10. Keep the game’s longevity intact.

A lot of good adventure games become dust collectors after players have solved them. Often this can be prevented, or at least delayed, by a little extra effort on the part of the author. Give some of your puzzles multiple solutions. Think up imaginative ways of dying and humorous tricks for the player to try. Some adventures even have multiple endings depending on various things the player has done (or not done) during the course of the game. All of these things can keep players interested for quite some time after they’ve been through the entire game. The “Zork” and “Enchanter” series are particularly good examples of this tip. I’m still finding things buried in them that I never knew existed. A little extra programming can go a long way.

If you see yourself making any of these mistakes, you might consider rethinking at least part of your original design. Designing a good text adventure is a long, complicated, involving, and extremely frustrating task, but in the end it can be very rewarding. Good interactive fiction is always in demand, and I sincerely hope I have enlightened you and guided you toward successfully creating your own.


Joomla! 3.0 Alpha Released

Joomla! 3.0 Alpha-1 Released

The Joomla Project is pleased to announce the availability of Joomla 3.0 Alpha 1 for download.

What is this release for?

There is one goal for this release: to allow advance testing of custom extensions so that extension developers can report any problems well before the final release. This release includes most of the platform changes that will be included with version 3.0.0. Some of these changes will require small changes to extensions. For a complete list of known backward compatibility issues for version 3.0 see Potential backward compatibility issues in Joomla 3.0 and Joomla Platform 12.1 in the documentation site.

For known issues with the 3.0 alpha-1 release, see the version 3.0 Alpha-1 FAQ in the documentation site.

Click here to download.

What is this release NOT for?

This alpha version of Joomla 3.0 is not suitable for production sites. It is for testing only.

When is the final release due?

Joomla 3.0.0 (general availability) is due to be released on or about 24 September 2012. The planned milestones are:

  • on or about 23 July – Joomla 3.0 alpha-2 released for public testing. This will include new user-interface enhancements.
  • mid-August – Feature freeze to prepare for beta release
  • late-Autust – Joomla 3.0 beta 1 to be released for public testing
  • on or about 24 September – Joomla 3.0.0 released

Please note that dates may be subject to change depending on availability of volunteers and circumstances beyond our control.

Should I plan to upgrade to Joomla 3.0?

Version 3.0 will be a standard-term-support (STS) release. If you are running an existing production site on version 2.5, you will probably not want to update to version 3.0. Instead, you will likely want to wait and eventually update it to version 3.5, the next long-term-support (LTS) release. Note that the 3.0 update will not show by default in the auto-updates in the Joomla! Update. By default, version 2.5.x updates will show.

Users who decide to use version 3.0 will need to update to versions 3.1 and 3.5 when these become available. Version 3.0 support will end 30 days after version 3.1 is released.

How do I upgrade to Joomla 3.0?

Depending on the extensions you have installed, it may not be possible to update your site from 2.5 to 3.0 until your extensions have version 3.0-compatible updates available. More information on that will be available before 3.0 is released.

If you are using Joomla 1.5 then you will need to migrate your site to version 2.5 before updating to 3.0.

What’s new in Joomla 3.0 so far?

So far, the only features that have been committed to version 3.0 relate to the new version 12 of the platform. Other features are expected to be committed before the alpha-2 release.

What happens to Joomla 2.5?

Version 2.5 is a long-term-support (LTS) release and will be supported at least until September 2013. The exact end of support for version 2.5 will be announced later.

How can you help Joomla development?

The great news is you don’t have to be a developer to help build Joomla. The Joomla Bug Squad is one of the most active teams in the Joomla development process and is always looking for people (not just developers) that can help with sorting bug reports, coding patches and testing solutions. It’s a great way for increasing your working knowledge of Joomla, and also a great way to meet knew people from all around the world.

If you are interested, please read about us on the Joomla Wiki and, if you wish to join, email
Mark Dexter
This email address is being protected from spambots. You need JavaScript enabled to view it.

You can also help Joomla development by thanking those involved in the many areas of the process. In the past year, for example, over 875 bugs have been fixed by the Bug Squad. The project also wants to thank all of the people that have taken the time to prepare and submit work to be included in Joomla 3.0, and to those that have worked very hard on the Joomla Platform project.


PHP Update: PHP Version 5.4.5

Another update for PHP 5 here is the complete changelog for who is intrested in it:

PHP 5 ChangeLog

Version 5.4.5


  • Core
    • Fixed bug #62443 (Crypt SHA256/512 Segfaults With Malformed Salt)
    • Fixed bug #62432 (ReflectionMethod random corrupt memory on high concurrent)
    • Fixed bug #62373 (serialize() generates wrong reference to the object).
    • Fixed bug #62357 (compile failure: (S) Arguments missing for built-in function __memcmp)
    • Fixed bug #61998 (Using traits with method aliases appears to result in crash during execution)
    • Fixed bug #51094 (parse_ini_file() with INI_SCANNER_RAW cuts a value that includes a semi-colon)
    • Fixed potential overflow in _php_stream_scandir (CVE-2012-2688)
  • EXIF
    • Fixed information leak in ext exif
  • FPM
    • Fixed bug #62205 (php-fpm segfaults (null passed to strstr)
    • Fixed bug #62160 (Add process.priority to set nice(2) priorities)
    • Fixed bug #62153 (when using unix sockets, multiples FPM instances)
    • Fixed bug #62033 (php-fpm exits with status 0 on some failures to start)
    • Fixed bug #61839 (Unable to cross-compile PHP with –enable-fpm)
    • Fixed bug #61835 (php-fpm is not allowed to run as root)
    • Fixed bug #61295 (php-fpm should not fail with commented ‘user’
    • Fixed bug #61218 (FPM drops connection while receiving some binary values in FastCGI requests)
    • Fixed bug #61045 (fpm don’t send error log to fastcgi clients). (fat) for non-root start)
    • Fixed bug #61026 (FPM pools can listen on the same address). (fat) can be launched without errors)
  • Iconv
    • Fixed bug #55042 (Erealloc in iconv.c unsafe)
  • Intl
    • Fixed bug #62083 (grapheme_extract() memory leaks)
    • Fixed bug #62081 (IntlDateFormatter constructor leaks memory when called twice)
    • Fixed bug #62070 (Collator::getSortKey() returns garbage)
    • Fixed bug #62017 (datefmt_create with incorrectly encoded timezone leaks pattern)
    • Fixed bug #60785 (memory leak in IntlDateFormatter constructor)
    • ResourceBundle constructor now accepts NULL for the first two arguments
  • JSON
    • Fixed bug #61359 (json_encode() calls too many reallocs)
  • libxml
    • Fixed bug #62266 (Custom extension segfaults during xmlParseFile with FPM SAPI)
  • Phar
    • Fixed bug #62227 (Invalid phar stream path causes crash)
  • Readline
    • Fixed bug #62186 (readline fails to compile – void function should not return a value)
  • Reflection
    • Fixed bug #62384 (Attempting to invoke a Closure more than once causes segfault)
    • Fixed bug #62202 (ReflectionParameter::getDefaultValue() memory leaks with constant)
  • Sockets
    • Fixed bug #62025 (__ss_family was changed on AIX 5.3)
  • SPL
    • Fixed bug #62433 (Inconsistent behavior of RecursiveDirectoryIterator to dot files)
    • Fixed bug #62262 (RecursiveArrayIterator does not implement Countable)
  • XML Writer
    • Fixed bug #62064 (memory leak in the XML Writer module)
  • Zip
    • Upgraded libzip to 0.10.