Execute() has come along quickly. Less than a month ago, it was a twinkle in my eye, now there are Lua bots, created from JSON and command sets, roaming a Tiled map. Blockly is installed and ready for me to customize blocks and implement Lua output. Follow me on Twitter @jcpmcdonald for the latest.
HTML5 audio is a bit of a minefield when you’re trying to get sound working on all platforms. The internet is rife with outdated information, and libraries that claim to work everywhere but don’t really. By “all platforms”, I mean:
Took me an entire week to navigate this minefield, and I emerged on the other end with a Tuning Fork to help me figure out which audio solutions were working where. I have a hosted version of Tuning Fork so that you can try this out for yourself. Here are my findings:
| Chrome (35.0) | Firefox (v30) | IE 11 | Safari (v7.0.5) | Safari Mobile (7) | Chrome Mobile | Android Mobile | PhoneGap Build | PhoneGap CLI | CocoonJS (Webview+) | |
| HTML5 audio tag | Yes | Yes | Yes | Yes | Yes | No | ? | No | No | No |
| Crafty.Audio (v0.6.2) | Yes | Yes | No | No | No | No | ? | No | No | No |
| SoundJS (v0.5.2) | Yes | Yes | Yes | Yes | Yes | Yes | ? | No | No | Yes |
| howler.js (v1.1.23) | Yes | Yes | Yes | Yes | Yes | Yes | ? | No | No | Yes |
After much effort, I finally got audio working on PhoneGap using the Media object, but it was no easy task. If you’re in that boat, the Tuning Fork project, when compiled using PhoneGap CLI, will produce audio, at least it did for me on my Android. To get it working in your own project, I wrote a detailed answer on Stack Overflow.
Undoubtedly, the table above will become obsolete in a few months, so please run your own Tuning Fork tests against your target platform(s).
I just finished my adorable jam entry for the 2014 GDSE Summer Game Jam.
The theme of the jam was to take a mechanic from another game and either change it or make it better. I chose Flappy Bird’s “tap to fly” and “Punishing but Quick” concepts and made them my own. You are a fish trying to escape death by skipping on the surface of the water. Press or release the left mouse button when Skippy is close to the surface of the water to skip.
All art and sound assets were created by me, specifically for this project. I used Inkscape for the graphics, and a glass of water, a straw, some popsicle sticks, my own voice, and Audacity for the audio. I have uploaded all of these assets to opengameart.org under more permissive licenses than the game.
The game is open source and can be forked on Bitbucket, Licensed under CC-BY-NC-4.0
Known issue: Sound may not function properly in IE11, use Chrome or Firefox.
It saddens me to declare that Asteroid Outpost is over. I knew it was a very ambitious project when I started back in 2009, but at the time, I needed an interesting challenge. Along the way, I rose the bar again and again. I set my bar too high. Asteroid Outpost is in a playable state, and I will be releasing not only an executable, but I will be reopening the source. It has been an wonderful journey with lots of ups and downs, but it’s time to move on. I have never experienced an emotional roller-coaster quite like it. In time, I will write up a postmortem, but for now I just want to write something short.
My web-host was hacked, and my website was among 4 that were deleted. It sucks, but I didn’t lose a lot, and there’s some good coming out of it: I’m starting over with WordPress. Most everything is back up and running, and I think most links should work. Let me know if you find any issues.
I need to create a small number of scenarios, get them linked together in a campaign, implement saving, add some sounds, and tie it all together with a story. Asteroid Outpost needs to make it to a cohesive state. I’ve built my vertical slice of gameplay, now it’s time to build horizontally. Five or six scenarios sounds about right to lay down my horizontal framework, and it will be long enough to have some fun. I’m aiming for ~10-20 minutes per scenario, which will result in 1-1.5 hours of gameplay awesomeness!
It feels like relief to finally make some decent progress in Asteroid Outpost. I have been trying to focus on some of the larger and more visible items, starting with those ugly yellow power lines. This was followed up with improving the laser miner beam and making it extend from source to destination:
I was getting sick of the single style of AI in the game: “move forward until you’re within laser range, stop and shoot”, so I designed some new AI that uses a mix of missiles and lasers, and attempts to strafe. Each unit has 6 missiles and will only use laser beams as a last resort. Here’s a quick video example:
Scenarios are an important part of my game, so I sunk some time into the “Science Station” mission. In this scenario, scientists require more and more power to conduct an experiment. Without access to power, they will be unable to keep their experiment under control and the entire station will erupt spectacularly.
The explosion could look better, but I do like the fires. It’ll do for now. The scenario isn’t quite done yet, but the power requirements ramp up, and if they are not met, the science station explodes.
I have started to seriously think about how many scenarios I want the game to have, and how to link them together with a bit of a story. It would be great if I could create skeletons of these scenarios and connect everything for the first time. No, it would be incredible.
Been a while since I’ve provided an update, so this will be a big one.
I won the first, and second ever GDSE Game Jams! For the theme “There can only be one”, I created Like Clockwork, a web-based bot programming game where you program your archer to navigate the battlefield, seek out, and destroy your enemies. The second jam had the theme “Time is Broken”, and I made (In &) Out of Time (works noticeably better in Chrome), a web-based adventure game. Both are open source and available on BitBucket here and here.
Asteroid Outpost could be coming along better. I created a nice dialog screen that shows who’s talking, added a new enemy spaceship that’s practically the same as the first, and started to make a new scenario. The new scenario demanded a giant super-structure, but since my game is 2D, I needed to split the new entity into 2 sprites so that it would properly draw over and under other entities in the scene. My entire engine is capable of handling two sprites for a single entity, except the current JSON format I’m using to load entity templates and send entity data to Awesomium. Now I either find a shortcut and move on, or take the time to fix my JSON. Shouldn’t be too bad, but it’s still one more thing I need to do. On the plus side, I was really happy with how quickly I was able to get a new bad guy int he game.
There have been a couple bugs in TeeVee that have been annoying me recently, and I’ve been thinking about completely redoing the UI for a few years, but haven’t made the time. This weekend, however, I finally took the plunge and created a brand new web-UI that replaces the UI portion of TeeVee. The scanning and updating from TheTVDB.com is still handled by TeeVee 1, but I plan to write two stand-alone apps that will do each of those tasks. I must say, TeeVee II is already looking way better. Not only is it significantly faster, but it’s also way sexier.
When I’m done with TeeVee II, I’m not sure if I want to release it open source or what. It’s valuable to the right audience, but my gut is telling me that the audience is too small, and none of my audience will be actively seeking out an XBMC replacement because they don’t know that it could be better. Let me be clear here, it may be better than XBMC for heavy TV viewers like myself. I tried XBMC for a few weeks, and my main annoyances with XBMC were: It’s very folder-based, lack of “favourite” shows, and it didn’t handle sleeping very well. TeeVee is file-based, so you can just download your TV to wherever you want, and TeeVee just picks it up and runs with it. It can save a lot of time if your library is large. You can select favourite shows in TeeVee, and those shows will appear above all of the other shows. I have 157 series in my database. How fun do you think it is to watch Vikings with XBMC? And the last point: if my laptop would go to sleep with XBMC running full-screen on my second “Monitor” (the TV), when I woke up the laptop, XBMC would be full-screen on the primary monitor (the laptop). Anyway, look for TeeVee II hitting the shelves near you!
I participated in the GDSE Game Jam over the weekend and ended up making a pretty cool game in a very short period of time. For those who are unfamiliar with game jams, you are given a theme at the start of the competition, and you have to make a game from scratch before Sunday at Midnight, using only freely available tools and art. Once the games are submitted, there is a voting period, and the one with the most votes wins.
The theme for this jam was “There can only be one”. It took a lot of thinking, but I finally thought of, and settled on programmable bots that would fight each other in a 2D arena. I didn’t want the bots to be futuristic, and so the medieval archer game Like Clockwork was born.
Like Clockwork’s documentation and source are available on bitbucket, and you can play it on my App Spot
Note that the battle field will only work in Firefox due to technical limitations. I hope to have a working version in Chrome soon. After this fix is made, Chrome users will have to enable the Experimental JavaScript flag in the browser because Chrome does not support the future JavaScript function yield out of the box.
For this game, I am using a technology stack that is completely new to me: CraftyJS, Blockly, Google App Engine, and the future JavaScript function yield. From a high-level, users stack blocks together in Blockly, then publish the generated JavaScript to Google App Engine’s cloud storage where they (and others) can select bots for battle, which then sends the JavaScript bots to the CraftyJS “battle engine” where you get to watch the bots move around and shoot arrows at each other.
The game took me almost exactly 30 hours of work from start to finish, and a lot of this time was spent reading documentation for the new technologies that I am using in this project. Here’s a rough timeline:
yield doesn’t workThe end was a bit tight. If I didn’t connect Blockly to the Battle Engine, I would have had nothing. Luckily, I came across very few roadblocks and was able to pull everything together in the last hours of the jam, :)
Here are some screenshots of programming and fighting:
Wish me luck in the polls!
I’ve been getting my upgrade system in place. Below, you can see three Solar Stations, one of each level. #screenshotsaturday
