Developer Blog #2 - Data Storage and Dynamic Art

Before we start to write about this next developer blog, I'd like to give a shout out to all our early supporters for last weeks developer videos. There's a few things I want to address this week before we delve right in.

Firstly, we started an instagram and it's been going really well. If you want to catch up on our progress daily and see pictures, gameplay and snapshots definitely head over and follow it.

We also have a twitter, facebook and patreon account. Any support on these platforms is greatly appreciated. A share, like, comment or a $1 a month can go a long way to helping FTC get out into the public eye.

Secondly we're starting to grow a small community over on our discord server. This is also a chance for developers, fans or anyone to have a chat with us directly. We're all about open communication and transparency and we'd love to hear from you guys. Click on our invite link below and connect with us instantly!

Data Storage using Unity
Jordan - Lead Programmer

This week, I've been working on ways to store large amounts of text and data.

I have been primarily focusing on having the player navigating around the planetary system and triggering events. FTC will feature hundreds of different unique and exciting events, and we needed a way to store this data and trigger it. Typing out and creating hundreds of different functions in one script isn't going to cut it.
Here are a few options to get you started:
  • XML
  • SQLite
  • Scriptable Objects
  • JSON
Over the course of the game we will probably need to use one or two of these options and I'll explain why in a bit. For our events system we're working with scriptable objects that interact with XML. A scriptable object is like the cousin of monobehaviour in Unity. It acts as a piece of data that derives from the unity engine but does not work in the same as monobehaviour either. You cannot place it on a gameobject. When you create a scriptable object it then creates asset files. Each asset file contains unique data. For example, each asset file we created contains an ID number, Image, Description, Choices and Outcomes. We can store all these asset files into a list and pull and read data from them when we trigger events in our game. The downside to a scriptable object is that they cannot be modified at run time unlike other options such as XML, SQLite which you can read and write from at any time. 

Hopefully this gives you a bit of insight to scriptable objects. The main reason I've chosen to use scriptable objects is that I'm most familiar with Unity's scripting API and XML/SQLite might take time to learn when we're pushing for a workable alpha as fast as we can.

If you want to learn more about Scriptable Objects check out some of these links:

2D Art in a 3D Space
Richard - Lead Designer

As games have become more technologically advanced, they have relied less on engaging art, because a similar effect could be achieved using 3D models and environments.

I think this trend is sad. Art evokes so much more emotion than any 3D environment in my opinion. It will always have a special place in narrative story telling. I feel many triple A games today are really substandard in their aesthetics these days. It's like developers have been blinded by technology and are trying to present this technology as an aesthetic style, when in reality its just the same recycled 3D models. 

That being said, I do think art can be integrated into technology to create new and exciting effects. Just look at Hearthstone and Gwent. People are drawn to art, but taking that art and adding effects makes it even more special. A great deal of development effort goes into games like Hearthstone. People may not realise it, but just because it's a virtual card game, doesn't mean it's not difficult to develop.

In FTC each random story event, mission and linear story event will have its own unique art work. This acts as both a marker and for aesthetic purposes. People can see the artwork and be like 'Ah, this one.' 

Another thing we have added is dynamic images. What this means is that we have a 2D image with a transparent background. What happens in game is the image is shown and the background is taken from the system the player is in. Because our systems are procedurally generated, the backgrounds are always different, in in this way the 2D image will be a little dynamic and change according to where the player is. 

This effect doesn't end with random story events. We hope to bring this effect to a variety of areas including character customisation and portrait randomisation. This allows the player to create a dynamic 2D portrait out of many parts. 

FTC is all about customisation and we want to keep the player engaged at all times through customisation. The next build, the next story, the next portrait. It's a big design challenge, but I think it will make the game really special and unique.

Below is the same story portrait, but taken in two different systems. 

Thank you for your continued support. Stay tuned for our next video and developer blog.


Popular Posts