Where we started.
Had you told me a year ago what I would be up to now, I wouldn't have been able to visualise it. Back then, myself (Joshua Ellis), my business partner Joshua Matthews and a third person, who I won't name, were in our second year of university and trying to join the Enterprise placement scheme, funded and organised by Sheffield Hallam University. This would have allowed us to attempt to follow our ambitions for a year and build a business in our chosen field of games development.
We initially had the intention of making a few small games for mobile using the Unity game engine. With the loss of our third team member, however, our plans rapidly changed into what they are today, as the uncertainty and smaller team forced us to focus on one project based on the types of games we were really passionate about.
We are both creative, ambitious, and love customisable games such as Minecraft and Garry's mod, and so decided we had to reflect that in our work to get the most out of the year. We also realised that while a steady income would be great, it's really about the quality and passion of what we make at the end of the day that drives us.
We started off with the vision of a game that was a top-down survival RPG at heart, customisable from head to toe, and had close integration with the Steam community marketplace. This, of course, has meant a focus on PC rather than mobile, which was another big change for us. Due to a lot of experience (and failure) with ambitious overarching goals like this before, I knew, as did Matthews that we would have to dial it down and hone it somehow without destroying what we wanted to create. We are a two-man team after all, and one new to the indie development scene at that.
Initially, we whittled down our scope to include only what made the project idea unique in the first place and have been slowly refining this throughout the development process. We had a rocky start getting used to being independent, new to the field of business, and we were forced to use new development tools and processes. It was a steep learning curve, with the switch over to Unreal 4 from Unity due to performance concerns being a major time investment. It is why the first leg of our project took so long, but it gave us time to develop the company into what it is now.
After the Christmas holidays, refreshed, wiser and eager to get over the slump we had experienced in our first two quarters, we knew we had to do something differently. We had just found our feet working independently, but had to raise our business up to the standards that we wanted it to be. We began by overhauling our social media efforts so that we could begin to build a following around the idea of a transparent games development process. We are really proud of what we did here, and so turned our focus towards our product.
The IsoEngine/Reign project has been slowly growing, but not at the rate that we needed due to our inexperience with independent project and time management. Initially, we set a meeting with our assigned mentor, who's speciality happened to be project management, and they really set us in the right direction with what we needed to prioritise and what processes to follow in managing our needs.
With our priorities straight we spent the lead-up to our six-month review (held internally within the enterprise team) breaking down our project as much as possible and really tried to solidify our aims. This was so not only so that we could build a roadmap, but also so that we could show our plans and commitment to the outside world. We had the opportunity to compete for funding with other teams in the space, and while we didn't win, it was great motivation to develop our credibility and professionalism.
An overview of our roadmap.
I am really happy to say that based on our recent efforts the project roadmap for our project is finally complete! A roadmap is simply a plan on how and when we intend to spend our time, which for us is flexible so that we may adapt to our situation and demand for the project itself. It covers literally everything we can think of that contributes to the success or failure of the project's development, its commercial release and our business. I hope that this demonstrates a clear commitment to the future of what we are doing, and clears up any questions about where we are going next.
To help me take you through our companies future, I'll give you a quick primer on our roadmap so you can use it as a reference and then I'll detail our companies complete planned future for the next six months. For a quick overview, here is an image of our internal roadmap and what I'll be covering:
A common technique in agile software development (a form of project management style) is to break up your work for your roadmaps in three stages. The topmost level is an Epic, which in our understanding is a clearly identifiable work category. This is what you see on our Jira roadmap on the left-hand side. This is great at helping you identify focus areas at a glance, and keeps us narrowed in when deciding what type of direction to take the work we do.
Taking epics, we need to break them down into what are traditionally called User Stories. We refer to them by tasks or features, as it makes more sense to us and more closely matches the image we want to convey to our community. These are identifiable business goals or things we want to deliver to the end-user. To manage the completion of our tasks we often break them up further into subtasks, which can be helpful if something is particularly challenging or involves multiple people.
Dependencies and timeframes.
When deciding how to prioritise our Epics, the biggest challenge was deciding what to start on first. A really helpful way to figure this out is to work backwards and assign your tasks and epics what is called a dependency link (if it needs one). As the name suggests, this is a relationship between Epics or tasks that specifies if one must be completed before the other. For us, we were able to build chains of Epics ending with our eventual product release target. You can see these links as small squiggles connecting our time estimates (the purple blocks shown under the top row of dates).
Since not everything has dependencies, it also reveals what can be worked on in parallel (if you have the resources and decide to do so). We have two team members currently, and have managed to set out a systems-oriented development chain and a design-oriented chain that myself and Matthews can work on respectively. This helps us work without getting held up by each other's deadlines, and reduces downtime. We also have our business Epics, which are decoupled from both chains and generally worked on constantly alongside development.
Estimating how long things should take is always a struggle, and in some ways is a perpetual back and forth as you move through your roadmap. What we have set up currently is a very loose estimate based on ideal completion times, and that doesn't even factor in individual task timeframes. We are very flexible with our milestones, and so for us, we don't need to be too concerned with getting our estimates particularly close, and just use them as a way to line up our workflows, and prepare for certain real-world dates.
The static editor experience.
Now that I've provided some context, I want to take you on a journey through our envisioned future, covering each of the sections on our roadmap as we go along. The most foundational aspect of our work is the editor that drives the engine we are making, and so I'll be covering this first. It should give you a clear outline of what we hope the toolset will be capable of, and later I'll explain what content we'll be developing with it. I (Joshua Ellis) personally manage the technical track of our roadmap, whereas Joshua Matthews manages the design track.
Our voxel and prop technology is something that we have largely already developed tools and test content for, which has laid the foundations for our complete scene editor experience. So far the static design portion of both systems is complete, but soon we are expanding it's editing capabilities to include changing prop and voxel states for gameplay purposes. This will include the groundwork for features such as inventory systems, animations, health, and other relevant statistics that effect AI and static objects. Here is an image of the kinds of things you can do with what we have developed so far, but bear in mind the lack of actual content (I'll cover that later):
The next task for me is to combine aspects of both props and voxels into the prefabs tool-set. This will allow you to save collections of voxels and props for future use, which will be especially useful for things like buildings, dungeons or re-usable setpieces. We plan to have these cross-scene compatible, so rest assured you can take your creations wherever you go!
Once work on this is mostly complete, Matthews will be designing and building a unified UI that will tie together the visuals for voxels, props and prefabs into one nice interface. This editor UI will complete the design experience that we want to deliver in the base game and will be a major milestone in the project's history. It will be at this stage that we first want to demo the project to various testers in person. This will be part of our networking Epic, and I know that we will get valuable feedback from what will be our first real playable demo.
Our dynamic games experience.
With the ability to set up your static scenes in whatever manner you wish, you'll more than likely want them to do something, and ultimately be able to mess around in what you've built. This is where our dynamic game systems come into play. The most crucial one to our environments is the inclusion of flexible artificial intelligence that can bring to life entire ecosystems. To lay the groundwork for testing this, however, I will be developing functionality for a couple of important game features.
First and foremost, our menus will be crucial in developing a cohesive polished experience, allowing you to switch between static and dynamic game-modes, configure settings and eventually (we hope) be a one-stop location for information about the company and the game. This will lead to the second essential component for getting AI to work, which is a play mode for objects. Put simply a play mode is only really a controller for managing what parts of the game are running and which aren't, so we can disable/enable certain features when switching between our editor and in-game experiences.
With this foundation laid, I can start giving the AI some autonomy. The core goal is to have them be able to perform simple navigation and problem-solving in a dynamic environment, with the aim being to survive. Some may be at odds with one another or have complex needs, so we hope we can get some really interesting interactions going on between AI types (a lot of which we won't restrict or even be able to anticipate).
Additionally, we also want AI to reproduce, age and create shelter, creating a nice gameplay loop involving the ecosystem itself. All in all, it sounds like an incredibly complex undertaking, but I have a few simple systems in mind that should (all being well) go a long way to making these goals a reality. Failing this, we'll just cut back on some of these additional features, and look at re-delivering them at a later date. It won't slow us down too much if we decide some things aren't feasible given our time-frames, and as with everything we want to remain flexible.
As AI will be laying out so many of the features regarding interactivity and actions within the play-space, this will enable the rapid creation of the player controller. This is the point at which you'll actually be able to "play" the scenarios that you build. We'll give you access to as many of the actions AI can perform as possible (so long as they make sense for humans), and we'll be designing a nice UI to accompany that. We haven't nailed the design of combat down yet as there are a lot of unknowns in regards to AI, but rest assured we'll take the time to get it right.
A lot of smaller improvements and features will be built throughout the creations of these systems as part of our global features Epic, covering all areas of the game's functionality. With the player controller done, we will be exactly where we want to be for showing off the broader game itself, and not just the design toolset. As with before, we'll network and gather feedback as much as possible to design a great user experience. That about wraps up our game systems, and hopefully, it's clear how they'll eventually come together.
Our scenario content (the Reign of Rains package).
With our gameplay systems clearly laid out, I now want to get to the meat of what's important to most players. Our goal has always been to make a game, not just an editor, so we're building a set of experiences that we're calling Reign of Rains. Primarily, it will feature a medieval period survival experience that will act as a playground for whatever you can think of. Much like Minecraft, you'll be free to destroy, build, create, interact and share whatever you want within our worlds.
I'll go through the types of content you'll be able to use in our editor in a similar order as laid out by what systems I've already discussed, beginning with voxel materials. Voxels, our primary building tools, are of course for the development of environments, which needs to reflect the diverse nature of not only natural materials but also man-made ones. We want to be able to produce not just simple things like hillsides, but also buildings, all the way up to complex structures like castles.
Materials won't necessarily just be just a change of skin, with some potentially having unique surface shapes, normal maps, reflective properties and even transparency. We can even change the appearance depending on the voxel shape type it's applied to. Stone, for instance, could be represented by a simple cube, or a staircase if used on a slope. So long as seams line up between primitive shape types, anything is possible. This diversity should allow us a great deal more flexibility than traditional voxel engines but can be optimised and customised in similar ways. This is something we're really excited to build content for, and know that it will go a long way to making visually stunning environments.
To assist with the creation of said environments, Matthews will be making a large library of static props, which with the help of our interaction system, will be capable of building fully diverse and interactive worlds for you to play with. Everything from trees to brick walls to tool-benches will be possible for us to add into the game to bring it to life. We're also extending this work to animated and physics-based props, such as AI, for which we're planning on making a wide range of creatures, including many human sub-types. This is so that we can test our AI system with as many unique scenarios as possible, and eventually deliver the widest range of tools to you guys to have fun with.
Getting the AI to function as we envision will be difficult, but balancing their designed lifecycles will also be a challenge. For example, let's say we've accidentally created a species of fox that is really good at hunting rabbits (the smallest animal in this hypothetical food chain). If it wipes them out, the fox's food source will be depleted and cause the eventual death of other species in the ecosystem, including the fox. We'll be building feedback loops into our game systems that should help avoid such scenarios, but if the player finds a way to do things like this of their own accord, we won't outright stop them, for better or worse. Limiting gameplay opportunities is not what we want to do, and figuring out the complex rules of your designed (or chosen) play-space is part of the fun of what we're building.
As Matthews is building this designer content, he will, of course, be designing our Reign of Rains experiences. Both Reign of Rains and our content design will inform the development of the other, leading to the natural growth of a cohesive visual and thematic experience. We aren't one-hundred percent sure what direction this will take yet, but we know we want to develop a carefully curated experience, that will take you through a variety of environments, giving you the opportunity to make the sandbox your own. This is our chance to show off everything we're building and is currently our guiding star, which will mark the culmination and completion of all our current roadmap plans.
Our business Epics.
We appreciate that the scope and needs of the project may change over the course of this year, and maybe even well into the future, so we are taking steps to embrace that. We are combining the strengths of our social media output and new-found project management skills to do what we have always wanted to, and involve the community in the creation of our games. As soon as we have the resources and fan-base to do so, we'll be opening up the opportunity for feature suggestions and voting rounds to decide what we work on in given weeks. This is really important to us, as has been livestreaming the game's development, so that we can really open up the development process and have a close connection with our audience.
To secure a small following from which we can grow, as I have discussed, been really on top of content creation since Christmas. We have also been planning to go to a major gaming event to get to see fellow developers and fans in person. For this, we recently secured a massive £1000 from our incubation space, which will cover everything from event costs to company branding, and we intend to make full use of it. We're really grateful for the opportunity and have been excited about attending an event for some time.
Unfortunately, just as we've received funding, our original plans to go to the April Insomnia Games Festival have had to be cancelled this week due to the coronavirus pandemic, and the UK government issuing warnings and restrictions on such events. We are taking this in our stride, however, and rather than try to demo a smaller version of what we are building, we're going to take more time to flesh out our product and have a more complete demo to show at the event in August instead. We actually think this could be better for us overall, and definitely gives us more time to prepare for our now also delayed Kickstarter campaign.
One thing we are investigating to deal with the monumental task we have set ourselves and to help develop a better product is to bring on board an additional team-member. We're really hoping to find someone who can help us deal with the increased workload of managing a community. A stand-alone website is something we are also considering, as a central location for all of our content, bringing people together to one place. We would only build upon this if we could secure this additional team-member so that we didn't take time away from what's important. Reign of Rains. As always our efforts are all focussed on this one product, and I know we'll have more to show as the year progresses.
Fin.
So thanks for reading! I know this week's blog has been massive compared to the others (which is why it took me two weeks to do instead of the one), so I appreciate it if you've taken the time to get to the end. I just want to say a special thank you to people who have interacted with me on Twitch in the last month, who actually inspired me to write this summary. I've had a lot of people come through and ask about what the project is that I'm working on, and that interest is genuinely inspiring. As always, if people have any further questions, get in touch through our various platforms and we'll be sure to get back to you. Thanks again everyone, and have a great week! See you next time :)