You can download the mp3 of the podcast, play it in the embedded player below, or you can follow us on iTunes.
Topics discussed in this episode include:
- What are game jams and why we like them
- Examples of jams, including 7DRL Challenge, Ludum Dare, Global Game Jam, F*** This Jam, Molyjam, Experimental Gameplay Project, TIGJam Get Togethers, Indie Buskers, 0hgame jam, Glorious Trainwrecks, Popovkast
- Planning in advance vs last-minute design
- Advantages of jams: creativity through constraints, having fun, cool/weird/novel challenges, socialising, solidarity, deadlines force you to finish, small victories, throwaway nature of result, experimentation, learning new things, forcing you to try new things
- Maintaining games after jams are over (and the complete lack of this happening)
- Getting addicted to jams and having jams interrupt bigger projects
- Going to physical jams and meeting other developers (it's fun! - unless you're Ido, he's boring) and potentially forming collaborations
- Why roguelikes are good for jams, yet why they're rarely made
- Innovation in the Seven Day Roguelike Challenge
- CompoHub - find out about all current and upcoming game jams
- Reddit /r/GameJams
Some recent examples of jam games made by the speakers:
- F*** This Jam by Darren Grey, a clickfest action RPG
- Pimps vs Vampires by Zapa, a roguelikelike shooter
- McPixel by Sos Sosowski, a point and click adventure originally made for Ludum Dare 21, which is now on Steam
- VESPER.5 by Michael Brough, a turn-based explorer where you can only take one move a day
- Pakkuman's Defense by Ido Yehieli, a mix between tower defense and pacman.
Join us next week for a look at strategy games! With a special expert guest!
Yet another great podcast! (Is YAGP going to become a major acronym like YAVP/YASD?)
ReplyDeleteThe talk on playtesting jam games is interesting. As someone who doesn't really have ideas for games but loves playing them and witnessing other people's creativity, I never really paid attention to jams while they happened before, instead prefering to browse through the results. But now that that concept has been brought up, perhaps I'll find a jam in progress one day and just offer to be a roving playtester. Hmmm.
YAGP indeed!
ReplyDeleteI've been waiting for 7DRL now ever since I started following this show, and will finally have a chance to participate in GGJ 2013 as well. Hopefully a good reason to finish something :P
Fuck 'Fuck this jam''s name. I'm going to have to figure out how to manually stamp this particular RSS feed with 'Explicit'... grumble.
ReplyDeleteAnd YAGP.
DeleteI've edited the post to remove the offending word. Of course now you've polluted the comments section... ;)
DeleteMichael Brough has made a good blog post following on from this episode about Jamming:
ReplyDeletehttp://mightyvision.blogspot.co.uk/2012/11/jamming.html
It touches on something I meant to raise in the podcast - people who have negative attitudes towards jams. My general opinion is "screw them", but Michael is much more eloquent in his post.
Traditionally you'd want a numpad? There's nothing traditional about using a numpad to play Roguelikes! That honour belongs to Vi keys.
ReplyDeleteI'd be interested to know what langauges and libraries the participants use for game jams and whether they are the same as they use normally. I think I would like to give game jamming a try but if I use the same toolset that I do usually after eight hours I'll still be setting up the include folders!
ReplyDeleteUsing the same tools as usual is good for getting things done quickly because you're not grappling with unfamiliar technology at the same time. Some tools (e.g. Twine) are really quick to use but less versatile though, good for jamming.
DeleteYou shouldn't be throwing away eight hours achieving nothing at the start of anything though! Make a base project with whatever you need already set up that you can just copy to get started, don't duplicate effort. Over time you'll accumulate a lot of helpful utility functions that you use again and again.
Definitely re-use existing code as much as possible. I have a stripped down version of one of my T-Engine modules ready for game jams, with new content quick to add (Lua makes this nice and easy). I have lots of example code I can cut and paste from other modules I've made, or from ToME4.
DeleteBefore I got into the T-Engine I used FreePascal, and I used the same tactic of reusing the gutted remains of other games. The basic architecture was all there, I just needed to add the meat to the bones.
Having said all that, my first use of the T-Engine was during a 7DRL week, when I learned Lua and the T-Engine from scratch whilst making a highly ambitious game. This is not something I'd recommend, but it did work out well in the end. As I said on the podcast, game jams can be a great way of forcing you to learn something quickly :)
I'll be using Unity3D, as that's what I use professionally too. It has required me to build some custom functionality into it in order to get something that looks like a 2D roguelike though, so some preparation is required.
DeleteThe engine itself is extremely powerful and flexible, utilizing the component object model for plug 'n play reuse of gameplay logic. So once set up, it is very efficient to work with.
The Asset Store is also very helpful, since it's packed with different types of content. For my roguelike "package" I'm using Coherent Noise library and 2D Toolkit. I might use Playmaker too for some nice visual state machine scripting if it makes sense.
The really cool thing about Unity3D is the tight interaction between the editor UI and the .NET scripting engine. It's really easy to add elements to the UI via script, and as such also very easy to add tweaking bars for the procedural algorithms, that you may tweak it with instant graphical feedback.
The free version of Unity3D should be more than enough for creating a roguelike also... so it's a really good option I think :)