New Features, a Combat Test Demo Video, and More!

It’s been too long since I have written a blog post!

Let’s begin with the progress we have made on Schism over the past two or three days.  Brandon created a sweet algorithm to calculate trajectories for thrown objects which I turned into a new combat mechanic that allows the player to throw equipped items, i.e. grenades, in combat mode.  It took a while, and about 100 emails to Brandon in order to get all of the functionality right.  I needed the “targeting ring” to attach flat to whatever surface the trajectory was contacting which really gave me fits, a method to allow the player to “cook off” the grenade timer, and several other features that I really struggled with until now, it all works just as we want it too.

Here is a quick, rough video demo I just created to show you some of these features.  Forgive the programmer art; I probably should have spiced the scene up.  I’ll do that the next time.

Lets see; what else did we do these past couple of weeks.  Brandon ironed out some of the character animations and got us working with our AI navmesh properly and has been working on some 3D modeling and texturing.  We recently purchased a license for the Bitmap2Material software from Allegorithmic.  Eventually we would like to purchase licenses for Substance Painter and Substance Designer as well, but they are just not in our budget right now.

I had some adventures and misadventures upgrading some hardware and trying to migrate to Windows 8.1.  That was frustrating.  I really like Windows 8.1 but unfortunately my video cards are just not supported by AMD anymore so I couldn’t find stable enough drivers and had to go back to Windows 7.  I can’t afford to buy new cards at this point.

Thanks to my friend Jason Fox, we are now part of the Microsoft BizSpark Program which is really cool.  This gives us free membership to the Microsoft Developers Network as well as support and visibility.  I’m very grateful to Jason for pushing it through for us.

We are going to start pushing really hard for an alpha release that we can use to drum up support for a Kickstarter Campaign, hopefully within the next couple of months.  In order to finish Schism, we are going to need some financial support in order to purchase the hardware and software we are going to need in order to make the vision we have for Schism come to life.  We want the final product to have the “indie spirit” yet look almost like an expensive AAA game.  I do believe that both of those goals are achievable if we can get the time and tools necessary to do it, and unfortunately, that requires a certain amount of capital.  So get ready for that.  We really hope to have your support!

I know there are some things I am leaving out!  I invite Brandon to post further comments if he has anything he wants to add as well!  And as always, if you have any questions about the game or the development process, please feel free to comment.  Also, look me up on Twitter!


Bring on the Assets

It’s been a rough week.  But we did get some things accomplished on Schism.  Last week I talked about the AI and the code I was working on for the enemy combat logic.  We decided to go ahead and incorporate a free, third-party asset for all of the pathfinding AI called RAIN by a great group of AI developers called rival{Theory}.  Note: The version of RAIN available of the Unity Asset Store is outdated; if you are interested in it, download the newest version directly from rival{Theory}’s website.  So far we are having good success with it although we have taken a pretty decent hit in performance.  I believe that a lot of that will be ironed out when we are able to upgrade to Unity Pro version.

With RAIN, Brandon has created a system that allows our player characters to move from point A to point B while in combat while navigating around obstacles whereas before, the characters simply ran through them or got hung up trying.  I love seeing the characters figure out the best paths to take to get to their objective.  This is a really important step for Schism.  With RAIN Brandon has also demonstrated how easy it is to establish “patrols” for our enemies so they can wander around on the map now instead of just standing idle.  And it works seamlessly with my enemy detection system.

It is amazing to me that this powerful AI system has been offered for no cost to the game development community by rival{Theory} when they could easily be profiting from it.  A big shout out to Prime and the rest of the rival{Theory} team.  We expect to continue to use RAIN for most of our AI needs as we move forward with Schism and quite possibly with future Lunatic Fringe Games’ titles.

I talked previously about the complicated dialog and narrative system we are wanting to create for Schism.  Brandon and I have both been thinking about how we can achieve that goal.  The design and programming necessary to make that happen are possibly the most technically challenging aspects of the game.  So yesterday, Brandon proposed an idea that I instantly agreed with: for the time being, we are going to develop Schism with a more traditional “tree-based” dialog system.  The goal is to get the game ready to demo for a crowdfunding campaign so that we may get funding to build the actual narrative system we want to create (and other features as well).  To this end, we went ahead and purchased the Dialogue System for Unity by Pixel Crushers.  With this asset we hope to easily create our character interaction dialog, quests, “barks” and even cut-scenes.  I haven’t started using it yet but it is one of my goals for the day.  I’ll post more about this soon.  So, I better get to it!  Thanks for reading and please feel free to leave and questions or comments below.





