This is Post 4 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.
Up until now, most projects I’ve discussed on Redlight have been mainly stalled due to scope. Grid Optimizer is the complete opposite problem; it’s just not exciting to me. I’ve never really introduced the project on my blog, as it’s so simple that I felt it wouldn’t make for stimulating reading. But here’s a screenshot…
In a nutshell, Grid Optimizer is a puzzle game about arranging Factories, Power, and Boosts in a way that maximise your output. Your pieces are randomized, creating endless content. In a way it is the perfect project for me. The scope is tiny, the coding is tiny, the design is easy. If I had to make a game in 6 months to put food on the table, it would be Grid Optimizer.
But I’m not doing that, I’m trying to work on a seductive and exciting passion project. Much like PA4X, I have only one redlight reason…
Redlight Reason #1:It’s not exciting enough
There are a lot of mini-reasons inside this one but ultimately they all come from this. The game is casual, which means free-to-play, which means mobile. Mobile is not good for indie developers. Yes you can cite a Flappy Bird or 2048 (poor Threes), but those are product of their time and place. I don’t truly believe that you can craft a mobile success as an indie, you have to get extremely lucky whilst also hitting a perfect storm of great timing, apt sentiment in the market (i.e. Crossy Road), a solid USP, and THEN you want to make sure you get it perfect first time. Because if you don’t, you will get cloned. You’ll get cloned anyway, but if you did a perfect job first time then it’s harder for the Katchapps of the world to steal your shit.
This was the final day of Redlight, next I will be updating you all on why I picked Ventura as The Game… then explaining some exciting plans for the future.
This is Post 3 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.
PA4X is an interesting case about the deception of game development scope. As a quick summary, you can read my PA4X announcement for more details about the game. In essence it’s a 4X game (a la Civilization) with a heavy multiplayer focus; short turn times with a single moving city, simulating your peoples’ struggle in a broken world.
It was surprisingly easy to build many of the systems. I had Biomes working, a 4X grid, a pre-built pathfinding solution, turns, building stuff, resource generation… plenty of systems. Civilization V as a system is easy to build. So what went wrong?
Redlight Reason #1:Too much backend to find the fun
This is the one and only reason why PA4X is getting a red light. Despite knowing that a 4X game is fun (I’m currently playing another epic game of Civilization V), it’s going to take a long long time to get it into a state where it’s actually fun. When you think about it, Civilization isn’t really that fun of a first play experience. It’s slow, nothing really happens (bar finding a goody hut), you haven’t got many choices. The reason Civilization V works is because it is a massively complex system of moving parts that you will get into eventually. Civ V is built on the promise of emergent gameplay based on its humongous content generating machine. Therefore my theory is that PA4X would not be fun until I have a humongous content generating machine… and that will take a long time and a lot of risk.
The number one lesson I’ve learnt from my 2 year-long indie game development project is that finding the fun early is super important. Too many times, I’ve fallen down the rabbit hole in the search for a fun game… wasting months of time and effort to eventually find nothing. Not this time. So that’s why PA4X is getting the red light.
Nevertheless, a 4X design is almost entirely Game Design/System Design focussed. This prototype proved that building the mechanics is actually not hard at all. All the challenge is in Game Design. I do like that. I like it a lot. I’m sure that one day I will come back to this prototype, as it’s perfect for my skill set.
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
This is Post 1 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.
Squire Power / Ludum Dare 32
I never really discussed my failed Ludum Dare 32 project for a number of reasons. The first is that I was upset about it! Ludum Dare only happens 4 times a year, and I’ve put a lot of value into it as a determinant of how well I’m doing as a Game Designer. It creates a beautiful level playing field, with integrated feedback and scoring systems that I can use to judge how good I am on a given day (or weekend). My hope is for every project to do better than the last.
For this Ludum Dare, I picked a project I could build quite easily with regards to programming. It used a lot of systems I’d actually just built in the Project BR prototype; so I wasn’t worried about technical scope. What I did wrong was art. For some reason I decided that my game needed a fully animated combatant and I spent about 1/3 of my entire time creating and integrating animations. Massive, massive fail… especially as that’s exactly what I did wrong for Global Game Jam!
So what is Squire Power?
Squire Power is an interesting hybrid between a tower defense, akin to Swords & Soldiers, and an inventory management game. You are the Squire for ‘The Immortal’, a 1000 year old warrior who protects the land from the forces of evil.
As you can see on the screen above, the centre stage is dedicated to a Battle Window. The Immortal will stand in the centre, as monsters slowly creep towards her from either side of the screen. If a monster moves into her range, The Immortal will attack it. Monsters die in one hit, but only if The Immortal is holding the correct Weapon.
This is where you come in. Monsters are of a certain affinity, determining which weapon will kill them if they enter The Immortal’s attack range. The numbered boxes surrounding the Battle Window are your Inventory Slots. Your job is to pick up certain items from inside the boxes and place them in the Red or Blue slots; which represent The Immortal’s left and right hands. If The Immortal has the right weapon for the nearest monster when it comes into range, she will slay it. If she has the wrong weapon, her attack will have no effect. If a monster reaches her hitbox, she will take damage.
At its very basic level, Squire Power is about judging which monsters will reach The Immortal first and then planning your inventory so you can switch weapons in time to react to the spawning enemies. For Ludum Dare I had this basic mechanic done and dusted; 3 weapon types, 3 monster types.
The second mechanic is the Anger/Intoxication meters. As an Immortal, your companion can’t actually die. When a monster hits her, she just gets angry. The premise of the game is that The Immortal is a horribly traumatized, violently angry, alcoholic. You’re not supposed to like this character at the beginning. She is heralded as this glorious hero but when you meet her, she’s abusive and cruel.
When her Anger meter reaches 100, the game is over… you’re fired. The main technique for reducing her rage is to supply her with Wine, whenever she requests it. During combat, The Immortal will occasionally yell at you to provide her with Wine. To give her Wine, you must remove a Weapon from one of her hands and place the Wine item in that slot before the timer runs out. If you fail, her Anger increases. If you succeed, it decreases. At its simplest level, providing Wine leaves The Immortal open to attack and gives the player with a hectic scramble to make sure they get that Wine in her hands before the timer is over.
You should be a good Squire and constantly give her Wine, right? Then The Immortal will always be happy and you won’t get fired. WRONG!
To counteract liberal alcohol abuse, The Immortal also has an Intoxication meter. When this reaches 100, she will be disabled for around 5 seconds in order to puke. Yes, she vomits mid-battle. Your job is to carefully decide when it is a good time to give her Wine and when it is a good time to take an Anger hit.
This mechanic I had done for Ludum Dare.
So why didn’t I finish?
This is a really important question. I had the mechanics, and I had the animations. Why didn’t I just submit the little content I had? I guess I have no excuse.
At the time I felt pretty bad. I realized I wasn’t ever going to make the 48 hour Compo submission (which is the reason I do Ludum Dare). I realized that the simple mechanics needed more to them to really be a decent game. I spent a lot of time building an augmentation system, where you could apply potions to weapons to grant them new capabilities… it failed. I just couldn’t get it to work.
Another reason I just dropped the game jam was because I needed to build a narrative for this project. Having an abusive, violent, alcoholic anti-hero requires some context… I don’t want to create some stereotypical shallow bullshit about a traumatised warrior. We have enough of that. I wanted each level to have a short amount of story and dialogue, developing your relationship with The Immortal and providing important backstory that helps you understand her plight. I want her to grow as a character and not just be a pathetic caricature of a serious issue (Alcoholism).
I didn’t have time for this. I didn’t have time to build the dialogue UI feature, I didn’t have time to make enough hand-crafted levels, I didn’t have time to build those additional gameplay features that would give the game some meat. If I didn’t ‘waste’ time on animation, I would have had this stuff in.
I didn’t want to release a demo for Ludum Dare, I wanted to release a whole game; much like I did for Silian Rail.
On Squire Power’s IGF Candidacy
I am still very much enthralled with the concept of Squire Power, so I kept it as a possible IGF project. With that additional time, I could develop those interesting inventory management mechanics (more than just dragging and dropping the right weapons like ‘Simon Says’). With that additional time, I could develop a nuanced story that respectfully deals with addiction and tells a fascinating gritty fantasy story.
So why the red light?
Redlight Reason #1:I’m an awful writer
I’ve been trying to improve my writing, and I joined Storium in order to practice, but I’m just not ready for it. I don’t have the skill to take on these complex moral issues. The narrative is such an important part of the game concept, and why I find it interesting, so I can’t just sacrifice it.
Redlight Reason #2:Requires a lot more prototyping to prove it’s not a gimmick
In my head, Squire Power’s potential mechanics are very interesting. Imagine having to repair items, craft potions, and build tools during battle that lead into more unique items… I think these would all work quite well. But it’s such a weird concept of a game that I would really need to spend a good 2-weeks to a month on just messing around with mechanics. I could create something amazing, I’m sure, but it’s still a big risk and I can’t take on a project that’s ‘cancellable’ at this stage in The Plan
Redlight Reason #3:The game design isn’t turning me on.
I do really like the idea of Squire Power but mechanically it’s just not that interesting to me. I worry that much of the game will end up like a Puzzle to solve… with level designs at the harder difficulties relying on a single ‘best way to play’. That isn’t the type of game I want to make. I hate playing the ‘default’ way, I hate cookie cutter playstyles. There are probably a myriad of ways to solve this, but right now I need low hanging fruit and this ain’t it.
So that’s why Squire Power is not The Game for IGF. I’ll definitely keep it on the back burners for a future project, but for now… The Immortal is dead!
A double header with this post, as I promised a little look into my Task generation and it happens to be June 1st!
On March 11th I announced The Plan which was a period of prototyping and experimenting to find The Game, an ideal project for me to submit to IGF 2016; the deadline of which is in October. Two and a half months has flown by and a lot has happened;
Bard Life was cancelled
Ludum Dare 32 happened
Project BR was started
Project Grid Optimizer was started
Project P4AX was started
Project Ventura was started
With each of these projects I took anywhere from a tip toe to a full on nose dive into development. The goal was to be able to assess each of these projects and then lock one down as The Game by 1st June.
1st June has come and G-Day is here, so what is the project?
I’ll get into some details about why I picked Ventura over the others at the end of the week, but for the next 6 days I’ll have weekday update ‘Greenlight’ posts about what went right, what went wrong, and why I rejected all the other projects.
So what happens to The Plan now? Well Ventura is locked in, it’s getting made… it’s getting made for the end of October. No excuses, no changing my mind. It’s happening. The extent of how far I will get into the project by IGF submission day is something we’ll discuss over the coming weeks, but my basic goal is to have it fully functioning (perhaps without pretty art) by that point.
Ventura Day 10
Last time we talked about my first steps into the Task generation system. This is the lynchpin of Ventura’s whole design. City States will request things of the players in-game, what those things are is down to the Task Generation system.
It all starts with a Task Type, this is the ‘Raid’, ‘Rescue’, ‘Extort’, and ‘Scout’ in the UI above. This is the general behaviour that the player has to perform to complete the Task. I currently have 12 of these types planned, which should create a ton of variety between all the Tasks.
When a City decides to generate a Task, it picks the Task Type. As I develop the game, I want Civilization V-esque personalities for the Cities… which adds a little predictability and flavour to each location. At the moment, there’s a basic dice roll to pick the Task
When the Task Type is generated it has to run its own unique script to determine which Objectives are needed to complete it. In my prototype, I have the ‘Rescue’ task implemented. This task is themed as the city having a respected noble kidnapped by bandits.
The Rescue Task needs a location on the map that players can visit, a battle that they can fight, and then it has a completion behaviour which determines if the player needs to return to the City to claim their rewards or if the Task is complete as soon as the battle is over.
The Location for the task is based on the specific Task Type. Rescue Tasks will specify either an Industrial area (i.e. a Mine, Farm, Workshop) or a Dungeon (i.e. Abandoned castle, spooky forest). When Rescue has been decided as the Task Type, it then adds every possible Location into a list. From that list it picks an object and places the Task Behaviour inside.
When a player interacts with a Task Location, it will perform the Task Behaviour.
Most Task Types involve a battle for players to fight. In the Rescue Task Type, players must fight a single battle to release the prisoner. Once the Location is set, the system then generates a battle.
Battles can have up to 8 enemy units inside. The specific units picked for battle is based on the theme of the Location (a Mine will be based around a Bandit fight, a Dungeon around a Monster fight) and the difficulty of the engagement. This difficulty is based on the original city’s task creation.
The Battle Generation looks at the objective location, taking its theme. It then looks at the city, taking its difficulty. It mashes those 2 together and then randomly picks from various hand-crafted configurations of unit types.
This is what I have done so far. The plan is for the unit types to then be placed in the Battle scenario based on various terrain features of the Location. Once that’s done, there’s a whole Combat System I haven’t built yet so this is all groundwork!
Day 10 GSD
A lot of work has gone into the Task Generation, as you can see from the screen above, and I’ve expanded out the GSD to help track the holistic functionality of the feature;
As you can see, there is a lot of green! Basic game functionality is very much in progress. The next big thing is to start speccing out the Combat System. That will be large… very large.