Atari's PongDevChallenge is still moving along. Atari sent us this press release yesterday, and it alludes to the video above.
"The #PongDevChallenge is in full swing. With one month left to go for developers to submit their ideas for a chance to recreate the mobile version of Pong, we’re actively looking for every indie developer who wants to participate in the challenge. Nolan Bushnell, the father of Atari, speaks out about Pong and the upcoming challenge in the attached video. "
We had a near total failure of the site last night. However, we were able to export all the old content, and get everything back up this morning. We will be searching fr new themes and logos and stuff to make this a (albeit forced) fresh start. Any ideas are welcome.
Pro Flash game development veteran Richard Davey has a great article named "The Reality of HTML5 Game Development and making money from it" that you NEED to read right now. It's an awesome overview of the an industry that is blowing up right now written by a guy who lives it every day.
A few weeks ago on one of the forums I frequent, a fellow retro game fan (Rimbo) talked about playing "Time Pilot:Pacifist". This was not a new game, but rather, a different way of playing an old game. In his version of Time Pilot, he chose to never fire a shot, and instead spend all of his time on level one, picking-up the little parachute guys. I instantly replied to the conversation because I have played this game too. We both had created a new game out of an old one, and we never had to write a single line of code to do it.
This conversation sparked some thoughts in my mind about other games that I have played in the past in ways that were probably never intended by the designers. Some of these were because of are bugs, some were just alternate ways to play based on the released game. None of these were hacks. While I also spent a lot of time using sectors editors and cheat programs to edit the values in games and change the difficulty, those efforts always left me cold, like I had suddenly taken the fun out of the game by cheating. These were not "mods" either. The things I'm talking about were ways to leverage the existing games (glitches and all) to make the intended experience into something else entirely. All of them were memorable in their own special way.
Creating A Game Out Of A Toy: Etch A Sketch Auto Racing
The first game I recall "editing" was the Etch A sketch toy. Wrote about this a long time ago on this site in a post named "Atari Nerd Chronicles: Garage Games Literally", and here is what I said:
"By using scotch tape and the lap timer on a digital watch, we created our own racing games using this seminal drawing toy. First, one of us would spend the time to lay-down an elaborate track using scotch tape over the Etch-A-Sketch screen. When that was finished, the other one of us would attempt to ‘race’ (draw a line through the track) as fast as possible without hitting any of the scotch tape lines as he was timed by the digital watch. It worked fairly well, as long as the players were honest about not hitting the barriers. "
Imagining A Different Game Entirely: Marauder Star Wars
The first video game I recall "editing" was Tiger games' Marauder. This was more of a "mental" edit, than anything else, as it was less a different way to play the same game, than it was a different mental state in which to play the same game.
Marauder was the first Atari 2600 game I ever bought that I hated. It was a game a bit like Berzerk, but from an overhead perspective (kind of). The graphics were designed to look like little people walking and firing guns, but instead, they looked more like grotesque purple triangles shooting square eggplants. Your own character was seen from the side (I think), which made the whole thing even more bizarre.
Since I had paid $24.99 of birthday money (in 1983 dollars,$56.62 in 2011 dollars based on inflation ) for the game, I was really pissed off. It was one of the first games I bought that I hated, but I still played it...because I bought it. However, every time I stuck the cartridge into the 2600, it was not Marauder any longer, instead it became : Star Wars Death Star Battle. I imagined that the game was set on the Death Star, and all the little purple triangles were Storm Troopers. My job was to shoot as many as possible. The items to collect in the game became stole plans for the ultimate battle station. Sure, it really didn't make the game any better, but it was a quick way to fill the $24.99 hole left in my heart by the disappointment.
Going Hardcore : Defender : Holy Sh*t! Space Mode
These days, there is a whole sub-genre of game players that go hardcore when it comes to difficulty. They play on the hardest settings, make rules that you can't reload, or you only get one life. While I admire these kinds of "rule modifications" in modern games, I can proudly say that I participated in one of the very first versions of this: Defender Holy Sh*T Space Mode.
Defender, along with Tempest, Star Gate and Robotron, were some of the first hardcore video games. The difficulty level was set very high, the controls were complicated, and the action was blazingly fast. If the regular mode of Defender was not hard enough, if you managed to kill off all the humans you were supposed to save, the game thrust you into what we called "space mode". In this mode, the landscape went away, and the game threw as many aliens at you as possible. It was insane, and usually going into "space mode" meant your game was over.
However, playing games in the arcade in 1982 was an exercise in resource management. If my mom had dropped us off for a couple hours, and it was nearing the time for us to be picked up, we could not get into any game that might last too long ad have her waiting outside. Because of this, we had to create short challenges out of existing games to fill in the remaining time. Sometimes, (usually with our last tokens) my brother and I would start a 2 player game of defender named Defender : Holy Sh*t! Space Mode.
We played this game by killing off all our humans as quickly as possible to get in to "space mode" and then tried to see who could stay alive for the longest amount of time. The game was less about points than play time. If we could make the game last just until my mom came to pick us up, it was a success. Of course, playing the game this way was insanely difficult, but it was like icing on the cake: a final thrill to top off a great day playing video games at the arcade.
Exploring The Landscape: Intellivision Auto Racing Offroad
The Mattel Intellivison was an odd beast of a game system. The games always seemed to play in slow-motion, the controllers were bizarre at best, awkward at worst. However, one advantage the Intellivision had over the Atari 2600 was bit-mapped graphics. While Atari game designers had to program by TV electron-gun scan-line (which is also one of the reasons you can't hook a 2600 directly up to a modern TV), Intellvision programmers had the luxury of laying out giant scrollable, bit-mapped worlds. No game displayed this ability more than Auto Racing. (on a side note, it's odd that this game was not Hot Wheels branded because Mattel owned that brand, but I digress).
Auto Racing was a very cool, scrolling racing game, but the best part of the game was that you did not have to stay on the roads at all. There were gaps between the trees and buildings big enough for your car. It was enticing, and enjoyable, to simply take-off road and explore the world on your own. You could not win the race this way, but it did not matter. For the first time playing any racing game, it seemed more fun to drive through backyards and groves of trees than staying on the track. It always appeared that we would discover something really cool and secret if we just kept going off the track. While we never did find anything out of the ordinary while going off road, it wasn't from a lack of trying!
Data Manipulation : Microleague Baseball Superhuman Stats
When we were kids, my brother and I loved baseball. We could list the starting line-ups for both the Dodgers and Angels in order by first and last name, and we watched every game that was on TV. We played in Little League, and collected baseball cards, and consumed Big League Chew" like it was the coolest thing around.
One of the first computer video games we devoured was Microleague Baseball . This was not an action game but a stats based baseball simulation where you played the manager. The game featured dozens of teams from the history of baseball, including teams that could have never existed like the America League All-Stars featuring great players from most of the 20th century.
One of the joys of the game was playing a team like The American League All-Stars against a relatively recent team (at the time) like the 1981 Dodgers. In fact, it was during one of these games that we noticed something interesting. After the American League All-Stars clobbered their opponent in shut-out by a 25 or so run margin, the game ended and, like always, it asked if we wanted to "compile the stats" for the game. "Compiling The Stats" for a game meant the stats for the current game would be added to a new team. We did this, and then the game asked if we wanted to compile them again. So we did, and again. The same stats over and over again.
Soon, we had a team with a pitcher that had won dozens of shut-out games, and players who had dozens of hits, RBI and home runs, all based on that one game. Sure, some players compiled crappy stats, but most became inhumanly good at baseball.
Next we took that same team, and played it against the same, sad opponent. I believe the first inning took almost 2 hours. In fact we had to put the game in "fast play" mode and let it play out itself to get to the ending. That game ended with a score of about 102-2. Of course, we compiled that one multiple times, and continued. The result were bizarrely out of whack baseball teams. Some players hit home runs at every a bat, while other could not hit the ball at all. If player had made an error in a game that was recompiled many times, all of sudden he became a total clown on the baseball field, missing everything that came to him. It didn't make the game any better, but it was a fun time while it lasted. It also showed that basing a game like baseball, completely on stats, can have some serious drawbacks.
TOS Icon Football
Right after we bought our Atari 520 ST computer in 1987, the disk drive failed. I mean right after, like the same day. However, since we had bought it out of the trunk of a guy's car (the same guy who would one-day open the store Computer Games Plus in Orange California), we really could not return it right away. In fact, it took about 4 weeks to get a replacement. In the mean time, We came up with sad game named TOS Icon Football. The game was played on the TOS desktop. One player would move the icons around, trying to protect the trash can (the ball). The other player would take their turn making moves to try to steal the trash can. In reality, the game made no sense at all, and I can't even remember the rules. We just needed to find something to do with our $700 door stop while we waited for a disk drive to arrive. The main thing I remember is the remorse I felt after selling my Atari 800, and all our disks (including all the BASIC games and programs we had written--what the hell were we thinking?) to help pay for, what amounted to, an expensive tan box that displayed a green field of nothing.
By the way, the mouse failed on the Atari ST not too long afterward, and we took it to Federated Group (Atari had bought the chain) to try to get it fixed. 9 months later, after multiple attempts to get it back, fixed or not, a call from the Bureau Of Consumer Affair to the manager of the Federated Group was the only way they would release their steely grip on the device.
Yeah, owning an Atari ST in the 80's took a lot of patience. There were some great games (Dungeon Master, Lost Dutchman Mine, Kickoff) that clouded the issue. However, it was only in hindsight that we realize we should have bought an Amiga.
Glitches That Makes Games More Competetive: Micropose Soccer/FIFA '94 Goal Storm
My brother and I played a lot of soccer video games while growing up. Some of those games had great special effects, but played terrible soccer (i.e Pele's Soccer for Atari 260), while others have never been outdone (Anco Player-Manager for Atari ST). The best games were the ones that allowed for an almost unlimited array of ways to score goals. However, some games had particular areas that, when the ball was shot by a player, a goal would be scored no matter what else was happening on the field. Two such games were Microprose Soccer for the Atari ST, and FIFA '94 for the Sega Genesis. However, instead of dismissing the games outright for being glitchy, we instead created our own contest from their relative shortcomings: Goal Storm!
The object Goal Storm! was to see who could score as many goals as possible in the longest game, without giving up out of boredom. Both MicroProse Soccer and FIFA '94 had similar features that made this game possible. First, you would select the longest play time possible. Neither game played in real-time (90 full minutes) but you could get very close. Then you would select to play the best team in the game (usually Brazil or Germany) and play against the a terrible team (usually Oman, Japan, or the USA). This was before the USA or Japan were recognized as playing a decent game and that was reflected in these games. Then, it was time to score as many goals as possible.
In FIFA '94 the key was to get the ball to just outside the 18-yard box a bit right of center, and make a lob shot into the goal. In Microprose Soccer, you needed to sprint down the right-side of the field, just to the right inside of the goal box, and make an angle shot. Since you scored EVERY TIME (as far I can recall anyway) with these methods, your goal was to steal the ball as quickly as possible from the other team, sprint to the box and shoot. I don't believe either my brother or I ever finished the longest games, but the shorter ones were great fun. In an alternate version of this game, we would play as the disrespected USA team, and use the goal storm methods to trounce the best teams in the world.
Command And Conquer Wall Wars
After devouring Dune II on the PC, I could not wait for the release of Westwood's Command And Conquer. However, when it was released I realized that the game was much harder than I anticipated. While it used a lot of the same ideas as Dune II, some of the unit powers and combos made my (albeit very basic) strategies and tactics learned from Dune II fairly toothless.
That was, until I discovered walls. Apparently, this was a bug, but I did not know it until much later. In the first version of Command And Conquer "walls" counted part of your base, no matter how far you built them one of your buildings. At the same time, enemy units, more often than not, would not try shoot at your walls. When I found this out, my strategy became the same on every level.
First, I'd send out scouts to locate the enemy base. Next, I would build a long wall from my base, all the way to the enemy base, and surround it. The enemy units were now trapped in their base, and their harvesters could not return. I would then build towers around the enemy base that would shoot at their units as soon as they were created. Lastly, I'd send up my tanks to finish off the buildings. It turned a semi-complex strategy game into a game of shooting fish in barrel. Unfortunately for me, In later versions of the game, this glitch was fixed. After that, RTS games were ruined for me, as they never gave the intense satisfaction of a game of Command And Conquer Wall Wars.
So those were the ways I recall playing video and computer game in ways they were not intended. Did you do anything similar? Tell us about it in the comments.
At Producto Studios, we have just finished a large 5 month cross-platform (iPhone, iPad, Android phone, Android Tablet) project using Ansca Corona as the API and tool kit. Corona is not a drag and drop style app builder, but a robust, subscription-based API built on top of the relatively simple, yet powerful Lua scripting language.
First, lets just say that working with Corona is very straight-forward, and the Ansca Team is constantly updating the API by adding new features while the developer community adds new code modules that make creating games and mobile apps easier than ever. Let's break down our experience in using Corona for a Large-scaled (over 125MB foot print) application in to the Good, the Kind of Bad, and the Not So Ugly. ( Note: These can also be applied to building any size application)
1. The Corona API lets you build true cross-platform applications that target the major devices (iOs 4.3 and above, Android 2.1 and above, and now Kindle Fire) with a true SINGLE code base.
2. With a few lines of code in your build.settings file you can truly scale your application to any device screen. (see other sections to bad and ugly parts of this)
3. The API includes many concepts that Flash developers will be familiar with such as MovieClips and Spites. For example, using a PNG sequence from Flash to create an animated MovieClip or as a Sprite is a snap. There are also great tools such as Texture Packer (not free, but reasonably inexpensive) that will output to Corona (after dropping a swf into it) to make this even easier. There is even a layering concept called "Groups", and simple dynamic masking (not fully realized as of yet, but it does have its uses).
4. The API includes many Audio and Video functions and more are being added each day. Audio is completely supported with record and playback features built-in.
5. There is physics engine (built-in) that is based on Box2d.
6. More and more interface widgets (such as the awesome newly re-designed scroll-pane) are being added (or improved upon) to each new daily build.
7. We found that letting the designers work in Flash (a tool they are comfortable with) and exporting animations was the best way for them to get assets into a Corona project.
8. You don't need a run-time such as Air for your application to run on the platform. Each application is built with native API's (Java for Android) and xCode for iOS.
9. Loading assets from remote servers either as files or as Server data streams (XML from a web service) is simple and straight forward.
10. The API integrates with the Flurry mobile analytic engine very simply and easily.
11. There is a new set of "project" settings that allow the user to set up and use some pre-created templates when first starting an application.
12. Can integrate with OpenFeint, Papaya (Android), and Game Center
13. There is a nice transition manager that is not unlike Tween-lite for AS3.
14. Can integrate with Facebook
15. Has currency and in-app purchase APIs
16. Can directly use SQLLite3 in app.
17. Has access to the operating system, photo and video libraries on the device (and much much more)
The Kind Of Bad
2. Video. While the video functions in the Current version of the API are sufficient, they are not any where as good as Flash. First off, the API relies on the video player of the device, and when a video is playing, complete control of the application is lost to the device's player. When the video is complete or the user stops the video, you can create a call-back function that will run when your app returns to active duty. Video cannot use flv files so Green-screen videos such as those prevalent in Flash applications are not possible to do. This can be solved with PNG sequences, but those use A LOT of texture memory. You also cannot record video or access the web cam of the user.
3. Up until recently the "widget" section of the API was pretty sparse or lacking in basic functions that you needed to roll yourself. A good example is the ScrollPane widget that up until a recent "daily build" in January could only be used vertically or take up the entire screen. The new version is very useful though. The API team at Ansca is very responsive to the comments on their message boards and do everything they can to add and fix features in a timely manner.
4. YOU MUST SUBSCRIBE to get all of the features of the product. You can't be content using the free version for development and then purchasing a subscription right before building as you will miss out on many features added in daily builds.
5. For a large scale project, the The Corona Project Manager is a must. It's an extra $75, but it is a very useful tool for create applications. It really should be built in to Corona though.
6. The debugger is only adequate at best.
7. Assets are all png and jpg files (unlike Flash Vectors) and this creates very large foot-print apps that use a lot of texture memory. You must be aware of each byte byte you are using and dispose of it properly. If not, you run the risk of apps dying when memory runs out. mp3 files are supported cross-platform, so music and sound effects can be small files sizes as long as you understand that mp3 files will not loop playback with out an audible silence.
The Not So Ugly
1. To build a true cross-platform and screen-size app, you must start with the largest screen-size and then create a "buffer area" that will show up on the larger devices and will be hidden on the smaller screen devices. There is more than one way to skin this cat though, as there you can dynamically detect screen size and load in various assets accordingly, but this creates a lot of extra code and extra assets in the final package.
2. Without the Project Manager (extra $75 cost), creating a cross-platform app means shoveling all files for the app into a single folder (Android will not compile with items in sub-folders).
3. The Audio API is very robust, but it has some bugs that require the user to ensure that a sound is not playing before it is disposed from memory. In some cases, disposing a sound while playing will crash an application.
4. The debugger is only adequate at best (I know I said this before).
All in all though, Ansca Corona is a one of the best (if not the best) cross-platform mobile development tools on the market. It is always evolving, adding new devices to publish to and becoming more awesome. We could not have completed our project on-time without using Corona. Without it, the cost and time to develop for both Android and iOS (let alone the various screen sizes) would have nearly doubled the cost and time to market for our project.
A few weeks ago we saw a video of a guy punishing a Windows laptop by shooting it with 8 hallow point bullets. Now while we are all for punishing Windows laptops (they certainly punish us all day long), we think that wasting all those hallow point bullets might not be a good idea (especially with the 2012 zombie apocalypse looming in our collective future). So instead, we suggest 10 other ways to punish a laptop.
This video is a sad, pathetic response to this:http://www.youtube.com/watch?v=kl1ujzRidmU
If you are stuck spinning your wheels, trying to think of the next "Angry Birds", "Fruit Ninja", or "Plants v. Zombies", why not try the App-o-Tron mobile game idea generator. It couldn't hurt and probably will come up with better ideas than 90% of the current games in the app stores.
Or why not try our Game Storm game idea generator for even more detailed game ideas.