Prototyping Something New

After the demise of my previous project I've taken some time off from active game development. I've been doing a little soul searching, a little research and as much learning as I can squeeze into an already packed schedule. 

Feeling like I had an idea worth exploring, I've spent the last few weeks working to prototype a new game idea. It's an idea that I've had bouncing around for a few years and is heavily inspired by one of the first online games I ever played. And no. This new game will not have multiplayer - I've learned that lesson (I hope).

With my last project I was nearly a year into it and still didn't have a real working prototype - I had built prototypes of systems but that was it. So this time around I was determined to do things differently. I wanted something that I could prototype in a few weeks, maybe a couple months at most (real life can get in the way). 

Despite looking like a folded protein structure, it's a bunch of star systems with mapped out connections.

Despite looking like a folded protein structure, it's a bunch of star systems with mapped out connections.

So... Where is it at now?

In a about ten days, I was able to code the "procedural" generation of the world. It's not perfect, but it works. And that's all a prototype needs.

A few days later I had the player's navigation working along with some ugly but functional and relevant UI. 

The project was checking lots of boxes and doing so quickly.

The game will be a "space" game. You know planets, stars, laser beams and plenty of spaceships flying around.

So the next chunk I wanted to implement was shipbuilding. I want the player to customize their ship and design it around their desired play style.  A few days later while sticking to primitive shapes (programmer art) I had the basic code functioning. Even spent some time working on visual feedback...

Prototype of the ship building function - the camera auto centers over center of mass.

That was a few hours work that didn't move the prototype forward. Oops.

I'm pretty happy with the results. It's simple and not as smooth and polished as it needs to be, but it works. Again it's everything the prototype needs (and just a few bits more). 

With the ship building complete I had two major features that were going to need work. The game is going to be based on trading and combat (shocking I know). So I needed an inventory and shop system. 

Nothing much to see with the shop system and it's probably the part of the prototype that I'm the least happy with. But! It works. I need to revisit it, to make it "feel" good as it will likely be a central part of many player's experiences. That will come later in the production.

As much as I dreamt of making a "violence free" game with my last project, I can't imagine this game without some lasers, a healthy dose of explosions and maybe a few space pirates. Which means the last piece to build was a combat system.

I know. I know. It's a masterpiece!

I know. I know. It's a masterpiece!

The combat will be very stylized. You're won't be piloting your ship dodging asteroids or incoming missiles. Rather you'll be creating a strategy to counter a single opposing ship. You'll be able to pause the game, think, plan, act and then watch it unfold. And yes, the system is pretty heavily inspired by a  popular rogue-like minus the parts that I didn't like and hopefully with at least a few new ideas. 

Even for a prototype, the beginnings were pretty rough.

Once the code was functional I wanted maybe even needed to make this part of the game "feel" good. If I can't make this feel good, then I may need to re-evaluate the design?

I spent a few hours on the UI, a bit on the visuals and a few more on some basic AI. The results? They aren't horrible.

Clearly, there is more work to be done. 

So is this my new game? 

Maybe it is. Maybe it's not. But I'm getting close to committing.  

When to Shelve a Game Project?

I write this post to help me process as well as to share the journey of the last few months as I have realized I need to put my current project on the shelf and take up a new and simpler project. This is not an easy thing to do. Even as I write this I can hear the doubt whispering in my ear...

Like so many of us, I too had a dream of what my next project could look like. I had learned so much from my first published game and I was excited to start my second project making use of all that experience and knowledge. My coding was better. My design was better. Even my art had improved significantly. 

I was ready and excited to not make the same mistakes that I made on my first project. And so, no surprise, I proceeded to make a whole new set of mistakes...

Not bad, right?

I approached the design of "Game #2" much smarter this time around. Rather than just jump in and work on the next thing that came to mind. I laid out the design in layers with discrete chunks that could be prototyped. With each completed prototype I became more excited and more hopeful. I was making it happen! 

