thoughts about myself and game jams

Sep 15th, 2015
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. 48 hours just isn't long enough to make the kinds of games i want to make. The time limit leads to rushing and badly made things. Game jams are really an exercise in doing things badly. It completely goes against the principle of "Do it once, and do it well".
  3. That said, i don't enjoy game development as much as i once did. Writing the same algorithms over and over gets tiresome. Choosing what mechanics/features to combine can feel as arbitrary as rolling a dice. The ideas behind games have been explored already many times over. And while innovation is still a remote possibility, i don't care that much about innovation, so any game i make feels like a pointless addition to the existing gamut.
  5. So, while 48 hours feels like not enough time to make something worthwhile, any longer feels like too much time to invest on a project i don't find that rewarding or justifiable.
  7. So why did i enjoy game development before and not so much now? what changed?
  9. My interest in game development started when i was very young, at the age of about 5 or 6. At that age I had a rough idea of what computer programs were, but I was surprised that people could write programs as complex as games.
  11. The kinds of games i'm drawn towards making are those hich present problems that i don't feel i have yet mastered.
  13. Examples:
  14. - Procedural generation of puzzles (must have a solution, and solutions aren't luck based. we can specify difficulty)
  15. - Programs to solve puzzles (typically some combination of computation, reduction, and searching)
  16. - Procedural generation of dungeons/levels (interesting structure, and sensible placement of features)
  17. - Procedural generation of graphics (generating tiles/textures. component based character sprites. animations)
  18. - Mob AI (clever decisions, rather than quick)
  19. - Pattern breaking AI (unpredictable enough that you can't learn/exploit it's patterns)
  20. - Adaptive AI (learns to exploit it's opponent's patterns/weaknesses)
  21. - Crowd behaviour (when there are lots of mobs together, they should move similarly, but their path finding isn't simple. Established solutions to this problem aren't always quite what we want.)
  22. - Orthogonal Design (minimise functional overlaps in designed content. eg spells, weapons, items, mobs)
  23. - Strategy Design (complex and interesting depth. equal opportunities. non-transitive. creating balance isn't simple.)
  25. Game jams like Ludum Dare, are not really suitable for tackling these kinds of challenges. The time limit encourages us to focus on safer ideas, with problems we know how to solve. The theme encourages creativity in a very game-oriented context, rather than inviting us to solve particularly challenging problems. And rightly so, because "it is a game jam, not a programming jam".
  27. But even outside of game jams, the game dev scene regularly jokes (and warns) about scope and "feature creep", which I feel broadly channels us into the same way of thinking as in game jams: encouraging us to shy away from particularly challenging problems in favour of something "safe", like a single mechanic, or an art game. No doubt this wisdom is useful to those who hold productivity and creativity in the highest regard, but I don't think that's me.
  29. The trouble is that the problems I want to explore can feel quite dry on their own, yet they are fun to interpret and solve in the context of games. This is perhaps a reason why I remain with game dev scene, despite not enjoying game jams as much. So that I'm not tackling problems like this in isolation. The game dev scene is also an attractive and joyful place, with many wonderful and talented people.
RAW Paste Data