Create Something New

As I was getting the most recent build of Schism ready to Demo to Brandon last night I was really able to see some of the concepts I have had from the beginning about what I wanted this game to be coming together. 

I think one of the major complaints about the video game industry, particularly in AAA game development, is that there are really only a handful of genres and that many games are simply emulating countless other games.  And really that is OK, to an extent.  I had a great conversation with a game developer / friend,   Łukasz Szymański (@Luke_Szymanski) who talked about needing to do something different while at the same maintaining a certain level of familiarity to the player.  As with most thing I spoke to Luke about, I couldn’t agree more.

Stephanie has been extremely supportive of this project but the one thing she iterates to me over and over is that I need to do something “different”; Something that people haven’t already seen.  This is a challenge of all creative media.  It is easy to get locked into the idea that everything has already be done; that there are no “original” ideas to be had, they have all been taken.  All of this leads up to the point of this Blog entry: I would like to talk about some of the things that I think will make Schism stand out as “different.”

It’s always a little frightening to reveal your designs before something is fully created.  In the beginning I felt like I needed to keep them secret so no one would “steal” them.  But one thing I love about the “indie” game developers that really make them different in and of themselves, from the AAA developers is their transparency.  We are an open bunch!  And no one really reads this blog anyway so what do I have to lose!

I think the first “Stand-out” feature of Schism, and the foundation to which it is built around is the two modes that the gameplay occurs in.  This, alone, is not that original, I know.  Many games have different modes.  JRPGs are famous for dividing their games into “explore” mode and “combat” mode.  Typically, you have a party of characters yet, while you are exploring the world, you only control one of the characters, usually from a third-person perspective, and the rest of your party are conspicuously absent.  And then you enter into combat and you are taken to a new scene in which the battle takes place.  I think this is referred to as an “arena.”  What I don’t like about these games is that you are completely taken out of the world during the mode transitions.  And the fact that your party is represented by a single character breaks the immersion.  So here is how Schism is doing it:

In explore mode, you will see the world from a first-person perspective.  However, all of your characters are present in this mode, they are just mostly behind the camera view.  BUT, each character is represented, in real-time, in a window on the screen at all times.  This is sort of like the typical “character portraits” that so many games have, except instead of being a static picture, ours are real-time representations of the characters that are always there in the scene.  So the feeling is, you see the world from the “lead” character while the rest of your party follows behind.  In explore mode, each of the characters can interact with the world.  To select which character you want to interact with something in the world, you select it’s “portrait”, choose the action you want it to perform, usually, you will also select what you want to interact with in the world, and THAT character will step out from behind the camera and you will SEE him as he performs that interaction.  When he is finished, he returns to his place behind the camera.  The idea is to keep the “feeling” that everyone is there in the scene with you while providing a sensible way in which to explore and interact with the world around you.  Then, when combat is triggered, the camera simply pulls back, time stops, and we are now in a tactical, turn-based mode.  And that in itself is a whole other beast.  I will save that discussion for a future post.  But I am aware of the break in immersion that this mode transition creates.  It is a risky design decision, I know, but I’m taking a chance that we can pull it off in such a way that the player forgets to notice, or “feel” (because isn’t feeling what immersion is all about) that we have broken the immersion by stopping time and moving into a turn-based mode.  One of the most important parts of the game is to get that transition to “feel right.”

