There are a couple things you can try if you want to keep playing The Pencil Farm games after December 2020:
Flashpoint Archive
The BlueMaxima Flashpoint project is attempting to archive as much Flash content as possible and make it playable in a downloadable format. I’m not associated with this project, but they seem to have the Pencil Farm games in the archive. If you have problems playing the games there, you’ll need to contact the project owners.
Standalone Flash Player
You can download a version of the Flash Player that runs outside the browser. Go here and download the “Flash Player projector” for your operating system.
Drag any SWF onto this version of the player to play the game locally.
I don’t know if this standalone version of the player will still be available after December 2020, or how long Adobe will continue to support it.
If neither of these options work for you, unfortunately I don’t think there’s much that I can do. Most of the games are so old that I can’t even open the project files in any recent version of Flash to edit or republish them.
The Future of The Farm
I don’t have any plans to take down this site any time soon, but I imagine at some point it won’t make sense to keep it alive any longer. It’s been fun. Thanks for playing!
I just listened to the Adam Saltsman (aka Adam Atomic) episode of the Debug podcast.
Adam created the Flixel framework, which is one of the things that inspired me to make Pickle. He is also one of the guys behind Semi Secret Software, makers of the games Cannabalt and Hundreds.
He says a lot of smart stuff in the interview and overall just sounds like a really nice guy.
Definitely worth a listen: Debug 6: Adam Saltsman and Hundreds
My first iPad game, Zephyr Touch, was released on the App Store last week.
I’ve wanted to make a game for the iPad since it was first announced. I’ve been learning bits of Objective-C development here and there for a couple of years. I even have a few small apps under my belt, but making a full-fledged game on iOS has always seemed too intimidating. I finally decided that I needed to just buckle down and make a complete game — no matter how simple — so I could begin to learn the process and build up my skills.
Choosing a Game
Since this would be my first game for iOS, I figured it would be easiest to start with a game that’s already complete and port it to the new platform, rather than try to build something from scratch.
I have quite a few games in my archive to choose from. Luckily, I’ve focused almost exclusively on small casual games that feel well-suited for the iOS platform and are not terribly difficult to develop. That being said, all of my games are designed to be played with a mouse and keyboard, not a touch screen. I identified some games that would work better on a touch screen than others, but one in particular stood out. When completed my Ludum Dare 23 entry, Zephyr, more than one person commented on how well it work on a touch screen. Zephyr had another thing going for it as well: it is a very simple game (it was made over the course of a weekend after all). The perfect game for me to try my hand at iOS game development!
Choosing a Framework
Coming from a Flash background, I was immediately drawn to the Sparrow framework because of its Flash-like API.
I briefly considered trying to build the game using Starling/Adobe AIR for iOS, but then I remembered the wasted afternoon I spent just trying to get a Hello World app to run on my iPad through AIR for iOS. Developing for iOS already involves enough voodoo without adding another layer of hassles to go through.
I also considered Cocos2d. I’ve read a bit about it, and it seems to be a very competent and well-maintained framework. There are a few things about it that seem less than ideal (the coordinate system for example) that made me shy away from it.
So I ultimately chose to go with Sparrow, and I think it was the right choice for me. I figure after I make a few games and get some more experience I can re-evaluate the available frameworks with a more educated eye.
Technical Challenges
Considering I was learning a new framework API, and working in an unfamiliar language, I had surprisingly few major technical problems.
One hangup I ran into was getting the game to launch in the proper orientation. One of the major downsides to working with a framework (any framework) is not knowing if a bug is being caused by my code, or something in the framework. Searching for the problem online led me to many others who had similar problems, but none of the suggested solutions worked for me. I eventually got it to a state where it works most of the time. On iOS 5, the game still sometimes launches upside down for a half second before correcting itself. I think that’s the best I can do. Hopefully the newly-released Sparrow 2.0 has a fix for this issue.
I ran into another issue just when I was thinking I was almost done with the game: I needed to actually save the user’s game state if they quit or were interrupted while a game was in progress. Coming from Flash games, I’d never had to deal with that before. I figured out how to save the game’s object graph using the NSCoding protocol, which is a pretty neat little feature. Ben Scheirman has a nice short introduction to NSCoding on his NSScreencast site that got me started pretty quickly.
Gameplay Challenges
Since Zephyr Touch is based on an existing game, I didn’t have to struggle with very many gameplay issues. I did have to adjust the game for the larger screen. This meant tweaking the speed of the sprites and the power of the fan in order to get the same feeling as the original game.
One issue did come up that I wasn’t expecting. Controlling the fan with a finger ends up being quite a bit different than using the mouse. In the Flash version, the fan follows your mouse wherever you move it, but in the touch version the fan only appears when your finger is actually touching the screen. This means that moving the fan from one side of the screen to the other is quite a bit different in the two versions. In the Flash game, the fan follows your mouse across the screen, blowing around any sprites that might be in that path. In the touch version, the fan simply disappears and reappears on the other side of the screen. It’s not a huge issue, but it’s interesting to note as something that didn’t even occur to me until I started playtesting the touch version.
I wonder how other games might be affected by switching to a touch interface.
Conclusion
Overall, I am happy with the game and I’m glad I went through the process to bring this game to iOS. It was a very valuable experience.
That being said, I know the game itself is not great. It very much has the shallow feeling of a game that was developed in a weekend (go figure). I did consider spending more time to improve the game (adding more visual effects, levels, more depth, etc) but I ultimately decided to keep it the same as the original for now and to focus my efforts on building a new game from scratch.
I’ve been working on some projects lately using the CreateJS libraries. It takes some getting used to, but overall the API works well for someone coming from an ActionScript background.
One of the projects I’ve been working on is more of an activity than a game. One of the optimizations I make in the activity is to pause the CreateJs Ticker when there are no active animations. This way the I don’t waste cycles updating elements when the app is static.
My first approach to this was simply to unpause the ticker before I started a tween, and in the tween complete handler, pause the ticker again. This worked fine until I started to have more than one tween active at the same time. I could try to keep track of which tween would finish first and then not repause the ticker until the second one had finished. That gets messy fast though, and for some things it’s not consistent.
I needed a way to keep track of how many elements were currently tweening and to only repause the ticker when all those elements were done.
What I came up with is a retain count method to keep track of how many tweens are currently requesting for the ticker to be active. This is similar to the way memory is managed in iOS.
I start in the app setup by creating a retainCount property on the ticker and setting it to 0.
createjs.Ticker.retainCount = 0;
I then create two functions called pauseTicker and unPauseTicker. These are global functions in my app namespace, so I can call them from anywhere.
Now anywhere in my app where I want tween an element I call unPauseTicker and pauseTicker instead of using Ticker.setPaused() directly.
It works by keeping a count of how many requests have been to unpause and pause the ticker. Each call to unPauseTicker increments the count, and each call to pauseTicker decrements it. When the count reaches 0 again the ticker actually gets paused using setPaused.
This way I can start as many simultaneous and overlapping tweens as I want and know that when the last one completes the ticker will repause itself. So far it seems to be working pretty well for my needs.
For the past year or so I’ve been developing a pixel art and animation tool called Pickle.
The idea for Pickle came about as I was working on a pixel art game using the Flixel engine. I was trying to create a seamless background tile for my game in Photoshop and was getting really frustrated at how cumbersome the process is. Creating a seamless tile in Photoshop is easy enough. I like to use the Offset filter to expose any hard seams and fix them. However when the tile actually gets repeated a bunch of times weird patterns can appear that also need to be smoothed out. Unfortunately there’s no good way to preview a repeating tile as you edit it in Photoshop.
I thought it wouldn’t be too hard to make a tool to do this in Flash. So Pickle started out as just a very simple tool that would allow me to edit a tile while showing a live preview of that tile repeated across the window.
As I continued to work on my game, I found some other points in my workflow that could be made easier as well. Flixel animations are made using sprite sheets, where all frames of an animation are laid out side-by-side in a single image. To edit an animation in Photoshop you need to edit a frame, export the image, import it into your game and then run your game to see how the animation looks. Repeat that process thousands of times until everything looks just right.
Ideally you would be able to edit a single frame and see the animation previewed in real-time as you make changes. This made a great addition to Pickle. Since I already had the pixel editing functionality built, I just needed to add the ability to preview an animation instead of a repeating tile.
Game terrain in Flixel is done in a similar way to animations. Each specific type of terrain tile is laid in a specific order in a single sprite sheet. The Flixel engine grabs these individual tiles and lays them out to create the game terrain. Once again, I felt that having a live preview of the game terrain while editing would be ideal, so I added the functionality to Pickle as well.
At this point I realized that other people who work on Flixel games might also appreciate this functionality, so I started polishing up the tool into a more user-friendly app and released it to the public.
Pickle is built in Flash, so it is distributed as an Adobe AIR app. AIR has its fair share of shortcomings, but it’s the easiest way for me to distribute a cross-platform tool given my limited development resources.
The tool is still very simple and feature-limited compared to other graphics editors, but many people still find it helpful. Little by little I am working on turning it into a more full-featured tool.
I love hearing from people who are using Pickle. It’s neat to learn about other people’s workflows and hear what kind of features they need. If you try it out, please send me feedback and let me know what you think.
The nice folks at GameDev Tuts+ asked me to write a tutorial on making retro games, based on my previous tutorial about my RGB shifting CRT effect.
I cover a lot of stuff in the tutorial. Since the GameDev Tuts+ site is technology agnostic, it’s a lot more general and non-technical than my other ActionScript tutorials. I found it was a lot more challenging to write this, compared to just stepping through some code to explain a programming topic, but I think it came out okay.
This was my third time participating in the Ludum Dare 48 hour game competition.
Theme
The theme this time was “evolution”.
I had a really hard time coming up with an idea for this one. I actually came pretty close to giving up and not making a game. I finally came up with the idea of a continuously growing plant that evolves and changes into other plants as it eats nutrients.
Development
After the success of my last game, I decided to once again take the relaxed approach to the game competition. I got plenty of sleep, took a lot of breaks, and made sure to get out of the house a few times. This worked out really well for me again, and I’m convinced that this is the best way to do Ludum Dare. I did however come really close to the deadline this time, finishing with only 45 minutes to spare.
One of my favorite things about doing Ludum Dare is watching the timelapse of the game coming together over 48 hours:
Results
I’ve had really great luck with my Ludum Dare games. All three have come out really well. Although they’re not quite up to the standards of my other games, I think they’re actually quite fun to play and could easily be fixed up into great games with a little more work.
In Sprout you guide the growth of your plant by moving the sun with your mouse. The sprout always grows toward the sun. As your plant consumes nutrients, it evolves into different types of plants. My favorite thing about this game is the neat swirling patterns of vines you leave behind as your plant grows.
I didn’t realize it as I was developing the game, but Sprout actually has a lot of similarities to my first Ludum Dare game Spawn. Both games have the main character centered in the screen, with the world swirling around them as you move. And both games have a creature that needs to consume nutrients to produce new life forms.
The Ludum Dare community seemed to like this game a lot. Out of 1000 entries, Sprout was rated #14 in Graphics, #16 Overall, #22 in Innovation, and #30 in Fun. Those are my best scores so far.
I had a lot of fun making a game in 48 hours for my first Ludum Dare in December, so I decided to try again in LD #23.
Theme
The theme for this competition was ‘Tiny World’.
I decided my game would be about tiny forest sprites floating on dandelion spores. You have to guide them to safety by creating gusts of wind with a fan (your mouse).
Development
This time I took a much more relaxed approach to development. I didn’t bother to clear my entire social calendar for the weekend, and I think I was less anxious about it since I knew I was capable of completing a game in a weekend. I was still very tired when I finished on Sunday afternoon, but not to the same degree as last time.
I made a time-lapse of the development process again:
Results
Once again I was really surprised that I was able to make such a complete and polished game in just 48 hours. I’m really happy with how this came out. A couple people commented on how well this game would work on a touchscreen. I’d love to try to port this game to the iPad at some point as an experiment.
Surprisingly, putting in less time and effort paid off this time around. Out of 900 games, Zephyr scored #9 in Mood, #21 in Graphics, #25 in Audio and #43 Overall! Much better than my scores for Spawn.
I participated in my first ever Ludum Dare 48 hour game competition. I wasn’t really sure what to expect, but I’ve been wanting to try to do it and I had the weekend free, so I figured I’d give it a shot.
Theme
The theme was announced on Friday night: ‘Alone’.
I came up with an idea for my game pretty quickly and got to work. My game would be about a tiny amoeba swimming through a vast empty ocean.
Development
Development was really tough. I spent a long time in front of my computer on Friday and Saturday. By Sunday morning I was in physical pain and mentally exhausted.
You can see my development progress in this time-lapse screen video of my screen:
The Game
I did manage to finish my game, and it actually came out pretty good.
The game is called ‘Spawn’. In the game you control the amoeba and you have to swim around and try to eat little nutrients out of the sea. After you eat three nutrients your amoeba will spawn a new life form. There is a screen in the game that will show off all the different creatures you’ve created.
I think I drifted a little too far from the theme. After I added the other creatures that get spawned, then you no longer feel very ‘alone’. But without them, the game wasn’t much fun so I chose to compromise in favor of fun.
Results
Overall, I got a lot of good feedback on my game. People seemed to like it.
It came out a lot better than I expected. I might end up refining it and releasing it as a proper Pencil Farm game.
Out of over 700 entries, Spawn came in #38 in the Audio category, #48 in Graphics, and #94 Overall.