In early 2018 I started to put the prototypes together. I started to build the game world and  began the process of weaving together my creations along with a few third-party tools (that's a whole other post). I was creating art assets and the world was starting to looked "not bad."

And then it happened...

What "it" is exactly I'm not sure. It wasn't a singular event. It was more of a dawning or realization. I think most simply put, it was the realization that this project was simply too big and too complicated. If I look back on the development process this was no surprise. I knew it was ambitious. I had been fooled by the success of each prototype. Each step forward gave me hope. But when all the prototypes came together I could see that what I had was, frankly, a mess. 

The spaghetti code that haunts Fracture the Flag and led to so many bugs had been replaced by chunks of code that individually were reasonably well put together, but when connected made for a not so tasty pasta dish. I could see the writing on the wall and I was headed towards another bug riddled project. 

Added to that was the knowledge that I'd broken a cardinal rule of game development, especially indie development. I had over scoped the game. I knew it from the beginning but had run headfirst into that all too common trap somehow believing it would be different this time. I had a plan. It was going to work.

Fuck.

How'd this happen? 

Pretty simple really. I'm an idiot and I ignored my own advice let alone every blog post, article or book I've ever read about designing a game.

I know better than to design a large game. I have discussions multiple times a month with students (I'm a teacher) about the scope of games and what a single person or a small team can accomplish. I preach simplicity and then I ignored my own advice. 

What a dumb ass.

Beyond dreaming too big, it was super easy to get lulled into a false sense of confidence by the Unity Asset Store. I learned long ago that most of what is published there is not as good as advertised and especially to stay away from assets that will be in the final build (as opposed to editor extensions).

A slick inventory system saved me weeks of work...

I picked up an exceptionally well-designed (truly!) behavior tree asset to be able to program my AI...

Other assets allowed me to quickly sculpt terrain and procedurally add scenery...

To be clear the assets I was using are in fact very good and they did save me time. That is until I needed to tweak them or until my vision didn't match the traditional vision of the asset developer. To stand out as an indie or even have a few people notice a game there needs to be something special about it. It needs to be different. You need to twist the boundaries of a genre or at least employ a new mechanic. So rolling someone else's tool that is based on past games and established mechanics is not be the best plan and frankly I'm not sure it even qualifies as an "okay" plan.

This has nothing to do with the article. Just felt like I needed a picture... maybe the confusion of the chickens is a metaphor?

This all helped to create a fiction that I, a solo hobby developer, could greatly expand the scope of my project. Each of the assets could potentially save hundreds or even thousands of hours, but that masks the hundreds of hours required to use those tools to create content.That's no one's fault except my own.

My stupid, overreaching, dumb ass self. 

Aside from my stupidity, part of the realization that I needed to shelve the game came from my day job's seemly unending ramping up of demands. This is usually my easy time of year, but instead I've found that I'm busier than ever before. The chunks of time where I used to be able to stream my game progress are gone. The easy afternoon where I could find 3-4 hours to code, model assets, or just dream about game design have turned into 15 minutes of down time between meetings. Ugh. 

I'm not planning on quitting my day job to go full time indie developer. Given my current game based income, that it would be a particularly bad idea. However, a career change is needed and it needs to happen sooner rather that later. In the next 12-18 months I will likely be looking for something new. I would love to publish one more game before that shift occurs. Not because I think I'll produce the next Stardew Valley, but because maybe I could sell 10,000 copies and maybe that could justify taking a couple years to build a third game and then a fourth... 

Limitations Lead to Creativity

It's so easy to get carried away with game design. After all you can make anything that you can imagine. You are LITERALLY writing the rules of the world you are creating. With this comes the danger of not having limitations. One good idea leads to another and another. Take a second to breathe and your scope is stupid big.

Don't believe the lies. It's not the first time this has happened... And yes, it happens to everyone.

Screenshot - Fracture the Flag

When I was creating Fracture the Flag I had this vision for dealing with player territory. I was going to split the map in to distinct chunks that the players would fight to control. I spent a few days working on several different solutions, but nothing was working or even getting close to working... That was the genesis of the flag mechainc. Why limit the shape of territory? Why presume to know a good way to break up the map into chunks? My limited skill set forced me to be creative and I came up with a simpler and far better solution. My constraints had led me to a creative solution that became the namesake of the game.

By over scoping my game design I have applied almost no constraints. As a result I haven't really forced myself to think creatively. This has put me on a path where I doomed myself to struggle with weaving all the different systems and mechanics together focusing on  the question "can I do it?" rather than "how should I do it?"

As a solo developer I won't be successful by copying or mimicking other designs. If I have a chance to be successful, it will only be possible if the game is fun and not if it's complex. The two are not mutually exclusive, but complexity has been know to stifle fun on more than a couple occasions.

I think this might be the best and most important reason for needing to set aside the game. The game design has become it's own burden. It's weighing me down. It's slowing me down. It's stopping the creative flow.

Sometimes the band-aid just needs to be ripped off.

If you are sitting there saying that I just need to stick with it, I just need to keep going, or others have done it so you can too! Maybe you're right? But this business is tough. Working hard, having a good idea, and executing the design well are not enough to find success.

If you haven't watched this, then you should. 

Sure, there are examples of indies working for years slaving away and then making it big. But for every success story I bet there are ten, a hundred maybe a thousand stories of indies working for years and hearing crickets when they release their work. Go dig into the new releases on Steam if you don't believe me.

Admitting I've gone the wrong direction and restarting is painful and hard to process but it is a far better option than stubbornly staying on the same path. Even if that means a year's work is going to be shelved. That's better than putting in another 1-2 year's worth of work and having a only a steaming pile shit to show for it. Still, as I write this I have a hard time truly saying "it's done," because there was so much good stuff in the game

The Hardest Question

A GIF of a very early System Prototype

What's next? I love making games. I really do.

I've allowed myself to pause the development of "Game #2" for the last several weeks. I had hoped that I could redesign the game to have something that I could still release. I saw several hurdles in the development process, so if I could design around those then maybe the months of work would still result in a game? While I haven't totally given up on this, the simplified design looks too much like what is already out there. Do we really need another resource management game? It's a popular genre, but isn't it already a bit too crowded? There are systems that I have I built that could probably be reused. If I was more creative I could probably split Game #2 into 3 or 4 smaller games all based on a single mechanic or system. 

During this "pause" I've been playing with a prototype that I've worked with off and on for the last couple of years. It's an idea that I've had and I chip away at from time to time. In a few weeks of (very) part time work, I've managed to cobble together a nearly working prototype. This prototype is just the first layer of the design, but it's taken me more than a year to get that far with "Game #2." From that alone, I know I'm far better off pursuing this new idea.

Hard to take pictures of a game that's about darkness

Hard to take pictures of a game that's about darkness

I also quite liked the results of my Ludum Dare entry. It's not unique, but it was fun to play. It potentially allows for players to create and share levels - always a good thing! (I wrote a script that converts a png file into a playable level.) It was a top down shooter that tried to use light and lighting in new ways. So while the top down shooter genre maybe not be as crowded as the platformer genre I still wouldn't call it an under served genre. 

I feel the danger in wandering through the desert for too long searching for the perfect idea. I can waste just as much time looking for the perfect project as I could trying to keep a bad project moving forwarad. So where to next?

I'm still working on that.

State of the Game - Episode 3

This week I released the third episode of the "State of the Game" devlog. The focus of the past month's work has been to add new art assets and start to build up the world. All with the continued goal of producing a playable Alpha Build.

Check out the latest developments in this months video development log. I show off many new art assets plus new NPC jobs such as farming, mining, logging and a few more.

Got thoughts or comments on the development of the game? Join the conversation on discord. Visit discord.onewheelstudio.com or click the button below.

State of the Game - Episode 2

The current goal is to stitch together the various prototypes into a playable alpha.

This video shows off the new terrain as well as logging, mining, and basic farming. These are the basic economic loops allowing players to generate revenue. NPC behaviors are slowly being built up using Behavior Designer. 

Next up is getting the constrution of buildings up and running as well as the start of basic dialogue with the NPCs. Stay tuned for more.

Want to have input on the development? 

Come join the discord server. It's the best way to make your ideas heard!

The Bump From A "Viral" Post

Getting the word out about a game is tough. Really tough. Try as you might the world is a full of games with "great ideas." The social reach needed for a successful game launch is a huge hurdle for small teams and maybe more so for hobby or solo developers like myself.

Over the last week or so I've posted and shared a GIF and a video of a low poly waterfall. I created the scene to test particle effects for use in my second game. I spent a little extra time making it look nice as I wanted it to be a real prototype - could I actually make a half decent water fall?

Based on the response, the answer is yes, yes I can make a half decent water fall.

The Numbers

I first posted the waterfall on twitter. As of writing this the tweet has been re-tweeted 18 times and been liked 42 times. This seemly earned me 10-20 new followers and maybe a few more over the next several days as the tweet continued to get some attention. Not bad but not viral.

A post on the low poly reddits earned over 500 up votes. One or two people asked questions and I was able to share more info about the game. My website (this site) also saw a bump of about an extra 100 views. Not bad, but still not viral.

Then 10 days or so later I posted on Imgur, a site I mostly use to share images with online friends. I posted the GIF and saw 60-70 up votes before heading to bed. Nothing too exciting. When I woke up the image had over 1000 votes and was featured somewhere on the front page. Imgur classified it as a "most viral" image - at least for a few minutes. 

As I type this post the image has almost 1200 up votes and 290,000 views! Wow. 

So what?

Those votes and views trigger a dopamine rush, but what did they really do for me? How did they move my game forward?

I'll be honest I wasn't prepared. My game's landing page is pretty basic. I was updating a few bits as all the views and up votes were rolling in. I didn't link the game right away, and probably only the last third of the views had access to more info about my game.

Oops. Maybe a big oops!

So the best that I can tell here's my gains from the imgur post:

  • Twitter followers - nothing significant.
  • YouTube - 7 or 8 followers
  • Newsletter - 28 at last count
  • Discord - 8 or 9 
  • Website - 480 visits and 700 page views

These numbers are small... The Newsletter and Discord were the most exciting as both were essentially at zero before. I had "launched" the Discord server just a few days earlier with zero publicity and the newsletter gets almost no push from me.

While this activity felt good it's not the 1k, 10k or 100k people that I might need to launch a game "successfully," whatever that might mean. 

My Take Aways

I'm writing this post as much to share my experience as to organize my thoughts and what I learned in the process. For me this was a break through in the PR department, even if it's small. It helped me understand and get a feel for what success could look like. 

The value of a good image is worth so much. Sharing works in progress have their place, but maybe not with the general public. People say share and share often and don't wait until the game is finished to share your work. I think this is largely true, but I also think there is something to be said for taking a little extra time to polish what you are going to share. Just because you're excited doesn't mean that very many other people will be too.

Where's the balance? I'm not sure, but I have a better feel for it now after this experience.

Motion adds so much. I've read this over and over, but I'm not sure I really understood. I also shared an image of my river at the same time as the waterfall. The river has motion but it's much more subtle - it got almost no response! At this point I question sharing much of anything unless there is some form of motion. All of our social feeds are full of static images - some are amazing, but the images that have motion are so much more engaging.

Somehow I need to reproduce this "viral" post over and over! It's scary to think what it would take to get to the social reach needed for a "successful" game....

 

 

NPC Job System

I needed a picture at the BEGINNING... At least it's a place of work?

My day job is at full speed with my weekends being controlled by bike races (head coach) so development is coming in spurts. It's disappointing to watch the slow crawl of progress, but at least the bike team is placing first in the conference! 

Ok, that's not why you came here... But while your distracted, if you didn't notice I've added a discord channel. It's quiet atm but feel free to stop by if you have questions or comments.

The big focus for the past month or two has been the job system. It is designed to the allow the player to hire NPCs to do basic jobs. These jobs are created from tasks which contain specific actions. These jobs are then "posted" and the NPC uses a simple  value system to determine what job they want to accept. The goal is that these jobs are superimposed on top of the NPC's other needs or desires and that jobs provide money for the NPC to provide for itself. The jobs also intended to speed up the progress of the player - rather spend time to chop wood they can pay an NPC to do it allowing the player to become more efficient and do more. 

The job system has developed in three major chunks. Code backbone. User interface. Creation of actions. 

Code Backbone

The base Actions class

The job system needed a generic framework that could be expanded and extended upon. To do this I broke the design into three main classes; jobs, tasks and actions. 

The job class is the boss of the whole deal. It controls the flow of tasks that the NPC will do and is also the communication link between the rest of the game and the job as a whole.

Task scripts are pretty similar to jobs in that they control the flow of what actions the NPC will do. Having a second container with no real effect made sense in that a task can fail and if the job contains more than one task the NPC would still be able to accomplish something... There is also the option (not fully implemented) that each task can have a time limit. The thought is that a NPC shouldn't spend 3 days looking for kindling if they could also be mining for coal. I'm not 100% sold on the need for tasks, but will likely leave them in for now. 

Actions are where, well, all the action happens. Actions are pretty specific and an individual job or task will likely have several actions. New actions can be added fairly easily due to the base class that is easily extended. Actions will include searching for items, dropping them off for processing or selling them to a vendor and whatever else seems useful.

The three classes largely communicate and interact by checking the status of their "subordinate." That is the job checks and reacts to the status of each task contained in the job and each task checks and reacts to the status of each action contained in the task. When all the actions in a task are complete the task is complete. When all tasks in a job are complete the job is complete and checks to see if it should repeat. Jobs can be done once, daily, continuously or a set number of times. For simplicity the status of jobs, tasks and actions all use the same enum - not started, running, complete, failed or paused. 

User Interface

The ugly current state of the Job Menu

There's a lot going on in the creation and the assignment of a job to an NPC. So the UI is probably the most complex I've made so far in my short dev career. Can I really call it that? I hesitate to even show it as it's so damn ugly, but it's easier to post a picture than describe it all. 

Essentially the left panel is where the job is constructed while the right panel contains posted jobs, saved jobs and inventory items that plug into actions. Not the most refined, but it's working (mostly). 

The job menu has already been through several iterations. With many more to come. I'm trying to hold off on the fancier bits until the full design is complete or at least closer to complete. Each new action makes me rethink the design of the UI or at least the action interface. Once the set of actions are more complete the design of the UI should come together.

Creation of Actions

The first action created was a rather useless one in that it was a random wander. Not something you'd likely want to pay some one to do, but served as a good testing grounds for the system as a whole. 

I would like to keep the number of actions fairly small, but still allow a wide range of jobs for the NPC to complete. Hunting for the system that allows emergent behavior! Currently actions are focused on the collection and delivery of resources. I hacked Inventory Pro to use the item database for the job actions. This greatly simplifies what I have to create and also helps keep a common interface and database.

At the moment I have one UI prefab for all actions and I am simply toggling on/off the needed parts. I'm not sure this is the best solution, but seems to be working fairly well. The toggling is controlled by a series of booleans in the actions themselves - the info in this communicated when the action UI element is created. 

So far the available options are an item, location, range from location, and a number of times to repeat the action. These options are holding up well with the exception of needing to show or indicate the location. At the moment the location is a vector3 which is pretty useless to the player... 

The Results?

The results of this work is a functional prototype of a job system. It's not complete, it's not ready to be added, but it was a proof of concept. The job system is likely to be left out of the first alpha build, but should make it's way in once the first couple rounds of bug fixing and balancing.

What's Next?

The job system was the last major piece of coding that needed to be completed in the prototype phase. So now the working goal is a fully playable alpha build. 

This leaves me focused on the visuals. In particular I begun the process of modeling buildings and working to refine my terrain creation process. I want to include rivers and waterfalls both as eye candy buy also as potential energy sources (hyrdo), but getting a low poly waterfall to look decent is tricky... but more on that in my next post.

I'll leave you with a WIP render of some market stalls.

A WIP render of market stalls - yes I know the lighting isn't awesome

 

 

Resources and Resource Systems

Progress on Game #2 marches slowly towards the goal of have a "releasable" product. Not a Steam ready product, but a product ready to tested by others. So much work to do...

A Chicken taking a stroll around a steam engine

A Chicken taking a stroll around a steam engine

In my first game I made the mistake of implementing "feature X" and then "feature Y" only to have to go back and hack the code for "feature Z" into the code base. I had no idea how to make my code easy to use or easy to extend. Simply adding a new building to a menu took hours...  Oh the mistakes I made! 

In my current project adding a new building to the UI takes approximately 45 seconds. 

With game #2 I am trying to build the systems before adding any significant content.  I don't expect flawless execution of this, but when I find myself writing code that will only work in one situation or copying code and only changing the value of a string I'm trying to step back and generalize or abstract the code. I'm making better use of getters and setters to keep behavior consistent and spaghetti code to a minimum, more of my variables are private and I'm making (some) use of the delightful world of static classes and static methods.

I have a bit of a man crush going with static methods at the moment.

One of my many static functions

One of those static classes is a "Helper Function" class that contains static (naturally) methods for things such as finding the nearest gameObject with a given component (good for snapping functionality), or finding the distance to a player or rounding a vector3. Not methods that every class needs, but methods that are needed frequently and all over the code base. I'm learning to do things better. Slowly. 

Static lists are doing good things too especially when it comes to searching for components in a scene. Several of my more common classes add their instance to a static list when they are initialized (and remove themselves when they are disabled). This allows for the quick searching of a list of components rather than a more time intensive "Find Objects of Type" situation. 

I don't think the extra memory usage a concern, at least not for now. 

All of this is helping to create a more manageable code base.

So what is the result of all this work? 

Energy Mechanics

The focus has been to get the basic resource mechanics working. As mentioned in an earlier post Energy is Everything, so getting the "generation" and delivery of energy working was a major goal.  At the moment energy is broken down into two categories, mechanical and electrical. Steam engines, wind turbines (not yet implemented), maybe solar (these aren't functional yet either) and even hand cranks will generate energy. While generators and motors will convert between the two types of energy. 

The current design vision is that energy sources can be attached directly to objects that need energy or that energy can be converted to electrical energy - at a cost - and transmitted via power lines or some other transmission mechanic.

The energy mechanics are largely functional and the parts that still need work should be easily created by extending the code that already exists. Getting this all working took several iterations and several bouts of refactoring with careful choices on script inheritance. There is, of course, plenty of tweaks and balancing that will need to be done, but the basic framework is in place and working well. Check!

Resource Gathering

I want to keep the resource gathering simple. I also want to make it easy to extend or add new resources. Can you sense a theme? So once again the focus was on building the base mechanics - which certainly needs some tidying and refactoring, but by in large the mechanics are functional and I'm happy with the product at the moment. Inventory Pro has gone a long way in helping structure much of the resource code - both in good ways and bad - the built-in item types and categories provide a natural structure for the resource content.

Currently, I'm focusing on wood/lumber gathering and basic mining. These should provide several resource loops as well as the basic building materials for all (most) structures. Or in other words, hopefully enough content for alpha build. 

Logging

Chopping down a tree with the CAW system

Chopping down a tree with the CAW system

With the logging I started working to get the visuals right before tackling the coding or player side mechanics. Maybe this is backward, but if chopping down a tree didn't feel good it wouldn't matter how great the code was...

So, in Blender I took a basic tree model and added a loop cut to the trunk to allow it to split into two parts. I spent a few hours adding colliders, rigidbodies and tweaking physics settings until I arrived at something that felt decent. A particle based dust cloud finished off the chopping down of a tree and I was ready to implement the chopping mechanic. 

I love physics. Both as a subject and as a game feature/tool. My trees use physics to fall.  So why not use physics to chop the tree down? I added a trigger to my axe and a script to my tree. Hit the tree the right number of times and ... Timber!

I loved it. Until I had to line my character up with the tree. Ugh. 

Trying to get a third person character lined up with a tree and get with in the range of the axe's trigger is doable, but that's not generally how you want to describe a commonly used game mechanic. "Oh yeah, it's 'doable.'" Cutting down a tree is not supposed to be the hard part. Did I mention the obvious fact the that axe is in front of the avatar so the player can't see it without rotating the camera.... Not awesome. So back to the drawing board.

I paused my work with logging and moved on to mining.

I often find when I'm stuck on a problem, big or small, moving on to another task often results in a more creative or at least better solution.

Mining Mechanic

Mining a cube... Can we all say "Place holder?"

Mining a cube... Can we all say "Place holder?"

I started with this Minecraft like vision where players would build an above ground mine and then be "transported" to a mine full of cubes. I wrote some code to generate the mines and place them below the game world. I added walls to limit player movement as well as block out the directional lights from the outside world.

Why not just have a new scene you might ask? I want/need the simulation in the outside world to continue and I also want NPCs to be able to visit a mine. 

It was all looking good, I was feeling good about my mining solution. That is until I placed my player into the mine. Damn walling clipping! I immediately saw the huge flaw in my plan. It didn't take 3 seconds to know this approach wasn't going to work. Totally dead on arrival. The camera was clipping through everything. It looked horrible, especially when the camera was outside of the walls looking at the world above and the vast nothingness below.

Again, a new approach was needed. Something that will feel good and look good.

At times I wonder if I implement ideas from others because I'm lazy or maybe because they realized the issues and designed around it... Hmm. Good artists copy, great artists steal?

Click and Wait

Basic building using the Progress bar

Basic building using the Progress bar

With the tree chopping feeling lousy and the mining mechanic needing to be redone I decided to implement the classic "click and wait" (CAW) mechanic with mining just to see how it felt. And by CAW I mean that a player would walk up to an object, click the mouse and wait for an animation/action to finish. When the animation is finished the resource (or whatever) is ready to be collected. Add a progress bar to this and you've got nice, easy, and hopefully well understood feedback to the player. 

It may be not be very creative. It may be fairly cliche. It may be a lot of things. But most importantly it feels good. The player walks up and clicks. The computer does a quick distance check and the progress bar starts doing it's thing. It's so much easier. Not only that but the previous method didn't really communicate to the player what was happening. Sure the old physics based approach had sound effects and particles when the pick axe hit the chunk of ore, but nothing much happened when you missed... Not good design. The progress bar, as cliche as it may be, teaches the player what to expect and gives near immediate feedback as to whether something is working or not. That's worth an awful lot in my mind.

The CAW mechanic felt so good I immediately added it to the chopping down of trees. While I miss the elegance of the physics based solution, as soon as I had the CAW working it was way more fun. I made a line of trees to just cut them down over and over... for testing purposes! I spent a little time appreciating the sounds, particles, motion and general goodness of how it felt. Hopefully the future players won't even notice - it'll just feel right and never get much attention. 

Best of all with a little clever refactoring, the CAW mechanic can be applied quickly and easily to other game mechanics. 

Freezing Player Input

When I was first coding up the farming scripts I made the decision to freeze input to the player and rotate the avatar towards the point of action. This did a couple things. First it helps the animations look better. It's pretty silly if your character is facing left and dirt is flying on the right... Second it solved the issue of the player interrupting an action part way through. While I like the idea of the player having control, breaking out of an action requires a good deal more code and bookkeeping then simply knowing the action will be complete. 

As the only player tester, I thought it felt pretty natural and normal. I was more engaged with where I was clicking than the direction that my character is facing. Hmm. It would be interesting to get feedback on this. Maybe I'll implement hitting the "escape" key to break out of a CAW loop. So far it doesn't seem like a game where cutting down the wrong tree or planting a carrot in the wrong spot would impact game play much...We'll see.

Progress Bar

My progress bar at the moment is nothing fancy. Just a UGUI slider with the handle turned off. Maybe I'll make a dial or a circle or some thing with a little more style, but for now it works. 

As of now I only foresee one (player) action happening at a time I added static methods (of course) to the script on the progress bar. This allows any script to call the progress bar and update it's value. No need to grab an instance via script or drop in a component in the inspector, simply call ProgressBar.UpdateValue(value) and the progress bar will toggle itself on and display the appropriate value. Have I mentioned how much I love static methods?

What's Next?

Chicken Cam! 

Chicken Cam! 

So what's coming next? I've been avoiding working on the AI side of things. Partially because I'm not 100% set on all the details of the game and also because, well, I know it's going to be hard. After watching "Less is More : Designing Awesome AI" I was encouraged to truly start simple. No need to plan out the entire AI, but rather start with basic functions and features, adding and tweaking until it behaves in a way that adds to the game.

I'm starting with farm animal AI. Why you might ask? I'm starting there as a way to learn and get familiar with Behavior Designer (my chosen AI solution for #2). Surely a behavior tree is over kill for a chicken, but I want or rather I need to start simple. 

 

Resources: Processing, Consumption and Inventory

As a solo developer (of an admittedly over scoped game) relying on outside assets is a key to building a game "quickly" and efficiently. I'm not the type of person to subscribe to the idea that I need to build everything from scratch. I have no desire to build my own game engine, but I do understand why folks often prefer to roll their own solution.

I've become very skeptical of assets that run with the game. I have learned that editor tools are more reliable and don't come with performance downsides that many runtime assets do. I've tried using several assets that are overly bloated or have turned out to have poor performance. My snow shader and graphing tool came out of such experiences. It's a tricky to find the balance between using pre-made tools and rolling your own. There are pro's and con's both ways.

Game #2 will allow players to collect and use items - this will in fact be a key mechanic. This means that I need some kind of inventory solution. I did a little research on how to do the basics, but decided to also look at solutions on the Unity Asset Store. If nothing else the Asset Store can be a good source of ideas. 

As a Unity Plus subscriber I get discounts on a handful of assets. One of those assets is Inventory Pro. So I figured it was worth a look since I was shopping for a inventory solution and the reviews were nearly flawless. 

I watched the tutorials and did as much research as I could. While not "cheap" it's an asset that would take me several days if not weeks to reproduce even in the most basic of forms. Plus it has a level of polish that would take even more work on my part.  So why not give it a shot?

I made the purchase and spent some time playing around. My first impression was positive. It has a nice and easy to use editor. Out of the box it handles person inventory, vendors, looting, banks, a skill bar and two styles of crafting. It comes with a pretty decent default look too (but, I suspect almost any developer will want to modify it). What's not to like about it?

Inventory Pro Editor - Item Editor

Inventory Pro also plays nice with several other popular third party add-ons. This includes Playmaker for those who don't want to dink around in C#. 

It also has custom functions for Behavior Designer which is a major plus in my book as I intend to use Behavior Designer as my AI engine. 

If you are intending on building game with a fairly typical or standard use of inventory then Inventory Pro should be on your short list of assets to check out. However, if your design has some non-standard uses you should keep reading. 

The Other Side of the Coin

As I continued to explore and think more about the custom needs my game was going to have I was becoming discouraged. The code base is all open source, which is greatly appreciated, but it feels like a mess of inherited classes and prefabs. Ugh. The documentation is decent, but doesn't do a great job of describing how to truly customize the tools. The learning curve is moderately steep.

The odd blog post by the developer were very helpful and cut hours out of my work. The needed info is out there, but it can be a little hard to find. 

When trying to setup a scene you can't simply drag and drop UI prefabs in the scene. They don't easily slide into a scene because there are too many connections that need to be made. Too many prefabs that need to be dropped into the inspector or combination of components that are required. It's certainly possible, but it's not easy.  Adding the UI to a scene is best done by copying from a demo scene and then turning off the parts you don't need - a custom editor to add the parts you want and get them all connected correctly would be a major plus and make the product that much more user friendly. 

There is a cost to using someone else's code base... That shouldn't be a real surprise. I got frustrated enough with Inventory Pro that I spent a few hours working to roll my own custom inventory code. It was all going well until I began to write a custom editor to create content. I went running back to Inventory Pro and I'm very glad I did.

Custom Windows

I mentioned a chicken, so why not include a image of my chicken?

For Game #2 I need some custom windows for resource consumers and resource processors. A resource consumer could be something such as a steam engine from my previous post that may take in wood or coal and produce a more usable form of energy.  While resource processors may be something such as a windmill that will process corn into corn meal that can be used to feed your chickens, i.e. turn items into other items.

Each of these custom windows is easy enough to create from a purely UI perspective, but coding them took a bit more especially as I was to digging through someone else's code. 

A resource consumer is very similar to a vendor in that individual objects in a scene will have there own collection that is loaded into a common UI. The main differences being that the resource consumer needs to do something with the items even when the player is not currently using that object, i.e. a steam engine should continue to burn coal and produce energy when the player is busy elsewhere and I don't want to be selling coal to a steam engine...

A snippet of the some of the custom code - All in all there's several hundred lines in the new classes some is copied other bits are mine

Rather than inherit from the vendor classes, which would bring functionality I didn't want, I chose to essentially copy the vendor scripts (ItemCollection and Trigger) and modify the scripts once I had basic functionality working.  The result was a custom trigger script, custom UI window (damned ugly at the moment), a custom collection script that controls what is shown in the UI as well as a base class resource consumer that is designed to be extended for a variety of resource consumer objects (steam engine, chicken feeder, etc). 

I promise it won't be this ugly in a final build

The resource processor is a bit different. At its core resource processing is very similar to crafting. Items go in and products come out - all following a blueprint. Given that Inventory Pro has a built in crafting system it seemed worth the time to fight through the code to create a custom "crafting" window that would meet my design needs. 

The idea here is a that a player (or NPC) drops off some items to be processed and it gets turned into a different item that can later be collected. This means that the UI needs to have an input and a output collection/inventory. It's also required that each individual scene object has it's own input and output collections to that get loaded to the UI when the player interacts with the object. A final two requirements is that the resource processor continues to work when the UI is closed and that the products get assigned to the correct scene object when the processing is done so the product doesn't get lost and the player can collect it later.

A snippet of the Custom Trigger

This last requirement was the biggest hurdles and required about an hour of hunting through code to follow the flow of the information. Inventory Pro has a "craft info" class that contains all the basic information which gets passed through about 8 different methods before an new inventory object is actually created.

I almost lost it at this point. Lots of deep breaths needed. 

To get it all working required an addition to the CraftInfo class to track what object had ordered the product to be created. This allows a finished product to look up where it was supposed to go and assign it to the appropriate collection. 

Custom Inventory Items

Default Item Types - Plus 3 of My own

While I found the process of adding custom windows and functionality challenging and frustrating, adding custom inventory item types was easy and almost fun. Out of the box Inventory Pro comes with several default item types, but anything beyond the typical RPG will likely require custom item types.

Different types have different properties (oh, shocking). These properties are not particularly well documented or at least I haven't found the documentation. Thankfully most are self explanatory. 

Game #2 is not the typical RPG with the collection, crafting or upgrading of gear playing a central role. Rather most inventory will have some use in creating something in the world. This might be a shovel that is used to prepare the ground to plant a crop or coal that will be used by a steam engine to power an industrial building. Inventory Pro's items all inherit from a parent class that calls a Use() function. This function can easily be overridden to perform any actions needed. The Use() function is called when the player uses the object. Which can be done from inside the inventory or from the skill bar.

A sample custom USE() function for a tool item type.

The Use() function returns an integer that indicates whether the object can be used.

In the case shown using the tool will call an outside public function that toggles a mode of the game (i.e. use a shovel and you can dig to plant seeds). 

The inventory item can also have public variables that will be displayed in the Inventory Pro editor. For example the Tool Type enum can be set for each inventory item of this type inside the editor which makes for easy and organized content creation. 

The ease of creating custom inventory items was a stark contrast to making custom windows and triggers. Why can't the rest be this easy?

The Final Verdict - Inventory Pro

Inventory Pro caused me a good amount frustration, plenty of swearing but also gave me a much more functional inventory system than I could have created on my own.

If you are looking to build a game with non-standard use of inventory and aren't comfortable with C# then you should probably look else where or be willing to hire a programmer to code up some custom solutions. 

But if you don't need custom functionality or if you are comfortable with C# and reading someone else's code then Inventory Pro can solve your inventory needs far quicker than you'll be able to roll your own solution. Mucking around with the custom windows wasn't particularly fun, but the end product was worth the time and money.

Energy is Everything

Game #2's design is fairly well established in my head and on paper, but I'm still very much in the stage of exploring what I can reasonably do from a technical perspective - not to mention from a time perspective. (Read as: I'm trimming down the scope by figuring out what I can or can't do.) I'm running through the big picture list of features to make sure that each can be implemented in a way that I like and fits the vision for the game. This is an iterative process. As features are implemented other aspects of the game are getting adjusted or redesigned, but that's not exactly news worthy...

Energy

A core feature/game mechanic of Game #2 is going to be energy. Energy is everything. With more energy we become more productive. With more efficient use of energy we can do more with less. The use of energy is what allows for modern society to function and, to hint at a game mechanic, use of more energy allows for a higher standard of living. 

There's of course a dark side to energy consumption.Increases in efficiency allows more to be produced with less. That might be less workers, less energy or less effort. All of which improve the quality of life. While this can drive down prices, increase production and consumption it also has the effect of higher unemployment or underemployment - i.e. the current stat of the rust belt. 

A rigged and animated steam engine model. This was also the first animation I'd ever rendered in Blender - GIF made with GIMP.

This give and take concept is something I very much want to explore in Game #2. The first step of which means I need to develop an energy mechanic. The mechanic requires the "generation" of energy (the physics teacher in me cringes writing that), the distribution of the energy, and the "consumption" of that energy.

The game is likely to be set in the industrial revolution time period. So... Steam engines!

Steam engines can provide a local source of energy. They can be fed with wood, charcoal or coal - really anything that'll burn. All of which can be found or produced easily with low tech methods. Steam engines can be built on site in a variety of sizes. Seems like a win. So off to Blender I went to see if I could produce something that I liked. 

A view of the rig in Blender.

Nothing profound in the modeling department, but rigging and animating is still pretty new to me. I didn't want to "fudge" the animation I wanted a rig that with the rotation of a single object could animated the entire model.  I wanted this for ease of animation as well as for a degree of realism. 

A combination of bones and constraints to tie the mechanism together and allow smooth animation. The constraints of copying location, rotation and or scale were all new to me and opened my eyes to a new world of possibilities. I'm excited to play with more mechanical animations...

There are very few tutorials on mechanical rigging - I might put one together in the future. Who knows?

I'd like to work renewable or at least pollution free energy sources into the game as well. At first glance windmills are a pretty obvious choice - so those will be added at some time in the future. At the moment I've avoided rivers (as I have no idea how to make a good looking low poly river) so water power is more or less out for the moment.  

Energy Transfer

Power Lines - Mostly eye candy at the moment

Power Lines - Mostly eye candy at the moment

The industrial revolution largely used mechanical energy which (clearly) has limitations. Moving towards electrical power as a way to transfer energy could help in several design areas, but could break the immersion or at least a sense of believably.

While it may not fit with the (current) intended time period I spent a little time playing around with power lines. Being able to generate power in a centralized location could lead to higher efficiency and more contained pollution. This is further specialization would allow workers (and the player) to spend more time doing something besides feeding fuel into a steam engine. 

Borrowed Code that when passed an Array of Points with Return a larger but smoother array of points - Don't Remember the Source, Oops.

I can see the game going away from a historically accurate time period (ha, as if I'm capable of historical accuracy), but I don't want to delve to far in to fantasy or steampunk styles either... 

The power poles are just to cubes scaled to look like modern poles. The lines are line renderers that start with three points and then are smoothed by some (borrowed) code to add additional points. 

The performance of moving the poles is pretty bad and will need some optimization if the code makes it into a build. I have to redraw all the lines when a pole moves - at the moment EVERY line is redrawn.

To be honest the power lines came out of frustration (lack of creativity) with another idea. They may just be a short lived idea that goes away.

Some form of energy transfer mechanic will need to make it into the game whether that is power lines or not I have decided. At the moment the energy transfer mechanic is simply the player or hired workers stoking the fires of steam engines - I think a step up in sophistication would be good.

Plenty more to iterate on...

Graphing Script - It's not exciting, but it needed to be made

A download link to my graphing asset is at the bottom of the post - if you want to try it out.

Game #2 will likely be centered around economics as well as climate (change). Deciding where to build a farm will likely be best done when looking at some climate data. Does it rain enough? Maybe too much? How hot does it get? Is the ground water polluted? Or looking at historical prices of commodities may help a player decide what type of business to pursue or how much they can afford to pay NPC employees. I don't want the game to be a data crunch fest, but data will be a part of the game. So naturally I'll be needing a way to visualize that data and graphs seem like a good way to do that. Pretty sure players don't want to read a list of float values.

Visualization - Basic line (scatter) graph

Graph Maker

I'd seen Graph Maker on the Unity Asset store and bookmarked it many months back. The reviews are pretty decent and it is definitely capable of a lot of heavy lifting. I'm aware of at least one reasonably successful game that has made use of it. So it seemed worth the risk of a few bucks. Graph maker clearly has had hundreds of hours poured into it. It's polished and feature rich.

All those features have also caused it to be fairly complicated. Each graph has several nested prefab elements each with scripts attached. The documentation is also a bit rough. As a new user the number one thing I want to know how to do is send the graph a list or array of my data and have it graph it.That's it. One simple function. So where is it?

I spent a while clicking around trying to figure out where the data was stored (turns out to be in the series prefab/script). I opened the documentation and couldn't find clear directions of how to send my data to the graph via script. I opened the scripts in search of the list or function that would import my data... Couldn't find what I was looking for.

There is a neat reflection script that can be attached to gameObjects and looks like it could do some handy stuff, but I couldn't get it to do what I wanted. All in all the asset looked way bigger than what I needed. Do I need radial graphs? I don't think so... 

The second thing I want to do is modify the appearance of the graph. The shear number of (nested) prefabs not to mention the number of settings in the main script it seemed like it was going to be a long battle to customize the looks of a graph.

So as I so often do, when I can't figure out an asset I start down the path of rolling my own asset. If you have more patience than I do, I know that Graph Maker is a good asset and will make pretty graphs for you. 

Rolling My Own

The goal of rolling my own graphing asset was to make something simple, lightweight and easy to use. As of writing this post my graphing asset has 6 prefabs and three scripts (one of which is a custom inspector to allow graph updates in edit mode - another detects mouse hovering). The prefabs largely consist of gameObjects with just an image component. A few such as "tick marks" or "axis labels" have children with Text components, but nothing gets more complex than that. Sending data to the graph is done with 1 of 3 functions. Pretty simple. 

Just send the data and let the graph do the rest.

In the end it's taken me way longer to roll my own graphing script then it would have taken to figure out Graph Maker. Is mine as pretty? No. Does mine do nice tweening animations? No. But I know how mine works and I know how to modify mine if I need to.

The feature list is short. It can switch between line (scatter) and bar graphs. The axes, points, connecting lines, and tick marks can all be tweaked in size and color. 

Bar graph of the same data as at the top of the post

Fonts, font size and font colors are all of course adjustable as well. Modification of the images was left out of the inspector/script and can be done with the prefabs. This was done for simplicity and the simple fact that changing images is less of a "tweak" than font size might be. 

I still have one feature to figure out and that's auto-scaling. Currently the axes will auto scale and adjust to fit the data, but the values displayed on the axes does not. I'd like to figure out some basic auto scaling to keep things simple - sure I can manually adjust the values in the inspector (or by script if I expose the variables or add a new function), but that's hard to do when the game is published... I like to be involved the community, but manually adjusting each player's graphs is a bit much. I'll keep the linked package up to date if anyone has ideas of how to auto scale I'd love to hear them.

Edit: The auto scaling is now working. 

Download (Free)

I may polish the asset a bit more and put it on the Unity Asset store, but that's a lot of work for not much of a return. Until then I'll happily handout a free download (box via goo.gl). Feel free to use it or modify it. Just don't flip it and sell it - don't steal my $12 in potential sales! If you do use it I'd love to hear about bugs or ways to improve it (but not bloat it). 

Not until writing this post did I realize I named my asset the same as the one I'd purchased. Oops.

Tutorials: Low Poly Snow Shader

My last post was about adding snow visualizations into Game #2. In the end I came up with a custom shader that ran faster than an asset I found on the Unity Asset Store. In my (quick) research I didn't find a tutorial showing what I needed, so I thought I'd do a quick series and show my project. The tutorial series covers the full creation of the shader (in Shader Forge) as well as a simple script to control the snow effect scene wide. 

If you want to see more details about the creation of the shader or if you'd like to try it out (download link in the video description) then check out my tutorials series. The first video is just an intro and explanation of what's to come. If you want to get to the meat then click here to skip to Video #1.

Intro video showing what will be created in the rest of the tutorial. Shader Forge: https://www.assetstore.unity3d.com/#!/content/14147?aid=1100lHSw Tutorial Assets: https://app.box.com/s/npupei7px4tjavkkg4gtbz3y3mj6b73b