I like to think we are designing Schism with “influence” from other games that we love, while making it something unique and fresh at the same time.  One of my favorite games of all time was System Shock 2.  I loved the “feel” of it.  It was the first game to really make me understand how we could progress this medium beyond the arcade standards.  I want our explore mode to emulate some of the System Shock 2 “feel.”  Only recently I began playing the old Might & Magic games.  I don’t know how I missed playing them back in the day but I did.  From those games, and others in that same class such as the Wizardry games, I want to inherit some of the “old-school”, challenging, RPG elements.  Some of my favorite gaming memories are of Brandon and I sitting at his Comodore64 all through the night playing the old Bard’s Tale games, anticipating what was around the next corner, how could we get the next great item we needed.  Today’s RPGs have strayed from a lot of that “feel.”  They would rather be action games.  One of my mantra’s right now is, “I’m not making an action game.”  Of course there will be action in Schism, but that is not what I want to DEFINE the game.  Take movies for instance.  There are thousands of action movies.  They are defined as such.  And there are drama’s, like say, A History of Violence, that has some of the most exciting action in any film.  The main difference is, to me, that the action, as exciting as it was in A History of Violence, had MEANING but it did not define the film as an action movie.  That is what I want to create in Schism.

So there you go.  Just some thoughts this morning on where I want to take Schism.  I could go on about this for hours, but there has to be limit; I don’t want to reveal ALL of my secrets.  At least not yet…

Artificial Intelligence

So, this week I took my first steps into the arena of enemy AI.  It is something that Brandon and I have been discussing for quite some time but I finally felt like I was ready to give it a go and at least get started with it.  We are actually going to have several levels of AI in Schism:  The player characters themselves are going to need some AI “pathfinding” built into our turn-based combat system.  The way our combat system works, you can spend “Action Points” to move the player characters into more tactically advantageous positions.  The reason for the AI pathfinding is so that, in the process of the player character moving from it’s current location to the location designated by the player, it will need to have some logic to determine how to maneuver around obstacles along that path.  This won’t be too complicated.  With the Unity Pro version, which we do not have because we don’t have the $3000 it would take to get each of us a Pro license, this is pretty simple because the Pro version has a built in “NavMesh” system.  But I think we can eventually create our own simple system to do this.

The second form of AI we need is for the enemy logic while outside of combat.  We want the enemies to “roam” around the world to a certain extent and behave in a somewhat realistic fashion.

The first steps I took into this foray were into the final type of AI we are going to use: the enemy AI while engaged in our turn-based combat.  I believe this is a system that is going to evolve several degrees before we consider it complete, but I have the first iteration in place for now anyway (at least the basic functions of it.)  This iteration is really just a “Finite State Machine” that lets us, upon an enemy’s turn in combat, put the enemy into a certain “state” based upon a series of logic rules we set up for it.  For example, we have states that allow the Enemy to hit a player character if that player character is within the enemy’s “melee” range, states that allow the enemy to attack from range if there are no player characters in “melee” range, move to cover if it is available, retreat when it’s hit points are low, use abilities or items when available, etc. during its turn.  The system is not that complicated, yet.  Like I said, this is just the first iteration.  I always end up re-writing a script several times from scratch before I am truly satisfied with it.

Anyway, I tried something a little bit different while writing this code.  I actually formulated a plan first.  Yup.  I even created a flowchart!  I usually just write and test on the fly as I go.  I get the idea in my head and just try to code it out.  I’ve got to tell you, there were several things about doing it this new way that were really hard for me.  First of all, the way I was constructing it, it really wasn’t feasible to test it until the entire code was written out, or at least “skeletoned” out.  So I was VERY surprised when I finished the code, hit the play button, and it just WORKED.  It was a great feeling.  (Although, on a side note, once I added multiple enemies to the equation, it SEEMED to fall apart and I spend most of last night and all of this morning trying to figure out where in the code I had gone wrong.  It was frustrating because everything SHOULD HAVE worked fine.  It made me feel like maybe I didn’t know as much as I thought I did about this stuff.  It turned out to be a completely unrelated issue and everything WAS working exactly as it was supposed to, it just didn’t seem like it.)

I think my next rewrite will be a more delegate driven system like this:  Maybe.

State of Schism

Well, I haven’t written a post in several days so this is sort of a catch up post.

First of all, I went ahead and got our domain name and some web hosting from GoDaddy so hopefully, we will have a new site up soon.  The address, of course, is

Secondly, I’ve been tinkering around with a company logo.  Nothing too intricate, just messing with some text with cool fonts in Gimp.  So far I think I like this one best:


