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
I’m quite pleased with how accessible the coding is for a 4X game. As I’m not delving into AI, it’s all a lot of UI systems and its turn based nature makes bug fixing and general logic so much easier! Therefore it’s very buildable.
However the problem is with design, iteration, and a massively convoluted assessment status. Remember why I cancelled Uffizi and Bard Life? Those games took too long to find the fun. PA4X has the same problem. It will take me weeks and months of design before it’s at a stage where players can say they enjoy the game. On top of that, it’s also a lot trickier to balance and design systems for a competitive 4X than a city-builder or idle game, so it just doesn’t make much sense to continue with it at this stage of The Plan.
No greenlight for this game, I’m afraid!
So where am I now?
I’m 11 days before my deadline for The Plan. The Plan was created to help me find a candidate for IGF’s 2015 submission in October. June 1st is when I need to begin working on ‘The Game’. Here are the prototypes I have built during The Plan;
Project BR: A multiplayer survival deathmatch game where you’re given a procedurally generated character and must complete dramatic quests while attempting to survive. Status: Needs an iteration loop.
Grid Optimizer: A simple puzzle game based on optimizing grids. Status: Ready for initial playtests
Ludum Dare 32 Followup: I didn’t discuss this at all on the blog, but Ludum Dare 32 did give me a good candidate game that’s worth investigating. Status: Needs an iteration loop.
PA4X: See above. Status: Red Light
Candidate 3: See below!
As you can see, Project BR, Grid Optimizer and Ludum Dare 32 are all technically in the running.
I have very mixed personal opinions about all of them, which I’ll get into on June 1st. Nonetheless, I still want another candidate game as I’m not satisfied with this selection.
Public Domain Jam / Candidate 3
My final shot at a completely blue sky idea before The Plan ends is Public Domain Jam.
Candidate 3 is a game which I want to get barely playable for the Public Domain Jam deadline, but it is also much more than just a fire-and-forget Game Jam project. I’m aiming for two birds with one stone. A solid Game Jam entry as well as an IGF Candidate. Funnily enough, Public Domain Jam has brought me full circle. I’m back on Machiavelli for this one!
Ventura is the codename for this project, and it’s back to the Renaissance with me. Linking to Public Domain Jam’s goal of being inspired by publicly available written works, I’m using Machiavelli’s writings on the use of mercenaries in Renaissance Italy as the inspiration for this new game project.
Ventura is extremely exciting to me as it brings together so many things I find intensely interesting in the field of Game Design.
It is a medium-term session multiplayer contest, akin to a Dota or League of Legends. I want the game to last around 30-40 minutes.
It involves competing with others, but not just through combat. Economy and strategic development decisions play a massive part.
In Ventura you are one of 4 mercenary captains who is tasked with protecting the City-States of Italy from external threats. You compete with others to fulfil quests and contracts, in the same world.
It’s similar to an MMO RPG quest region, but the core game is built around the idea of making it competitive. You compete for fortune, you compete to find the greatest recruits, you compete to acquire the most powerful loot. Everything that spawns in the game is limited.
When PvE is done, towards the end of the match, PvP begins and you take all that preparation and strategy into a fight to prove who is the strongest Capitano di Ventura.
Like Dota, where you experience an entire RPG in a single session, Ventura gives you a similar experience; but as a distilled MMORPG.
Reading it back now, it sounds crazily ambitious, but I believe I have a lot of very simple-to-build systems that become interesting based on the context of competitive play and a shared world. I’ve also got a combat system in my head that will be very entertaining. Then again, most of it is still in my head at this point… and that’s always too early of a stage to judge viability.
From now until June 1st I will be working on Ventura. Unlike with PA4X, I want to bring back the GSD and share the dev diary style posts I was doing previously.
Then, for better or for worse, I’m picking a game project that’s getting submitted to IGF 2015. Scary times, but unbelievably exciting too!
If you’ve been following the blog, you’ll know that my latest plan is to spend 2 weeks each on two separate candidate games before I really start trying to evaluate which game I need to focus on for IGF 2016. The 504 hours from June 1st > October 31st needs to have as little wiggle-room as possible.
My current project is Project BR, a procedurally generated multiplayer survival deathmatch game. I started proper work on it over 3 weeks ago. The goal was to create a proof of concept, with all core mechanics in the game. 50% past my deadline and I’ve got the mechanics in, but it’s still not ready. After discussions with many friends and peers, I’ve realized that making a single-player demo of the concepts just isn’t going to do the idea justice. I will need that LAN network code at least, which I’ve been told is tricky to implement but not as scary as I assumed.
There’s a point when I just have to say “enough is enough” and start moving on to another project. I’m cheating at the moment! Therefore, Project BR‘s first phase of development; iteration 1, is now officially complete.
Here’s my final GSD;
Most of the last phase of Project BR, the naughty extra week (!), was implementing more of the ‘demo’ features. These are the features I felt the game must have to stand out and show its true colours.
Kids are now generated
This is the coolest thing in the game. This is the reason why I want to do this project. Every character you play in Project BR is generated based on psychological traits, social relationships with other combatants, and a healthy dose of RNG. These numbers all feed into a large system that determines everything about your character. How fast they run, how quietly they walk, how far they can see, if and when they recognize traps, what and how successfully can they craft items. This is all in now, and it’s brilliant! Every kid is unique.
There is now a crafting UI and crafting system, letting players find various ingredients that they can combine to generate new items. I’ve got all temporary data in at the moment, but the system itself is working
So why is the game not done and I haven’t got a prototype to show? Two issues;
The first is that the Line of Sight system, which is so crucial to the exploration and tone of the game, is currently broken when the map scales to a more realistic size. I have ideas for how to fix it, but this will take time.
The second is that if Network Multiplayer is truly just a 1-2 day job… it’s better for me to actually build it and do a real test, than to work on this shoddy and inaccurate single player demo experience.
This is another week’s worth of work at least, and I’m already 1 week over my time limit. So I’m putting it on hold. Iteration 2 is when I’ll add networked multiplayer and iron out the bugs.
Until around mid-May, I won’t work on Project BR anymore. It’s time to start on Candidate 2.
Candidate 2: Post-Apocalyp—- NO! Puzzle Game!
It gives me a little sadness to announce that my Post-Apocalyptic 4X candidate is going to be pushed back. Project BR was a tough process and I’m a little burnt out with learning really new solutions. I need a quick win and the puzzle game I’ve got on my list of candidates is exactly that. I’ve even built it before in the past!
Candidate 2 is what I’ll refer to as a ‘Grid Optimizer’. I won’t go into massive detail about the game here, since it’s so simple and tiny that I might as well just show you it when it’s ready. Nevertheless, here’s my GSD… and this won’t get much bigger for the entire scope of the project;
Look at that! It’s TINY!
Unlike Project BR, when I finish all of these tasks… the game is basically in Alpha. It’s ready. It can be evaluated and played 99% like it would be in a real product. This is the sort of scope I should be aiming for anyway, so it’s a no brainer to do this project for the next 2 weeks.
Unfortunately from a blogging perspective, things will be a little dry. I’m very well aware of the limitations of casual puzzle games; see the Threes/2048 fiasco. Although it’s a great problem to have, being so successful that everyone clones your game, I don’t want to tempt fate. I want to be in the best possible position in case that best/worst-case scenario happens. Therefore, I’ll need to be a little smarter with showcasing my work online.
I’m hoping that I can keep things interesting here by doing a Ludum Dare post-mortem, which will update you on another potential IGF candidate game.
This weekend was Ludum Dare and the theme was An Unconventional Weapon.
Despite having a groan-worthy theme, once again, I had an enjoyable weekend… but alas, I did not complete my game. Much like with the Global Game Jam, I spent way too long doing stuff I hadn’t done before (mainly side-on main character art and animation). I didn’t finish. It was sad.
I’m having a lot of serious issues with predicting and managing scope.
Speaking of which, Project BR is continuing for another weekday of mornings. No new features now, but I need to actually turn it into something playable at this point (whereas as the moment it’s a big collection of systems).
I really need to have it done and dusted by Friday, as Sunday is when Candidate 2 begins. I need to gamify Project BR as quickly as possible and get it out there in the hands of friends and family.
Project BR has been developing nicely and as I come to the end of this phase of production, I’m very happy with what has been accomplished so far. Here’s the GSD;
A quick summary of what was done;
Players can trip over if they’re running and hit an obstacle. For some reason I’ve got it set in my mind that this is the mechanic I need to get right. I want you to feel helpless and weak… tripping makes you feel that way (it takes control from you for a significant period of time) and adds a great mechanic for chases.
Attacking / Being Attacked
This is also rather important in a game about a deathmatch! I’ve never dealt with hitboxes before, or decent collisions. This is in now, and it’s surprisingly not that buggy. I don’t know how good it feels, but it’s working in test conditions.
There’s a UI now. It’s not very functional and many features aren’t supported in-game, but it was a good exercise to design it and figure out how players will interact with the game
You can hold 2 items now, but must switch between them. Until this point, you had to open the inventory to select a new item.
Fog of War
Important for exploration games, and I haven’t got it 100% right yet. I need to work out the kinks, but it basically works well for hiding/revealing structures and the ‘blueprint’ of the map.
Supporting more than one player object
This is one thing that I had to do, which was extremely boring and tedious (and buggy) to implement. Until now, everything in the game was centred around a single player object. In the real game, this is also the case, but for the Demo I need local multiplayer fighting so it had to be built.
Well the plan was to be finished on Sunday (12th) and to move on to Candidate 2, my post-apocalyptic 4X prototype. However I’m not finished with Project BR‘s demo yet and Ludum Dare is this weekend, so I’d rather not start a new project with such a major distraction in the middle.
I’ll be spending the rest of my weekdays preparing the Project BR demo as much as I can, and there’s plenty to do on it!
After Ludum Dare, I will switch to Candidate 2.
My next post should be before the big weekend, see you then!
Progress on Project BR has been flying so, without further ado, here’s the GSD;
I lost my development virginity on a ton of things;
Working Inventory and Gathering system
Totally hacky sound radius system
‘Line of Sight’… I used a friend’s solution so I didn’t actually develop this! I do have to tweak it though, which I’m dreading.
Animations and integration
It was all a lot of fun to develop, and surprisingly easy. This seems to be my general thought with programming; it’s surprisingly easy. I’m sure when I start working on more nuanced and polished mechanics I’ll get to the hard stuff where I need things like… maths.
This post is actually delayed by a few days and I’ve done so much more since then. I’ll get that update in before the final 2-week mark ‘post-mortem’ where I’m supposed to stop working and show people what I’ve done.
One major concern I have is that it isn’t a game yet, and it won’t be one by Sunday. Evaluating how ‘fun’ it is will be very difficult at this point. Perhaps for this first playtest, I will just watch silently as people interact with the character and the area… taking notes on control schemes and various issues they have.
Another option is to create a quest for the players to achieve, which encourages them to interact with the area and perform many of the tasks that they would do in the ‘real game’. This is something The Stanley Parable did with its non-spoiler demo. The final option is to do the previous idea and also add in a little same-screen combat demo.
Plenty of food for thought! I’m very aware that ‘finding the fun’ too late has been my number one weakness, so I’m hoping to avoid that again.
The Plan is underway and I’ve been working on my Candidate 1 prototype; which I’m calling Project BR.
Project BR is a top-down survival multiplayer deathmatch game. This project is inspired by DayZ, Hotline Miami, and various ‘Most Dangerous Game’ fiction like Battle Royale (where the BR comes from), Hunger Games, Maze Runner, and The Running Man.
You are one of 20-40 procedurally generated characters, from a procedurally generated group (each player is connected in some way), on a procedurally generated map. The exact theme; whether it be schoolkids, graduates, prisoners, office workers, or abducted human slaves (!), is to be confirmed.
You must take your character and try to become the last man/woman standing. The core focus of the game is exploration and combat, with the former providing you with items to power you up and targets to fight with for the latter. Supplementing these two tenets is streamlined crafting, a basic survival needs system, and various motivation changers that promote complex social interaction as opposed to ‘shoot on sight’.
I’m super excited about this project.
As with Bard Life, I’ve been using the GSD to track what I need to do and how much progress I’ve made;
My goal is to spend another week on this prototype, building all basic core features, before sharing it with friends & family and moving on to Candidate 2. Based on the feedback I get and the development of Candidate 2, I’ll have a greenlight decision to confirm if Project BR has what it takes for The Game (the product of The Plan!), and whether I will give it another round of development or not.