I’m taking a few hours tonight to go through the archives and put up some of my finished/unreleased/unfinished game jam projects onto github. Ludum Dare 26 is next weekend and I want to have a simple URL to send people to to try out my stuff.
I’m up and running with BJL, Linux, and a sample “Hello World” app. Special shout out and thanks goes to JagChris for the handy dandy BJL cable.
Next step: add some animation to the screen to get a handle on how that sort of thing works.
Syrup Dispensers From Hell is coming along quite well. I’ve decided to use the Legend of Sadness base for the game, which plays and looks a lot like a Legend of Zelda title. Instead of having our hero travel into a cave, he’ll be travelling into a breakfast restaurant to save us all from horrid syrup dispensers.
This time around I’ve got a lot more experience working with Akihabara so I’ve been able to work harder on gameplay and graphics rather than learning how the game engine works. Designing tilemaps for a game, as a programmer, is tough work. It’s not that I dislike working on art or even that I’m not artistic, but what looks great in The Gimp looks like shit when it’s tiled a hundred times.
Doing graphics for a game is basically incrementalism combined with healthy doses of iteration. You tweak a pixel, test it in-game, hate it, go back, tweak another pixel, hate it, go back, and so on.
A neat feature that I discovered today was Akihabara’s ability to scale the size of the game display by a value that is less than 1, meaning that it does not need to zoom to an integer value. Currently I’ve got the game displaying at 320×240 with a zoom of 2.5, making that actual output 800×600.
Well, back to work :)
The second Guelph Game Jam has just started at the ThreeFortyNine co-workspace. The goal? To make a game in less than a day. We have about 8 hours to design, build, and test our games. Then the last bit of time is spent playing everyone else’s game.
I did this a few months ago and thoroughly enjoyed it.
The theme this time is ‘Monsters.’ The game designer can take that in any way, whether it be about monsters, being a monster, defeating monsters, etc.
As was the case last time, I’ll be live-blogging my progress here and on my BitBuilder game developer Twitter account.
Got the game loading and playing in Firefox, but doesn’t even try to load in Chrome. I have no idea why. It seems I’ve spent about twice as much time debugging as I have developing. For this stuff to work, that has to change.
Almost have the game loading, however. Making progress.
Note for anyone who is working on an Akihabara JS game: making a directory inside the unzipped Akihabara directory then trying to include the Akihabara files by ../akihabara/*.js does not work as JS in the browser cannot access stuff outside of its own domain.
If you wanna track my progress on BastardBlaster, my game for the Guelph Game Jam, check out my GitHub repo.
The game is GPL and is based on Solitude from the Akihabara HTML5/JS game platform.
The proverbial gunshot has been fired and all the developers here at the Guelph Game Jam have started work. I’m included in that list and will be liveblogging my experience, all its ups and downs included.
The theme for this Game Jam is “Big”. Whatever that means is up to you and how you choose to use it in your game is also up to you!
As for myself, I’m thinking Rampage meets Gradius.
I haven’t touched anything to do with level design or game development in a few months as there have been a few other important issues and projects to tackle. But, with the upcoming Christmas holidays, I’ve decided to take 2009 and really flesh out some C++ and torquescript skills and maybe do some creative work, such as 3D modeling and music. I’ve installed VC2005 and VC2008 along with Torque Game Engine Advanced and Torque Game Builder. Let’s rock.
I’m really excited. I’ll be posting all of the work that I complete in the Game Development, Game Art, Xandorus, and Torque categories.
If I had tons of money…
I’d hire a crack team to develop software for videogame character modeling that is similar to the modeling system used in the upcoming game Spore.
The premise is simple: You open a program on your computer that is only based around modeling characters or animals. You create things like legs, arms, heads, torsos, and any other body accessories you wish using a simple, to-the-point editor. Really newb friendly. After painting your texture like spraypaint (or by importing from an image), the modeling program procedurally generates the animations and exports to an industry-standard, open-source model + animation format that every major 3D engine supports.
Of course, we’re miles and miles away from something this useful.
The current system for developing models using computers is absolutely horrendous. It’s not that I’m criticizing the functionality of any of the major modeling programs or teams. Far from it. Obviously those artists who spend the time, get an education in the field, and are uniquely talented can and do create some fantastic scenes for us all to view whether it be still shots, games, or video.
The problem is that the tools are too extensive for the needs of an indie videogame designer. If you don’t know how to model, texture wrap, rig, animate, export, and then import your models, or you don’t know anyone who does, or if you have no funds to pay for someone to model for you, then you’re simply not going to be able to make a 3D game and tell your story. In this case, your only solution is to go 2D with tools likeÂ RPG Maker VX or Torque Game Builder, which are at the top of their class for 2D.
It’s disappointing because there are so many neat 3D games started by so many small teams these days and we’ve all got a large amount of free (or very low cost) 3D technology, but unless you’ve got a lot of time, a lot of money, or somehow a lifetime of game development knowledge, it’s very hard to produce an indie 3D game.
There are companies who are striving (and doing great work I might add) to give indies a chance by building just the tools I am blogging about (case in point: GarageGames), but there is still one area where complexity reigns supreme: modeling and animation.
Let’s look at the current setup.
First, as an aspiring modeler you’ve basically got two choices: a powerful yet completely unintuitive open-source solution (Blender), or software piracy to download and use an industry-standard but insanely expensive and closed solution (Lightwave, Maya, 3DS Max, et. al).
Then, after installing the software, the file formats that each program use are not entirely and completely interchangeable. It’s a bit like the different floppy disk formats of the 1980s. The files on each of the disks were the same but each had a special format, key, physical size difference, or other attribute that kept them almost entirely proprietary.
In between each of these programs is a completely unique interface. It’s not like the difference between Google Docs, Open Office, and Microsoft Word, of which you might spend a total of 30 seconds figuring out where everything is. No, these all feature user interfaces that contain so many powerful tools that they have their own scrollbar. We’re literally talking feature overload, here.
A few examples:
After you finally make your model and texture it, you have to rig it by placing bones and joints inside manually that will give your player the skeleton it needs in order to move. That sentence might take you weeks to finish if you’ve never done it before. With your skeleton in place you need to animate it by using a keyframer. As your skeleton moves, your model’s body will follow suit.
Hopefully and with any luck, the program you’re using will have an exporter that will export your model in the format your game engine can support. For Quake and Half Life that was Md2. For Torque, it’s DTS.
If by this point you’ve like me and you’re wondering why modeling a character for your 3D videogame can’t be simpler then at least I’m not alone! So, what’s the solution at this stage of the game? You tell me.