This is Post 2 discussing my project greenlight process. To add a little context, I’ve been working on locking down a perfect project for IGF 2016 submission. These posts will discuss a project and why I’ve red-lighted it. At the end, I’ll make a post about why I’ve greenlit Ventura.
The majority of detail about Project BR is in the introduction post about it. But in essence it’s a network multiplayer survival deathmatch; where you are given a procedurally generated combatant and have to earn the most points (either by surviving as long as possible or completing procedurally generated ‘Dramatic Quests’) before the game ends. You can equip weapons, set traps, craft, and attack one another. It’s a pretty cool game, and is by far the most advanced prototype I have at this point.
So why is did it get the Redlight?
- Redlight Reason #1: Advanced Network Code
As a real-time 40 man action game, Project BR would require some serious network code. I’m not a coder by trade and I’m terrible at it. I would need to hire someone to get it working.
- Redlight Reason #2: Real-time brawling is tough to get right
Reason 1 unfortunately is enough to postpone the project already, but this is a close second. Still related to my programming ability, Project BR needs a juicy, visceral combat system. I’ve never built one before and the maths required to get the action and movement perfect is beyond me currently. I think I could learn it, but it’s a big risk.
- Redlight Reason #3: Assets
Action games need a lot of art, mainly on the animation side. This game requires animations for all the weapons, various movement animations, plus world creation assets and a variety of different character models. I emphasized ‘requires’ because the game needs this stuff to even be playable. A game like Ventura also has a lot of assets, but they don’t actually impact the game that much. It’s just polish