I like timers and energy as game mechanics, personally. There’s several Free To Play games that I play and enjoy which use them to great effect. Smash Bandits, Boom Beach and Disco Zoo are a few solid example on mobile platforms. It’s too easy for some to ignore anything that appears to be intrinsic to free to play games just because you disagree with the business model. I think “premium” games can learn a few things from free to play.
There are some games that I love but can rarely play because they are designed for long play sessions. A lot of “just one more turn” games like Civilization fall into this category. I can’t enjoy them games responsibly because they have that hook that pulls you into the game so much that you lose track of time. That hook is part of the appeal, but I need it to let go of me on its own. Watching the clock myself breaks the experience and sometimes doesn’t work.
It’s also true for most of these types of games that there is never a “good” place to stop. There’s always loose ends or half-completed plans dangling and it can be a bit confusing to interrupt those things and come back later. It’s easy to forget about something you were planning to do or lose track of long term goals.
This is where timers and energy may be useful. Each play session can be designed to be a satisfying arc of its own that leaves things in a reasonable state for you to stop thinking about it for a while. I can’t think of any games that really employ this strategy in exactly this fashion, but the DNA was there in old browser-based strategy games like Star Kingdoms (wow I can’t believe that’s still running).
I may explore this idea in the future myself once Fate Tectonics is behind us.
There were some comments earlier today complaining about the Global Game Jam’s decision not to allow remote teams that can’t get to a jam location. After debating the issue with David Gallant on Twitter I felt like I needed to collect my thoughts on the subject with a few more than 140 characters. First off, I consider Global Game Jam a location jam; it may have many locations, but its interest is in creating location jam experiences in many places. If you don’t consider GGJ a location jam, this isn’t likely to sway your opinion much on that issue, but this is still relevant for other location-based jams.
Because it’s really awkward to repeat “location jam” over and over, I’m just going to say “jam” for the rest of this post. I mean location jams.
I had a problem when I first grabbed FTL. I couldn’t stop playing. I didn’t get my chores done, I had a hard time concentrating on work. Leave the house? After this next game. Maybe the one after that. Then something happened. I beat Sector 8. Every time I managed to best the flagship, I felt a little less inclined to play again. Then I stopped playing almost entirely. What happened?
Recently, Adam Saltsman made a two part post (Part One) (Part Two) critiquing aspects of social games and “freemium” business models. I share the distaste for the tactics, but we need to carefully consider what our opponent’s strengths and weaknesses are. Otherwise all we’re doing is talking for the sake of talk.
For a recent project I created a performance graph which helped me to identify which parts of my engine were responsible for performance issues. Based on that, I have developed a flexible PerformanceMonitor class which can expanded on to track performance in a number of ways. The default implementation produces a pair of graphs like so.
Each colour corresponds to a different task that my application performs. Perhaps blue represents AI execution time, red represents rendering, and teal represents mouse handling. The graph on the left reports the time spent on each task I am tracking per update. The green area gives me an indication of whether Flash is dropping frames due to the execution time of my code. On the right is a bar graph showing the relative weight of each task over the lifetime of the application. More details on use after the cut.
I just read this post by Greg Beaton on his Art of Game blog from back in February. Late last year I was talking to Alex about the same basic idea. Whenever I’m working on game projects I’m usually holed up in my computer room at home for hours on end, and sometimes the creative energy can be really difficult to sustain. Unlike a lot of other artistic disciplines, game developers are more tethered to equipment needs and can’t easily get a change of scenery while working. A common studio space for game development is a fantastic idea.
I’m not so sure about adding the additional overhead of selling merchandise on site, especially at the onset. Although, decent quality concessions are a pretty easy sell with game developers, as the TOJam concession stand demonstrates every year.
Game jams bring us together to achieve a short term goal every once in a while, but I’m really interested in a studio concept that would see local developers working closely on an ongoing basis. I hope this idea goes somewhere. I’m going to start bringing it up with other local developers and see if there’s any traction.
This is the second part of my series on game engine design. I’ve spent some time throwing around various ideas about the principal entities that a game engine should be concerned with and how they relate to each other. I’m going to hold off on any class diagrams or specific examples for the time being. This is all a thought exercise until the next entry, where I’ll analyze some specific examples and start generating some pseudo code for how I would like those use cases to look from the game developer’s perspective.
I’ve been working away on AScalpel for a while now, polishing it and adding some new features to it. It’s settled enough now that I can sit down and write a real step-by-step guide to using it.
There is also a sample application included with the AScalpel library which is already integrated. Compile com.andrewtraviss.ascalpel.sample::BouncingBallSample.as as an application to view it. AScalpel Basic User Guide continued »
With the announcement that TOJam 6 is imminent. We’ve done a little better each year and I’m really looking forward to this one. I wanted to take some time to share what I’ve learned by attending five of these crazy things and share what advice I have on improving your chances of success and minimizing your stress. TOJam only comes once a year, so make the most of it! A Quick Guide to TOJamming continued »
There was a bit of buzz in the indie game community recently around the idea of editing object properties at runtime as a great way to tune gameplay quickly. I haven’t seen any attempts at a reusable system to handle it, so I thought I’d give it a go. AScalpel is a basic editor shell which uses metadata to dynamically create editors for custom classes. There’s still some issues to iron out with it, but I don’t really have enough free time to do it. It’s up on Git now.
Normally I’m a diehard Flex fan, but I know not everyone shares my views so I’ve used the Bit-101 Minimal Components for this. It could easily be retrofitted to use Flex as well (I will probably do this later). For this initial release, it is purely an Actionscript 3.0 library. I’ve set up a Git repository to share it with everyone. An explanation of how to use it, below the cut. You’ll need the Bit-101 components in order to use it at the moment. Currently hosted on Google Code, here