…but I haven’t decided just yet.

Also, I pretty much scrapped the project and rebuilt it from scratch.  (I say that, but really, I didn’t scrap the code itself, just the project setup in Unity3d.  This allowed me to tidy everything up and clean out some bugs.  That has been going well.

Last night I started working on a new feature for the Skill GUI interface.  I fought with it long into the night but couldn’t get it working.  But, as usual, I found the solution in my sleep and got it running first thing this morning.  Sometimes I think I write my best code while sleeping.

And finally, today I also added a small feature to the mini-map system that allows you to drag the view around with the mouse and then use a right-click to reset it back onto your party if you want.  The mini-map was already zooming in and out just fine, although I think I will make a change that lets you zoom with the mouse wheel instead of clicking buttons.

Oh, one more thing!  I might be participating in my first Game Jam.   I’ve wormed my way onto Chris Morris’ team for the F–k This Jam next week.

So that about catches things up.  Thanks for reading!

Narrative and Dialog

So, we have been researching game narrative and dialog for a little while.  Yesterday I was bouncing ideas off Brandon about some ways to procedurally create dialog options based a number of rules.  The initial idea was that, when presented with dialog from an NPC, the player would select a response based upon the six player characters.  Thus, each character would offer his or her response and the player would choose which character’s response would be used in the dialog.  These responses were to be based upon the characters’ personalities.  Character personality has been one of my core concepts from the beginning and I think the narrative system is the perfect way to represent that feature.

Our only hurdle was developing a narrative/dialog engine to power this concept.  We weren’t sure if we wanted to try to write the engine ourselves or use one of the many great pre-made extensions available on the Unity Asset Store.  I even connected with a new game developer friend, Thomas Skuse from who is developing his own dialog extension for Unity who offered to let us use his system in exchange for proving user feedback back to him.

However, last night as I was desperately trying to fall asleep, I had an epiphany!  What if we didn’t let the player choose the dialog options at all?  What if the engine itself not only procedurally generated the dialog responses for each character but also chose which response to give, based on a set of rules and procedures?  Thus, the narrative would play out as procedural cut scenes.

The narrative is still influenced by the player, however.  Every decision and choice that the player makes, from the character creation process and beyond, will be a determining factor in all of the narrative choices, even if he or she does not directly guide the dialog.  The dialog itself should seem organic and natural, instead of “contrived” as most game dialog tends to be.

Add to this, my thoughts, as I was flooding Brandon’s email box this morning, turned to the idea of “mood.”  Thus, in addition to the personalities of the characters (and this applies to NPCs as well) affecting the narrative, we now have another factor to influence the equation.  While character personality is a little more of a fixed state (although it will be possible for personalities to evolve), mood will be more directly controllable.  So I introduces several concepts that the player can manipulate in order to directly influence characters’ moods such as hunger, rest, health, etc.  These things will also be more visible to the player while personality is something that exists behind the curtain.  The player doesn’t simply select the character’s personalities from a list, nor are the personalities clearly defined to the player.  There is nothing that tells the player that character number 4 has a “impulsive and charismatic” personality.  The player has to get to know his characters as the game plays out.  And the narrative and dialog scenes are the perfect opportunity to do so.  So, by taking that out of the hands of the player, he is allowed to learn about his characters and watch them in a new and innovative way.

This is something I am very excited about!  I really hope I have the programming chops to pull it off.  Thankfully, Brandon is a database wiz so he can help me with the complicated queries we are going to need to construct in order to procedurally draw these dialogs out of the vast database of dialog options we are going to have to create for this system.  But, as I reassured him earlier today, it won’t be as bad as it sounds because much of the dialog is re-usable since we aren’t using traditional, hand rolled dialog trees and branches.  Instead, we will be pulling responses out of the database based upon the conditions of our queries.  Then these query results are “weighted” and sometimes even randomly selected.  In addition to the other benefits I have already outlines, this also allows for a substantial amount of re-playability.

Brandon emailed me a little while ago saying “This might actually work!”

My response was, “Of course it will work!  We are Lunatic Fringe Games, not Mindless Sheep Games!”