





Fantastic!
by Megan Lara and Omega Man 5000
For my April project for One Game a Month, I liked the idea of making a game for my nieces to play to learn colors and shapes. I thought of having animals to click on, and initially it was frogs, but when I settled on turtles, it all clicked together.
Download Toytles Colors for Linux 64-bit (395 kb tar.gz file)
I figured such a game would need to have more pizazz than my typical projects have, so I wrote up an animation class quickly, and then I used the Gimp to create some animated legs for the turtles. It’s not too bad.
I wasn’t able to dedicate as much time to it as I would like to this project. I was going to have the player try to click on matching colors as well as shapes, but I ended up scrapping the shapes.
I was pleased with the cartoony turtles I threw together, although the scale left something to be desired.
I added some color picking criteria and made sure the player could click on a turtle with the right color.
The final game awards you a point for each turtle you click correctly, and even helpfully lets you know which color you’re looking for.
I had plans for particle effects and audio to celebrate and inform you when you clicked on the wrong turtle (“That’s not blue! That’s red!”), but I’ll have to address those next time I pick this project up.
April #1GAM Entry: Toytles Colors is a post from: GBGames - Thoughts on Indie Game Development
The following is some rambling. I have a point I’m trying to make, but I’m certain I don’t make it. My fingers kept moving, and this is what resulted. You can kinda get an idea what sort of madness is bouncing around in the ‘ol noodle right now though. Good luck.
*Big Sigh*
I’m typically a “from scratch”, “native code is best”, “c++ FTW” type of developer. The thing is, developers with my skillset and experience really are at a big disadvantage in today’s game market. I could go embed myself in some company somewhere, work on the latest greatest whatever BS FPS engine, but I’m far too independent to want to do that again. My distaste of C# has to take a backseat if I’m going to get anything serious done in a reasonable amount of time, because time… time is precious. Too precious to be fighting with low level stuff as a solo developer.
*Bigger Sigh*
To my credit, I started dabbling with HTML5 (JavaScript) last year, and quite liked it. It was refreshing, somewhat dirty, but enjoyable. I’ve also been picking up some little JavaScript related gigs here and there to pay the bills. So JS has been my gateway to exploring less strict languages. Squirrel is a favorite of mine, but the differences between JavaScript documented in my prior post go to show how much a change of thinking it still is. There may some day be a project for Me and Squirrel, but for now, I need to be looking elsewhere.
Unity unity unity. It’s impossible to NOT hear about Unity these days. I was at a cabin with some gamedevs earlier this year, and nearly all of them used Unity now, and looked at me funny for NOT using it. Wow.
I was so so soooo against it. The C#, the “I’m having fun engineering” excuse, etc. Suck it up.
Then I stumbled across these tutorials:
http://unity3d.com/learn/tutorials/modules
As I watched each 3-10 minute short, I began to understand more and more how Unity became such an unstoppable force. And as an engine designer, I grew more and more envious how elegant some things just work inside Unity. All it took was one night, watching a majority of those videos, to realize where I may have gone wrong in my past few years.
Now, don’t get me wrong. The port frenzy that was Smiles was actually the right idea. At the time, Unity was immature, and the platforms out there were plentiful and poorly supported. I had an argument back then. When I finally picked up and started using Marmalade for the remained of ports (Android and Symbian), that was also the right idea. The world was changing. The long promise of Native Code on every device being less and less necessary was finally happening. Today I have some concerns about Marmalade’s choices, but at the time a couple years ago, they were doing the right thing.
Today I have no argument regarding Unity. I’ve tried inventing reasons not to use it, like console ports and networking, but after the Unity+Sony announcement at GDC it became clear that I’d run out of them. Given my situation as a solo developer, I am making a grave mistake NOT using it.
I credit Unity earlier for looking extremely good, but it may be because I’m starting with Unity 4. I’ve skipped much of its legacy, and certainly things must have been improved going from 3.5 to 4.0. So best I can see, Unity today is the only practical way to make a 3D game.
Oh and best part, I don’t even have to use C#. There’s something nicknamed “UnityScript”, which they call “JavaScript”, but it’s more like a strictly typed Ecmascript (i.e. Flash-like). This seems to have become a theme.
Again, I want to say I’m still evaluating Unity. That said, I may have also conceded defeat to it… however!
There’s really only one tool suite more prolific than Unity, and that’s Haxe. Combined with NME, it provides a solid 2D framework that can target anything from PC to Mobile to the Web. It’s a tool suite that lives and breathes in the command line, where doing an “nme test android”, an “nme test flash”, or an “nme test windows” nets you a working binary on your platform of choice. Very slick. This was the promise of Marmalade too, but for whatever reason Marm is quite finicky. Honestly, I’m shocked Haxe NME has this single command building down so well.
Haxe is a strictly typed Ecmascript (deja vu), inspired by ActionScript. Like Unity, I still haven’t written anything real with it, but it’s interesting.
I do not know Flash… at all, yet I’d like to be able to generate SWFs. FlasCC was on my TODO list, integrating it in to my toolchain so I can target Flash. But it after a quick first look, I’m very impressed with Haxe NME.
One big disadvantage of Haxe NME is the compile time. It does really take a while, far longer than my native stuff. Unity is very instant. I’ve seen some really interesting instant development suites, even better than Unity. If there was a way to speed up the development->test cycle, then Haxe NME would be unstoppable.
On that note…
The Loom folks are doing some interesting work. It’s an entire development framework designed instant update across multiple devices. They too use a strictly typed Ecmascript style language (deja vu 2), but the only targets are PC and Mobile. This isn’t enough. I also get the impression they may be heavily reworking how graphics work from some of the forum posts, where as what I’m after is stablity. But still, as a proof of concept, there’s a lot of potential here. I wish everyone (i.e. HaXE NME) was doing livecoding (make some tweaks to the NekoVM runtime yo
).
Oh also, Loom the language/engine uses the LUA VM (despite being its own language). Smart!
This is one possibility I considered, again, because I like JavaScript. After some digging, I learned that PhoneGap is essentially the native browser for each platform, embedded in an app. That means the app is only as fast as HTML5 runs on the platform, and at the same time, may be as limited (audio).
*Just JavaScript* though, I thought about this, and I am still going to need this from time to time. Web development work especially.
Windows 8, you can work in JavaScript. But that said, I don’t trust Windows 8 as a target. That’s my problem, I don’t trust anyone anymore. If I’m going to do something outrageous like switch my primary development tool, I better get MORE out of it than I had before.
Web presence is something I lack. My time with HTML5/JavaScript has filled in for some of that complete lack of Flash experience, but things like WebGL for IE are a whole major browser version away (maybe a whole major OS revision too). Also audio, I *hope* Mozilla finally adds that missing new audio API by the next Firefox version (audio is great in Chrome), but wow, I can’t believe HTML5 audio is still something that isn’t completely solved yet.
I need to make some time to dabble with both. Ludum Dare 26 is coming up, and I’d like to take this chance to test out Haxe NME. After LD though, I want to dive in to Unity. We’ll see.
Getting the most out of Haxe NME is going to take more work. One of the biggest, most impressive parts of Unity is how well structured and functional it is as an engine. In my native codebase, I’ve architected something that’s design wise on par with Unity, but there is just so much work to do to bring my native engine up to par. Months, the year even, and that’s if I can stay focused. Practically speaking, I can learn Unity in a month, and start seeing serious progress within days and weeks. Doing native addons for Unity does look straightforward, though that does require the pro version. At the same time, I need to spend more time with it to justify ‘going pro unity’.
Will I be able to satisfy my engineering needs with NME? Maybe. I like engine making. I’m going to have to see how deep the Haxe NME rabbit hole goes.
And you, Unity. I hear getting my Oculus Rift working with you is a few clicks and a matter of importing something… You bastard.





