Pell-Mel Ideas

Faiths of Gyrdûn

The Twilight Paths

The Path of Dawn
The Path of Dusk
Faith of the Aternai

-mountain peaks important in/symbolizing ascension


Style Guide

Art Style

We strive to create environments with an aim toward realism, insofar as possible. The following example scenes shall serve as a point of reference to help establish a consistent style and mood for the content we create. If you can imagine it existing in any of the scenes below, then you're on the right track!

image-20200510105412-1.png image-20200510105553-2.png image-20200510105656-3.png

image-20200510111021-4.png image-20200510111411-6.png image-20200510111520-7.png


The game will initially focus on 4 biomes in the following categories:

  • Grasslands
  • Forest
  • Mountain
  • Volcano

Time Period

While the game is set in a fantasy world, we intend to draw from various middle periods of human history for guidance on topics like architecture, weaponry, and clothing. The use of colors, type (fonts), imagery (UI) and music should be used in a way that helps reinforce that mood.

Development Model (Workflow)

This guide explains the branch-based workflow we use to support our team-based collaboration at Project Thorne.

At its core, the development model relies on two parallel branches with an infinite lifetime: development and main. All feature coding takes place on the development branch. Once features are fully tested and ready for deployment, they are merged back into the main branch and tagged with a release number using a standard major.minor.patch versioning scheme.

Create a Branch


When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.

When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect code in other branches (like the master branch), so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready, typically after being reviewed by someone you're collaborating with.

The first step, therefore, to begin developing your own code is to create a branch off development and check it out. This can be done in a single command as follows (or by using a GUI client like TortoiseGIT):

git checkout -b branch-name development

As the name implies, creating a branch simply creates the branch in the git repository. To actually switch to it and begin working on that branch will require you to check it out. The git checkout command allows you to create the branch and check it out in one go.

Branching is a core concept in Git, and the entire workflow is based upon it. All feature branches must be created off the development branch. Anything in the master branch must always be deployable.

Add & Commit Code


Once your branch has been created, it's time to start making changes. Whenever you create or modify a file, it must first be staged locally before it can be committed to the repository and tracked. This can be done very simply with the following command:

git add filename(s)

You can also add multiple files at once by just typing in all the filenames in a single space delimited list. Once a file(s) has been staged in this way, it can be committed to the current working branch and eventually merged into the development branch and pushed up into the central repository where other collaborators can access it. So, whenever you've written code that compiles and runs successfully, it's time to commit it to the current working branch. This process of adding commits keeps track of your progress as you work on a feature branch.

Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction. To commit all the files you've staged (or "added"), simply perform the following command:

git commit -m "message"

Merge & Push Changes


Once you've committed your code, tested it and are ready to share it with the team, it's time to merge it into the development branch and update the central repository.

To merge code, you must first switch to ("checkout") the target branch and then merge your code into it from the source branch. At this stage, your target branch is development and your source branch is the feature branch you created.

Once you merge a feature branch, you should also delete it to avoid cluttering your local repository or checking them out accidentally. You can achieve this with the following sequence of commands:

git checkout development
git merge --no-ff branch-name

git branch -d branch name
git push -u origin development

Discuss & Review Changes


Once your code is merged into development, it's a good idea to make other collaborators aware of it, to review it and ultimately to pull that code into their local git repositories.

New code pushed into the central repository can quickly be pulled using the following command:

git pull

Deploy to Production Test


Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production.

If your branch causes issues, you can roll it back by deploying the existing master into production.



Now that your changes have been verified in production, it is time to merge your code into the master branch and issue a release. This can be achieved by first creating a release branch and merging the code currently on development into it then pushing it up into the central repository for permanent reference:

git checkout -b release-x.y.z development
git push -u origin release-x.y.z

We push release branches up into the central repository for two main reasons: a) so we can always view source code (and related commit histories/messages) associated with a release, and b) so we can very easily rollback to a prior release in the event a deployment breaks something unexpectedly.

Our versioning convention uses a release- prefix followed by major.minor.patch revision numbering. Major revision numbers only change when backward compatibility with existing deployments cannot be maintained for an upcoming release. Minor revision numbers change when backward compatibility is preserved, as is typically the case with the simple addition of new features. And patch revision numbers change when bug fixes are issued.

Now finally, it's time to merge the code in the release into the master branch, tag it with a release number and then push it up into the central repository as well. This can be achieved with the following commands:

git checkout master
git merge --no-ff release-x.y.z
git tag -a x.y.z
git push -u origin master

And that's it. Pop the champagne and make a toast. emoticon_smile



Official Wiki Launched

We're excited to announce that we've finally launched the official wiki for Project Thorne!

This is where information about our development studio and work on our projects can be found going forward. Over the coming days and weeks, we'll begin adding new content here and hopefully organizing it all in a way you find easy to navigate and consume. If you have any interesting ideas, suggestions for improvement or any feedback at all that you'd like to share with us, please feel free to leave a note in the comments area.

If you've been following our developments, thank you for your interest and stay tuned for news and other interesting tidbits about our progress!


Created by Sintax on 2005/01/28 09:50
Copyright © 2020 Project Thorne