WOMEN! For the women’s health clinic I’m working with.
I want to do 6 more. Ideas? Leave me an ask. Otherwise just let me know what you think. I’m going to Key West on Friday and probably won’t be able to crank out any more till I get back.
Red headband girl is pretty clearly Madeleine Flores, winky winky. Hope you like dat ridic muffin top. :B
Things I wouldn’t have thought of without tumblr: Heavier girl w/o baggy clothes, muscular girl, body hair lady. Great ideas!! Thanks you.Also all the skin tones were more varied, but I put an overlay on it that made all the tans kinda similar. Whups.
Gorgeous!
Yes please! Love all the people <3
Golly, it’s been a while hasn’t it.
I posted not too long ago about an ambitious project that brought the classic game Descent to Unreal Engine 3. This teaser trailer just recently hit the internet:
See their site for more info.
A few months ago I wrote about how it is so difficult to submit games to Linux gaming sites, based on my experience with trying to spread the word about the latest update of Stop That Hero!
One of those sites is The Linux Game Tome. It was one of my favorite Linux gaming sites, and had an active forum for developers and players, as well as an IRC channel.
In recent times, it has been plagued with spam and hardware issues. Twice it had been down for months due to a faulty hard drive, for instance. These problems resulted in a lack of activity when it was finally back up. When they updated their forums last summer, it broke the ability to submit games to their database. To this day, Summoning Wars was the last game with an update in June of 2012.
Last month, there was a new post, however, and it wasn’t good news for fans.
The Linux Game Tome will shut down on April 13. Those of us who have maintained happypenguin.org over the years now lack both the time and the ambition to do what is necessary to keep the site afloat.
A later update provided a link to a dump of the game database, all 300+ MB of it, with the idea that someone might be able to recreate the site if they so choose to do so.
Since then, two forums have popped up about how to carry on without the original site operators. One is Resurrecting the Tome, and the other is The Linux Game Tome Ideas and Discussion. I’ll be interested in seeing what comes out of these discussions.
While my new favorite site is the active Gaming on Linux, The Linux Game Tome holds a special place in my heart. I thank Bob Zimbinski, aka bobz, for all he had done, and I wish him luck in whatever his future ambitions are.
The Linux Game Tome Is Shutting Down is a post from: GBGames - Thoughts on Indie Game Development
Hey there! Another swell Galcon 2 beta is available for Kickstarter backers on Windows, Mac, Linux (Ubuntu 12.04), and for a select few, iOS!
I’ve set up a server for Galcon 2 finally, you can try out multiplayer by clicking Play, then Client, then “Quick Join g2s1″ . Other players are hosting modded servers as well, and you can get info about those in the forums.
Linux users who have an Ubuntu 12.04 compatible OS can check it out finally! Also, if you want to run a server on any OS you can now run Galcon 2 with the command line options “-headless -mod path/to/mod_server.lua” to start up a headless server.
I’ve added a ton of new options to the Controls tab in Settings. Check them out and customize your Galcon 2 controls to your preference. Be sure to stop by the forums and tell me which settings you like the best.
And on the Kickstarter reward front, Nan has started packing the fridge magnet sets! Watch for a survey in the mail to fill in your address. To save on shipping, we’re packing the box set with the magnets, so those will be delayed a bit (I hope that’s okay! It means more of the KS funds will be used for the game instead of just for postage.) Here’s a packaging action shot:
P.S. If you want to join in on the iOS beta, keep checking these announcements, and in the Galcon 2 forums. I’ll be inviting a second wave of beta testers sometime in the future.
Yesterday reports that Adam Orth, the guy who somehow caused this shitstorm, is no longer at Microsoft.
Let’s pay attention to the wording here. Resigned. Not fired.
Now, beyond all of the use of the impact font and the “Haha let’s make an internet meme out of this guy we’ve never met” let’s…
Fucking eh! Read it Love it :D
After seeing a post asking for tips on participating in Ludumdare as a team I was inspired to write this. I’ve successfully participated in three global game jams with in person teams, the Boston Festival of Indie Games, and Ludumdare(with St0ven), so I have a bit of experience with jamming as part of a team. There are plenty of other posts that cover the basics of participating in a game jam on your own and many of those suggestions still apply. Here are a few examples:
http://www.ludumdare.com/compo/2012/12/10/greetings-to-all-the-new-guys-a-k-a-folis-inofficial-guide-for-newbies/
http://www.ludumdare.com/compo/2012/12/17/my-tips-what-i-learnt-from-the-fix/
http://www.ludumdare.com/compo/2012/05/06/its-war-a-tiny-world-war-postmortem/
http://www.ludumdare.com/compo/2012/04/08/the-game-jam-survival-guide/
I’ve tried to keep my tips specific to a team environment, so without further ado, here they are.
If possible, form your team ahead of time
This way you know who’s doing what and what style they’re most comfortable with and what they are capable of. There’s nothing worse than trying to find another artist or programmer at the last minute and finding out that the tools they are familiar with or the style they use is completely incompatible with the game you are making. This also helps prevent the problem of too many chefs in the kitchen. If you form your team ahead of time and realize that you have four programmers and no artist then you still have time to split into two or more teams.
Minimize overlapping responsibilities
If you have multiple programmers you should try and break things up so that you aren’t working on the same code. You want to spend your time creating, not merging and bugfixing. If you do want to have multiple programmers working on the main gameplay components then have someone define interfaces early on. This way it’s really easy to drop in new code or change existing behaviour. For artists this may mean having one person do all character art and another do environments or UI.
Reduce bottlenecks and get rid of interruptions
Ideally create a way for artists to add content to the game without having to go through a programmer. Create placeholder assets(empty sounds, blank sprites) that can be easily swapped out without programmer intervention. This allows you to focus on making the game work while they can focus on content and aesthetics. Spend a little more time on making it easy to load in lots of content(It will pay off in a team environment). This also saves you or somebody else from interruptions where someone is asking what they can work on or to add their new content to the game. Make sure that each person has multiple things that they can focus on so that if they can’t progress on one they can switch over to the other. There are always going to be scheduling issues, you may have artists working on stuff while your programmer is asleep or vice versa and you don’t want that to slow down progress. Finally, if you need an uninterrupted block of time to work on something then be clear about it. Make sure that any questions or requests are written down for later or sent via email. I go so far as to sign off of IM/IRC and not check my email if I’m cranking away on something.
Someone should be calling the shots
This doesn’t mean that you need to be a ruthless dictator or that other people can’t make creative contributions but at the end of the day somebody should have an idea in mind for what the final game is going to look like and they should help guide people in that direction. Whoever takes on this role should be capable of understanding what is feasible. As a programmer I find that I am not great at estimating artist workloads and I have to assume that the reverse is true too. Also keep in mind that it’s a 48-72 hour game jam, it’s not the time or place to demand perfection. I always try and encourage people to do their best work and I find that I’m constantly surpirsed and inspired by what they create. If you find yourself in this role make sure you get estimates from the people who are actually doing the work and always be conservative with your estimates. If somebody else is organizing the game then don’t be afraid to say no to them, in the end everyone will be happier with a finished game than an unfinished game that was a really cool idea.
Source Control
Use source control. If everyone is at the same physical location or on some sort of instant messenger then drop box or a network folder can work, but it’s not ideal. You want to spend your time working on your game not mucking around with version control so stick to what you know and keep it simple. Make sure that it’s something that you are familiar with. If you don’t know how to use git or svn then now is not the time to learn it, you’ll just end up frustrated when you try and do anything more complicated than simple commits. If you don’t know a source control system I would recommend using drop box with a backup folder in it for old revisions. If your artists don’t know your source control system but your programmers do then consider using some sort of hybrid where your code is in source control but your art assets are uploaded to dropbox. Recent builds should always be available to everyone on the team. Source control is what allows you to add potentially game breaking tweaks at the last minute without fear or to spend an hour refactoring things to add a new gameplay feature that may or may not work.
Pick an idea early and run with it
This isn’t nessecarily team related but it’s exacerbated in a team environment. It’s easy to waste time trying to come up with the perfect idea. Pick something early on and keep the scope small.
Plan for people to drop out or have other commitments
Focus on the most important parts of your game first so that when somebody can’t continue to participate you can still salvage a game out of what you’ve got. Animation and polish and menus are nice to have but leave it all for the final day. Unexpected things will come up, in fact I don’t think there’s been a single jam that I’ve participated in where everyone has been available for the entire time. If something comes up and you have to take a break or drop out then you should let everyone else on your team know that you can’t participate and if you’ll be back later.
Have fun making games,
-Ben
#include <Servo.h>
Servo myservo;
int potpin = 0;
int val;
void setup() {
Serial.begin(9600);
myservo.attach(9);
}
void loop() {
val = analogRead(potpin);
Serial.println(val);
val = map(val, 62, 540, 0, 179);
myservo.write(val);
delay(15);
}
import os
import pygame
import serial
# guessing serial ports names. Linux or macosx.
#'/dev/tty.usbserial'
ser = serial.Serial('/dev/tty.usbmodem1411',
9600,
timeout = 0)
serial_buffer = ""
# an event number for the SERIAL
SERIAL = pygame.USEREVENT + 1
from pygame.locals import *
Event = pygame.Event
split = os.path.split
pygame.mixer.pre_init(44100, 8, 2, 1024)
pygame.init()
screen = pygame.display.set_mode((640, 480))
message = "Press q to quit, b for blue, r for red."
pygame.display.set_caption(message)
import pygame.examples
example_path = split(pygame.examples.__file__)[0]
example_data = os.path.join(example_path, "data")
sounds = [pygame.mixer.Sound("wiff.wav"),
pygame.mixer.Sound("punch.wav"),
]
going = True
while going:
serial_data = ser.read()
#print (repr(serial_data))
while serial_data:
serial_buffer += serial_data
# if there is a new line in it, then
if "\r\n" in serial_buffer:
#print (repr(serial_buffer))
evt = Event(SERIAL,
{'line': serial_buffer})
pygame.event.post(evt)
serial_buffer = ""
serial_data = ser.read()
events = pygame.event.get()
for event in events:
print (event)
if event.type == KEYDOWN and event.key == K_q:
going = False
if event.type == KEYDOWN and event.key == K_b:
screen.fill(Color("blue"))
if event.type == KEYDOWN and event.key == K_r:
screen.fill(Color("red"))
if event.type == SERIAL:
# read the line from the serial event.
print (repr(event.line))
# clean up, and do sanity checking.
# It could be corrupt or garbage.
line = event.line.replace("\r\n", "")
line = line.replace("\n", "")
line = line.replace("\r", "")
# it could be empty.
if line:
val = int(line)
if val < 1024 and val > 0:
print (repr(val))
# map 0 and 1023 of analog read to
# 0-255 colour colour range.
green = int((val/float(1023))*255 )
screen.fill((0, green, 0))
if val < 100:
sounds[0].play()
if val > 300:
sounds[1].play()
pygame.display.flip()
ser.close()
When you start a new project from scratch, you have a lot of freedom. Adding lines is almost as simple as typing it out and compiling.
As you add more code, however, it starts to constrain itself. You can’t easily add a few lines here because the code over there interacts with it poorly. Eventually, your code starts to rot and smells awful, but you have to work in it. It’s just not as fun nor easy anymore.
The state of your code base is the result of decisions made in the past. Sometimes developers have taken shortcuts to “get things done”, and then they have to suffer by working in stinky, smelly code that makes it difficult to do The Right Thing(tm). Unfortunately, these developers don’t take responsibility for their situation, and they keep doing what got them there in the first place. A colleague of mine says that they get into a state of learned helplessness.
As a result, it becomes easier to accept the state of the code base, to go with the flow, and to forget to be proud of your craft.
Soon, you are taking shortcuts as the normal course of events in large part because the shortcut looks like the main path. The path to creating legacy code (definition: code that doesn’t have tests) looks a lot less tangled than the path of TDD and SOLID principles. The real deception is that doing so creates the barriers, the gnarled weeds and growth, and you need more discipline and more patience to cut through it in order to get back to the right path, if you even bother at all.
Today’s shortcut results in problems with delivering results in a timely manner tomorrow.
The good news is that code is malleable. Even if the current state is bad, it’s possible to improve it, even if just a little.
Each day, you have an opportunity to improve the code for the people following behind you as well as for yourself as you traverse the path through the code again. And each day, despite the cause of the stench, you have the opportunity to use your skills as a software engineer, skills such as refactoring and TDD, to change the code from the stinky state it is in to a better, lemony-fresh state.
The alternative is to wallow in poor quality code, slowing your ability to deliver, and oftentimes adding to the problems that got you here in the first place.
Take responsibility for the quality of your code. It’s possible to have a better code base. Make it happen.
Taking Responsibility For Your Code is a post from: GBGames - Thoughts on Indie Game Development
![]() |
| LED lights with built in heatsink, and a multimeter. |