Tale of Omni

A hypermediated platforming adventure as never imagined by neither the Artist, the Architect, the Bard nor the Oracle. Follow this blog to get a look into our progress, and learn about the thoughts going into this project.

[taleofomni]

Layer upon Layer to Make a World for the Player

Hello all,

I know it has been a while, but now I, the Architect, am back with another blog post. And in today's blog post I will touch upon some of the recent changes, I have made to the game, to allow for a more vivid world for Omni (and the player) to explore. And as the title might suggest, it is all about layers!

GameMaker:Studio 2 and Layers

So, for the readers not knowing, we are using GameMaker:Studio 2 as our engine for Tale of Omni. In GMS2, parts of a game like levels and menus are typically divided into "rooms" (kinda like scenes in Unity, for reference), and unlike earlier versions of GameMaker, objects, tiles and other resources a placed in "layers" which also decides the order of which these resources are drawn onto the screen.

To make the environment of Tale of Omni look alive, I use quite a few tile layers, most of which I have ordered in different folders along the layer list as seen in the screenshot below.

This ordering allows me control over where elements are placed in relation to the player and other objects. Also note the "temp_fade" background layer between "bottom_tiles" and "background_tiles". This background is a transparent black color, which makes me able to visually differentiate between background tiles and the rest.

I will speak more of this later in the post. Now, back to the layer list: Inside each of my tile folders, I have a variety of similarly named tile layers, which is where the actual tiles go.

Except for the layer names' prefix "top_", which changes across the folders, the names of all the layers are the exact same. This allows me to easily manage the tiles through code, as I will further describe later. Now let us begin making everything look alive! I have set up the beginnings of a small area of the game with a huge tree.

Beginning from the background tile layers, I start out filling in leaves for the tree. Note that I place the leaves on the dedicated "foliage" layers (top and bottom), but not on the "foliage_static" layer.

Now while working the background, we might as well add a little extra tiles around the area to break up some of the repeated tiles.

Next up I move to the foreground/"top" layers, as I want the remainder of the leaves to be on top of everything. To make leaves overlap, I add a few more layers. Except for the end number, these layers all share the same name.

When I am satisfied with the tree, I go across different layers and add more tiles around the scene. A few mushrooms, flowers and bushes.

Shaders and Scripts

Now, tiles alone is all fine and good, but I don't want the nature to look static. Therefore, in a specific object's room start event, I have the following code (the event, and thus the code, will run once a new room is entered).

The first part may be ignored, as this is used for other purposes. The interesting code is the code starting from "//Background blending". Here I tell GMS2 to make the "temp_fade" layer invisible, so that it does not darken everything in the background. I do not want all of the background to be darkened, but I still want the tiles to be, so I go through the background tile layers using a few loops and apply a darkening shader to them. This is where it is especially nice to use easily recognizable and structured names for the layers.

Next up I find all the foliage layers, again using a series of loops, and then I apply another shader to these. But because this shader needs game variables to be passed, I instead give the layers scripts to run before and after drawing. These scripts simply sets and resets the shaders, but also they pass the proper variables to the shader. The background foliage layers gets a unique script, as it needs to both animate the foliage but also darken the tiles, as it is a background element.

End Result

Voila:

Now, while the scene still needs some tweaking (I think, for example, I added a few too many leaf clusters), I hope this blog post illustrates the effort put into making the world of Tale of Omni look more alive. And if you are an aspiring GMS2 user, maybe you even learned some tips on what you can do with tiles!

Either way, I have had a lot of fun exploring the possibilities of tiles and shaders in GMS2, and I look forward to continue building a beautiful world for Tale of Omni and the players to explore!

Sincerely, The Architect

[taleofomni]

Troubles of writing a tale

As described earlier, my role on the team is to both compose the music and the story for our game, yet i have little experience writing a tale of this size. Up untill now the process of creating the story has progressed by The Architect and I manifesting ideas for the main plot. Just recently we reached the point were we have made a diagram of the main locations and paths Omni can take through the “Game in a Game”-world and as the next step i was given the task of writing a game-script, which should be in the form of a children’s book. In doing this i was supposed to strip down all the many things we have discussed to be only the main storyline, which a very straight forward player would experience. This cutting down of actions performed and motives contained by the story’s characters, is supposed to make this version of the story into a foundation upon which we can build when building the level-structures, cutscenes and dialogue trees.

Right now the children book version is still in a rough state, yet it is coming together. It has been no easy process to keep the discipline, as i’m am spending a semester on an danish folkehøjskole where there is a lot stuff going on (both class duties and tempting social activities).  Initially i had a lot of trouble finding a writing style which would have the right amount of detail for it to be “bare bones” and sensible at the same time. This balance has been the tricky part throughout, as some parts have had to be written out in a lot of detail in order for me to select what the most important parts are. Some parts have of course been more straight forward to narrate, yet the key to this whole process  has been to listen to game soundtracks while writing. The soundtracks i have been listening to have been carrying both kinds of processes, yet while progressing with the writing, i have tried to select what i listen to, being conscious of what part of the story i will be writing. I’m doing this as i experienced that listening to certain game-soundtracks has helped me in selecting what really is the core of certain plot movements, as the music would fill out all the vacant space left by the stripped down narrative. So apart from helping me in not getting distracted, listening to game-soundtracks has helped me balance the amount of narration that i have put into this version of the story.

Overall it is a large refining process of all the ideas we have been discussing throughout the last year. The weak points of both the narrative and my writing really show and i hope that writing it out like this will make it possible to improve upon both by having an object to discuss with the team. The creation of the children's book version of the story will probably be a bit of an ongoing project, as we flesh out the story in game-form. Game-music is able to fill out a lot of the felt vacancy, but it is of course not able to show how the narrative fits into the mechanics of a story being told through a game. Problems with this version of the story will arise, but it will we really interesting and enriching to see in which ways it is not compatible. I’m looking forward to learning a lot throughout this process! Sincerely, The Bard

[learn-blesshaygaming]

Using Aseprite with Spine (Part 1): Aseprite

Should work for most versions of Aseprite v1.2 beta1 (or newer). Should work for all versions of Spine.

For this tutorial I used Aseprite v1.2.6 and Spine v3.5.46. I personally use Spine, but this method should work for other skeletal animation software as well.

I work on a Windows PC, so I do not know how things may differ on a Mac or Linux PC.

Introduction

During our development of Tale of Omni we use especially two pieces of graphics software: Aseprite and Spine. Aseprite is where we, the Artist and I, draw the graphics. And then, unless the character needs only few or no animations, I animate them in Spine - else they are animated in Aseprite by either of us. When I animate in Spine the character needs to be cut-out into parts, as Spine is software for skeletal animation. To begin with I used Photoshop as an intermediate step for doing this, as you may have seen me explain before.

Today’s post will be a tutorial on how to cut out the middle man and make ready-for-Spine content directly in Aseprite.

Starting Your Work in Aseprite

Since this tutorial is very focused, I will work from the assumption that you know your way around at least the basics of Aseprite and Spine.

1) Start off by making a new document big enough to fit everything (you can always resize the canvas as you go, of course). Then make a secondary frame before you draw your parts. Draw on the second frame and let the first frame stay empty - we will be using the first frame for masking later.

If you already have a character ready to cut out, simply insert an empty frame before it.

2) Make your character. Draw each body part on its own layer (or cut out an already existing character) and give the layers suitable names. You do not need to follow my naming conventions, but make sure your names are not too abstract, as these will be part of the exported filenames as well. Also add a tag to the skin describing the “type” of character (this might be easier to do after adding more skins in the following step).

3) Make more characters. Or “skins” for your character. Of course only if more skins are needed. The alternate skins should fit on top of the original one, as they will end up sharing the same skeleton. If they fit the same type as your previous, original skin, group them under the same tag as I have done. Else group them under other tags.

Note, it is possible to make impactful changes if you can visualize how the skeleton will be (or if you return and make skins after the skeleton is developed). For example, my two panda skins have different tail lengths.

4) Time for masking. But before I explain what to do, I will explain why to do it.

When working in Spine, I like to be able to reuse. After setting up my skeleton and my first skin - including making meshes and the like - I would rather not have to set the graphics for the following skins by hand as well (I will go more in depth with this in part two of this subject). But if I simply replace a graphic with another, or if I update a graphic and re-import it, and the graphic is not the exact same size as the previous one, then funky stretching will happen as shown below.

(The image below showcases the small, round panda tail being stretched due to a mismatch with the length of the red panda tale)

This is why I like to make a mask for the graphics. When exporting layers from Aseprite and trimming them (more on this later), the different frames will be trimmed to be of equal size. This means that if a frame is larger in size than another frame (like the red panda tail is longer than the panda tail), the canvas of the panda tail will be enlarged to be the same size.

I use masking to indicate the potential max-size of a given part, thus giving myself room to play around with skins in the future without screwing all my work in Spine up. I do this by going to the first frame, and then I draw pink rectangles on each layer showcasing how big that particular body part should be able to be. Toggling on onion skinning is quite helpful here.

I then put a tag like “Mask” on that frame. It is important to do this after being done with the masking, as onion skinning will only work within that tag afterwards.

5) Now it is time to export the layers. To do this you need to close down Aseprite, as this is done through the Command Line Interface (CLI) (or in our case through a batch file). Aseprite allows for a lot of awesome stuff through CLI - you can read about it here.

You start out by opening notepad. Then you define two variables: One for the path to the Aseprite software, and one for the path to the project file.

I like to make my batch file usable across multiple projects, so instead of writing the name of a project file, I fetch the name of the batch file itself and uses that name by writing “%~n0” (this is what it means). This way I just need to rename the batch file to fit the project I want it to work its magic on. The two variables looks like this in my case because I use Aseprite from Steam:

@set ASEPRITE="C:\Program Files (x86)\Steam\steamapps\common\Aseprite\aseprite.exe" @set FILENAME="%~n0"

I then like to create an asset folder for my parts, which you can do like this (note that I use the previously defined variable for the folder name):

mkdir %FILENAME%-assets

Then comes cutting out the parts. This is done by running %ASEPRITE% with the batch parameter “-b” or “-batch”. We tell which file to target, %FILENAM%, and then we apply a series of options:

–ignore-empty: If one of our skins does not have a tail, as an example, there is no reason for exporting an empty frame.

–trim: We only want the parts to be as big as their masked areas. If our whole project is 96x96 pixels, we do not want each part to be exported with such a big canvas - it is a waste of resources and makes it harder to work with in Spine.

–save-as: We of course want to name our files, and in doing this we can modify what Aseprite exports further: By adding {layer} as part of the filename, we tell Aseprite to export each layer individually, and by setting the file extension to .png, Aseprite knows that we want individual frames. Since we want to differentiate between tags (as we use them as skin type groupings), {tag} makes sense to insert as well, and we can tell which frame in the tag we are looking at by inserting {tagframe}. I personally want it to count like 01-02-03 instead of 0-1-2, so I alter the tagframe like this {tagframe01} (more formatting options can be found here).

Finally our line of code should (or could) look as follows:

%ASEPRITE% -b %FILENAME%.ase --ignore-empty --trim --save-as %FILENAME%-assets/{tag}{tagframe01}_{layer}.png

But you might also want to export the assembled characters as an assembly guide to use in Spine. That could look like this:

%ASEPRITE% -b %FILENAME%.ase --ignore-empty --trim --save-as %FILENAME%-assets/AssemblyGuide.png

That concludes our batch file, which should then look like this:

@set ASEPRITE="C:\Program Files (x86)\Steam\steamapps\common\Aseprite\aseprite.exe" @set FILENAME="%~n0" mkdir %FILENAME%-assets %ASEPRITE% -b %FILENAME%.ase --ignore-empty --trim --save-as %FILENAME%-assets/{tag}{tagframe01}_{layer}.png %ASEPRITE% -b %FILENAME%.ase --ignore-empty --trim --save-as %FILENAME%-assets/AssemblyGuide.png

Now you just have to save it. Make sure to give it the exact same name as your Aseprite project file, and in the same folder. The only exception is the file extension. You should save it as a .bat file.

Then simply double-click the batch file to run it. A Command Prompt window will show momentarily, and then a new folder of assets should be generated.

And that’s it! At least the part considering Aseprite. From now on, if you make changes to the character or make new skins, you simply delete the asset folder and double-click the batch file to re-generate. That’s how easy it is.

Next post will be about how to import and use this content in Spine - stay tuned!

[taleofomni]

This tutorial gives a glimpse into handling the graphics of Tale of Omni. It is written by me, and this first part is all about exporting the first pass of graphics from Aseprite so that it may be ready for use in Spine. Sincerely, The Architect

[taleofomni]

Status Update

Hello again dear readers! It is me, the Architect, here to inform you of the current progress and matters at hand. It is not going to be a long post, but it should inform what you can expect future posts by me to be about.

The team and I kicked off the month (and the year) with a grand meeting lasting about half a day. The point of the meeting was to summarize our current standing, reflect on our individual roles in, and expectations for the project, and plan our next moves. It was a very giving meeting and we set the course for the project for January.

For me the task for this month is to re-write the general physics of the game and finish up Omni himself in terms of movability. The physics re-write is needed to make it even more adaptable to what we need it to be able to do. Also it I need to write a bunch of flags into the code to have something for other objects (say audio and particle controllers) to latch onto.

While I see myself as quite adept at programming in GameMaker (the game engine the project is written in), I naturally keep learning as well. This can be quite troublesome during a project as Tale of Omni as I continuously return to old code to update it to my new standards. I feel an urge to refactor all the time, which slows down the development of new things. It is something I need to work on, as Tale of Omni is going to be a big game, and while clean code is important, it is much better to get the basics working first.

I saw these huge changes in myself and my ways of working programming first hand recently. Last weekend I participated in the 25th GM48 game jam - you can check out my game here - and my whole approach to game design and programming felt different than it has been in previous projects. I do a lot more pre-production now, whereas I used to jump in head first and adapt the code as I went along. Jumping in head first is a fine approach for prototyping, but when it comes to making real games, especially games the size of Tale of Omni, it just won't do. Because Tale of Omni began with the head-first-approach, the code has often needed revision. Other than the approach I also pick up more and more good practices for programming - for example I just changed all global variables from being initiated with globalvar to be using the global. prefix instead.

The current re-write of the code and the finalization of Omni should be the last changes to these parts of the project (well, Omni will need more powers, but those will all be working within the system). It is a lot of work - and there are much more work ahead of us - but the boulder is rolling again, and that is what matters.

I hope you have enjoyed my short read.

Sincerely The Architect

[taleofomni]

Star Wars Episode 8 and “World Strictness”

DISCLAIMER: THIS BLOG POST CONTAINS VERY MILD SPOILERS FOR STAR WARS EPISODE 8.

Let me start this one off straight: I have been quite moved by the polarized reactions to “Star Wars Episode 8: The Last Jedi”. I consider myself a big Star Wars fan, although I don’t fit the metrics of owning a lot of merchandise or knowing everything about the extended universe. I like Star Wars for the story, the characters, the mythical and archetypal level which the storytelling reaches with the scale of the main story and the way in which good is pinned against evil. I grew up with the sequels and loved them for their “cool”-factor, rewatching them as I got older I of course realized how flawed they were. Still loving the universe and characters, arguments with The Architect and videos like “The Star Wars Prequels are Secretly Brilliant?”, let me love the Star Wars Episodes as a whole, despite their flaws. Partially due to replaying the Knights of the Old Republic games together, The Architect and I agreed upon there being a great potential in the then announced extension of the series. Especially the aspects of showing how the prequel jedi order and teachings were not “in balance”, the potential of explicating what kind of balance Luke brought to the force and the universe – the “happily ever after”-ending of Episode 6 seemed quite abrupt.

After watching Episode 7 and being quite bummed out by how little context and solid information was given, I was not eagerly anticipating Episode 8. I went to see the movie, quite clean of expectations, I would say, and the thing is: I loved it. I didn’t have my hypercritical goggles on and it took me away (far far away, that is): I was amazed by how drastic plot twists were dared and how poetically the mirroring of Episode 2 & 5 was handled. I watched it twice, 2 days in a row, and then I went on YouTube…

Initially I was quite shocked by how negative many reviews where, how hurt people were by the handling of Luke’s character and how intensively people were hunting for plot holes. After watching a couple of videos (some “defending” the film aswell) I was torn: I couldn’t deny that I had loved the film, yet I could see some of the criticisms and how the story and world building still left many things to be desired. From this rose a questions: What is it that the Star Wars storytelling is supposed to attain? And more generally: How “free” does pseudo-mythical storytelling need to be from a perfect logic, in order to pose the messages it can deliver?

One of the things I thought, leaving the cinema after my first watch, was that the film became “Star Wars” by balancing risk taken with poetic messaging. By poetic I mean a certain elegance that I perceived in many of the bold plot moves, yet after watching opposing YouTube videos, I totally get that this elegance is hard to see, when a universe you are so deeply invested in is on the line. When things never previously seen in the Star Wars universe are suddenly used in the 8th episode of the main series, this easily comes off as offending to everything previous – the continuity of the rules set for the story’s world is torn. To me Luke Skywalker’s role and new story is perfectly acceptable (I am probably not as invested in his character as others), yet I see the validity of the question as to why  everything in the new trilogy has to be so extreme, so “new”? In a way I like them being “new and extreme”, as this for me is a part of the nature of Star Wars. Yet these traits also challenge the continuity of the created world and the story as a whole.

I don’t want to judge the new trilogy before it is actually completed, but Episode 8 and the following discussion in the YouTube community has really given me a lot of food for thought in regard to creating the Tale of Omni story. Our story is of course a totally different matter than Star Wars and most importantly the context of creating a new world and story is fundamentally different from handling an already existing one. The thing that I have gained from the Episode 8 controversy and see as very important and relevant for our Tale of Omni process, is the consciousness of the “world strictness” parameter and its importance. Right now we are working on the storyline of Omni’s Game in a Game and an interesting thing may be to have this contrast with how the “strictness” is handled outside the GiG. I don’t think it will make any sense to have them be very opposing, but “skewing” the laws of the meta-world could become a very powerful tool, as the main thing I have learned from my experience with Episode 8 is how central the personal perspective and world-expectation is to the impact of a story. There is something very meta about being conscious of how different points of view change a story’s power fundamentally. In a way this is already part of the story arc of Tale of Omni, but my experience with Episode 8 has encouraged me to experiment more with how this can be used on different levels, for instance with the consistency of the created world, inside and outside the GiG.

I Hope this gave you something to think about in regard to Star Wars and also just a bit of insight into some of the thoughts at work behind the scenes of our creation process.

Happy new year to all,

Sincerely,

The Bard

[taleofomni]

The Oracles first words - a DADIU reflection

Hey all. I think it is about time to have a proper introduction of yours truly, the Oracle. Though I have been mentioned in earlier blogposts, this is the first time speaking my own words. Here is the basics: I’m 24; studying Digital Design with the Architect and the Artist; have a terrible sense of humour; and love to play games!

As earlier mentioned, majority of the team have been attending DADIU (The National Academy of Digital Interactive Entertainment) this semester, where I had the role of Lead Quality Assurance (QA) & User Research (UR) Manager in Copenhagen. (For the rest of this article QA & UR Managers will be shortened to QA’s).

As a total newbie to the QA role, I was quite excited to start at DADIU, since I at the time had just joined the team. I have always wanted to be a part of the Tale of Omni project since the beginning, but I couldn’t figure out how I could contribute to the team. When the Architect asked me to join with the focus on QA and UR I jumped in immediately. I therefore wanted to learn as much as possible from this semester to help the Tale of Omni be the best it can be.

Though I also was assigned to a team at DADIU, just as the Architect, I also had to manage the other QA’s in Copenhagen in cooperation with another Lead in Aalborg. I remember early in the semester I spent a lot time on this issue, but as we all got more worked into the whole QA & UR role, the other QA’s became more independent, and thus not in the need of an overall managing from my side.

When we were first introduced to the QA part of it, we were told that we had to have a certain distance to the project we were assigned to. This was due to keep an objective sight upon the project. If we are too attached to it, we could easily miss out bugs and issues during testing, this means that a lot of effort must be put in into documentation from the production teams side, but as the Architect previously wrote: “Aint nobody got time for that”. During the semester it was therefore a general problem getting the needed information from the teams to do proper testing. So many found it easier to get this information by spending time at the productions teams, instead of the QA office, with the only reason to get needed information faster. Thus making us closer to the production and therefore obscuring some of the objectiveness towards the production. It is a tightrope walking to be a QA. I will try my best to keep a certain distance to the Tale of Omni project, so I can help improve it as much as possible, but it is going to be hard.  

Another aspect of being a QA is that you are always behind. When the team deliver a build, you’ll have to set up the test, go through documentations to test it right, write testcases, book other QA’s for testing, do the test, write down issues, document it, and finally deliver a report to the team. By the end of this round-a-bout the team has already moved on to new things, and some of the issues may already be resolved. Some may already be known, but has been forgotten to be send to the QA’s before the test. The testing therefore must be done quickly but you must keep quality in mind. Like what type of test is needed now? What adds most value to the project? What are the request from the team? Etc.

What it all comes down to is communication. It need to be short, clear and fast, since everything moves so quickly during the process. Information needs to be distributed through the right channels, and you need to follow up on those information’s. Just to make sure. On of our teaches used to say: “Check, check, double check.”. This clearly goes for everyone, but regarding my own process, I often realized that my reports and information often wasn’t delivered to the right persons at the right time because of a bottleneck in the communications pipeline, if even at all. A lot of work was therefore not being used to its potential. I don’t think this will be an issue here on the OMNI project, since we are not a big team, but is still something that need to be in our consciousness.

In regards to User Research I have got a better insight both in terms of recruiting and testing methods. I hope to use some of this on you in the future when the OMNI project develops further. Like the QA it is always a question about what adds the most value to the production. Different kind of playtesting is really useful, but is something that is often forgotten in these kinds of projects. I will do my best to include you guys into the project as much possible, whenever it is meaningful in the process. I may even push it forward if I see the need for it!

I have talked with the Architect about how we can do the QA and UR process as best as possible for the OMNI project, and since we both now have an insight into its realm, we believe, we have found an excellent work process for it.

I hope that I in the future can share some of the funny bugs, that I know for sure will come, with you. Then we can all have a laugh! I expect to share this both on Instagram and Twitter.

In any case, I’m very excited to start working on the project again after our long break from it!

Sincerely

The Oracle

[taleofomni]

A DADIU Post Mortem

Earlier this year I wrote about some big changes that had entered our project and lives. One of these changes were that both the Artist, the Oracle and I, the Architect, are attending DADIU (The National Academy of Digital Interactive Entertainment) this semester. While we are not fully finished yet (there is still one week left of productions at the time of writing this), I believe it is time for me to reflect on it all in relation to Tale of Omni.

QA & UR Manager

As I mentioned in the previous post of changes, my role on DADIU is Quality Assurance & User Research Manager (QA & UR Manager). As I have written before in personal ramblings on the matter, I were skeptical of entering this role in the very beginning, however, I have been learning a lot, and I am thankful, I got the opportunity. In the following I want to go through the main lessons, I have learned.

As a QA I have learned, that something does not have to be done to be tested. Or, well, I knew that already (I often prototype things), but I have really gotten the lesson under my skin now. By not being the one actually developing the games I have been able to see the value of testing things from a whole other perspective. I am a changed man. This has lead me to begin uploading weekly builds to the team, so that they can follow progress, and so that the Oracle can QA the shit out of the project as we go.

Closely tied to this lesson I have also learned, the importance of documentation. Yes, I touched upon this last time, I wrote, but it sticks deeper than the things, I wrote about then: I have now experienced first hand how troublesome it is to judge, whether things are like they should be, while not being close to the code. I have always been the programmer and designer, and I have always known my projects by heart, but for everyone else, it is much harder to know what happens. We already do meetings on the team, and as I explained in the post about documentation, I am also working iteratively on a game design document now - but I have also begun writing release notes for each build. This allows my fellow team members to know every small change happening to this part of the project, and it allows me to track what work, I have been doing, and what needs fixing.

When it comes to user research, my whole world view has been changed. As a Digital Design student at Aarhus University, I have been taught a whole lot about "the good design process": How to plan and execute workshops, iterations, mock-ups, prototyping, etc.. These has been good lessons, but "the good design process" as I knew it is utter utopia. Nobody have time to do prober cycles of iterations and develop ideas with user input in every single step. It simply takes too long. As UR I have learned, that the real challenge of user research is, to extract as much value from very little. ​ This does not mean the users should not be heard, but simply that you shall pick your battles, and not suggest a full blown workshop in each and every step of the process. Sometimes it gives more value to the team not to ask the users, sometimes guerilla-testing on the street is enough. You just need an approximation of the users' needs - even the best of workshops would not give you the full picture anyways.

Following a Production

I did not only learn things as a QA and UR Manager. I knew from the beginning of the semester, that I would get most out of DADIU, if I were to learn from multiple other roles as well. So I tried to continuously look at the mistakes and victories of my team mates.

Learning from the programmers, I have further divided my code into individual systems, so that one system may be fully revamped without having to edit the whole code base. One of the recent changes, this has lead to, is a full-screen shader manager to keep track of various effects (bloom, day/night, saturation, etc.).

From seeing the Game Director and Project Manager do their work, I have also learned a lot. I have seen how important it is to be able to delegate work to my team mates, but also how important it is to always stay in the loop. It is okay that I have vision, but it should never be reason to push aside my team's needs. A team works better when the outcome is in line with hopes of the individuals. On the other hand I should not be afraid to demand things from my team. Sometimes you have to be less soft. But for God's sake, do not confuse that with being unfair.

Watching the Game Designer taught me a lot about the importance of being precise. Illustrate what you mean and try to think every little detail into it. But also ask for feedback and improve. Knowing, that what you make is not perfect, and letting the team know that you know this, is valuable.

I have also had the honor to work with some very talented artists, both in terms of visuals and audio. From the visual artists it became even more clear to me, how important it is to work out a direction for the art (and I saw how well such things could be made). I also learned that each piece of concept art should be made with purpose. From the Audio Designer I learned that maybe it is time to add some audio to Tale of Omni again. Because it does not have to be finished. It may even be crude. But it gives much more sense of the direction to iterate on the music and sound effects from early on.

To Conclude / tl;dr

Being part of DADIU has been a rich experience. I have learned a lot, grown, met great people, and had great fun. In about a week we are done, and the whole team (almost) will once more be in Aarhus, ready to continue work on Tale of Omni. It is going to be great, and it is something, which I look very much forward to. Have a good one.

Sincerely The Architect

[taleofomni]

Money is one hell of a drug

Unfortunately (for you) I am still playing Ocarina of Time, so this time around I have no new perspectives on the sound-design of Tale of Omni. As a little intermezzo, I would like to discuss the subject which has been across all gaming news last week: The debacle that was the launch of EA/DICE’s Star Wars Battlefront 2. I would like to discuss this as it reminded me of some loose ideas we have had for commenting on game-monetization in Tale of Omni. I believe that it was actually the first EA Battlefront which spurred our thoughts, due to its severe lack of content at launch only remedied by buying the 50$ season pass. As far as I remember we just talked about taking some jabs at the un-ethical creation of incentive to buy season passes, by creating fake marketing for Tale of Omni, detailing what fantastic amounts of DLC we would have for the game. Our ideas may have been quite salty in sentiment, but the recent launch of the new battlefront really enforces my desire to comment on how greed destroys video games.

Almost everybody points out how clearly greed is the foundation of the new battlefront’s progression system, but it then becomes more differentiated as to why people think this is a problem. Although the ethical questions of gambling probably were the reason for Disney pushing EA to disable the microtransactions temporarily, I would like to put these questions aside, as I find it more interesting what consequences the gameplay actually suffered from the poor implementation of loot crates. I say poor due to how blatant the game tries to incentivize purchasing them. The grind, the supposed 4528 hours needed for unlocking everything, is of course an obvious challenge for gameplay enjoyment, but what really ticks me off is the idea of all progression being direct upgrades. As LevelCapGaming has pointed out, most upgrades are direct upgrades, meaning that you gain an obvious advantage, as for instance with a straight reduction of the time needed for your health to replenish after taking damage. LevelCap suggests that a system based on sidegrades, instead of direct upgrades, could benefit the gameplay tremendously and I agree. What I found worst about the game (I played part of the 10 hour trial (yea, I stopped playing before the time was up)) was the ever present feeling of the game not being fair. As a ground for this notion we of course have the new gameplay-style with its high-pace-combat, but this alone does not do it. The coherence in performance/outcome is suffering due to the direct upgrades which the better “star cards” produce and not only do you experience this through gameplay, but after being killed by a better equipped player, you are also presented which upgrades he is using.

What I find fatal about the gameplay of the new battlefront is really how hollow the imbalance makes the game feel – you play, to get the better upgrades which then directly give you better results? That feels so cheap and of course the whole aesthetic of having the upgrade process happen through loot crates just makes this even worse. I find that with this game EA is really pushing to make a game with the looks of a modern AAA-title have the gameplay of an arcade slot-machine – the only difference being that the arcade machine feels more fair, due to no one being able to buy performance enhancing ingame-drugs.

I felt similarly about the first EA battlefront (which I anticipated greatly), but there I didn’t find the gameplay to be as ruined as with the new one. The first EA battlefront’s gameplay was poorer in number of mechanics, but at least it didn’t feel as unbalanced as this one, thereby allowing for some seldom moments of feeling like you were actually part of the Star Wars universe. I think both games lacked heavily in “fun-factor” and “gameworld-depth”, but my greatest take-away in regards to producing the story for Tale of Omni is how villainous EA proves themselves to be. Having one of the world’s most popular IP’s and enormous amounts of investor money at their disposal, they manage to let greed get the best of them, creating sub-par gaming experiences. Following this story I think I have found some great inspiration for the motives and modes of Tale of Omni’s villains - how what they do clashes with what they say. Right now I am saddened by how this influences my love for Star Wars, but I hope that my experience with these games in the long run can add some edge to some of the messages contained in Tale of Omni. The jabs have to be more classy than just running fake DLC marketing, yet I smell great potential…

Sincerely,

The Bard

[taleofomni]

A Note on Documentation

It has become my turn to speak my mind again. This time I will talk about the importance of documentation in game design, and how we use (and will use) documentation while developing Tale of Omni.

I will start out by addressing the tools we use. We have changed our toolset a couple of times throughout development in terms of documentary tools, but I think we are somewhat settled by now. This will not be to say, that these tools are better than other tools, but the tools we have chosen is forming the way we work, which is why I believe they should be addressed.

Secondly I will be laying out a series of problems, which we have had. Problems I would say mainly existed because of a lack or misuse of documentation. This is not to say we started out completely without any use of documentation! From the very beginning we have been very throughout when it came to document our meetings, and writing down our thoughts. But it has been a continuously revisited area, and we have been through a lot of trouble because of it.

Lastly I will address the problems, and describe how things are done on the team currently to avoid said problems. I will however be truthful: Our approach has not magically removed all the problems. It has, however, decrease the amount quite a bit. Anyway - let us start at...

The Tools

Since I am the originator of the project, it should be stated, that for the longest of time - and still quite a bit currently - the documentation was me. I have been pretty good at remembering decisions made during the project, and especially because the project started out somewhat smaller in scope, I could quite easily remember the broad strokes (I did write notes down for myself sometimes). As the team became a thing, I was still the main documentation, which opened up for some of the problems, I will address later in the post. But we did begin to write down a lot of things.

We started out using Google Drive and Docs to collaborate on documents, and we began having meetings (meetings being a great tool for discussing progress and problems), which we also documented.

We also from very early on began to use Trello for our graphics pipeline (see below). Well, it started out being for general planning, then developed to be graphics only. Now we have multiple Trello boards to cover both graphics, programming and quality assurance.

We did use scrumy for a while too, but that did not work out for us, as we never fully implemented the scrum method, and often forgot about it.

Docs worked great in terms of sharing the documentation and being able to work on it together, but after a while we moved on to Dropbox Paper for our document writing purposes (we still use Drive for other files). As with Drive, Paper allows us to share files and work on them together, but it also allows for easy implementation of resources (videos, pictures, and lots more), tagging, easy cross-document referencing, and is not very cluttered to look at. It is almost the perfect tool for us. You can see in the image below as an example, how we use Paper for gathering inspiration for different areas in the game.

We have also recently adopted Slack into the tool family. While we do not use it for documentation per se, I think it is worth mentioning. We started out just communicating through Facebook chat, but we wanted to move away from Facebook, as we do not feel comfortable sharing important stuff and imagery in the chat. Also, by using Slack instead, we could divide the chat into multiple areas of discussion, thus making it easier to re-find information at a later date (ie. it is sort of used as documentation). Slack can integrate both Paper, Drive and Trello, which is perfect, and also Bitbucket, which I use to keep track of my code. This allows the other team members to follow my progress easily, which is nice.

tl;dr: The main tools currently in use are:

Dropbox Paper

Google Drive

Slack

Trello

Now let us move on to...

The Problems

As I described in the previous segment, a lot of the project have been happening inside my head. Since the project has been ever changing, I started out quite reluctant at writing too much down. We had our meetings, we wrote a lot down, but we did not really differentiate a lot between ideas and solid "this is how it will be"s.

As I were sitting with the code and am the most experienced one of us when it comes to making games, I had a clear image and vision in my head, and it felt quite obvious to me what could and could not be done, what was solid, and what was not. However, as time passed, I had to re-explain a lot of elements again and again for the team, and it felt like a lot of discussions resurfaced continuously. Further more ideas where often suggested which would change the course of the game dramatically.

To summarize this as problem #1: People are not mind readers, and while a forum open to suggestions are good, ideas need to be solidified at some point. We cannot keep on changing direction. We were too stuck in ideation.

Problem #2: While we did write down a lot of notes, especially during our meetings, they were rarely visited or revisited. I believe this problem roots in missing accessibility and order of importance. We have a lot of documents, but that also means there is a lot to read, and...

In short, while documentation is good, it needs to be a feasible amount, and you need to be able to find what you need - easily.

But this is not the only roots of this problem: While using scrumy this was apparent. It was one page in the browser you had to go update whenever you had a new assignment, progressed on one, or solved one. Pretty easy. Still, I found that I was the only one actually doing it, which ruined the purpose of it. I stressed again and again that it was important to do this, but it never came to be...

...problem 3: Motivation. This is independent of whatever system is in use. The team needs to use it, else it is of no use. Honestly I believe this is an everlasting issue, especially when the project is not funded in any way or form. Everyone have their own lives to live besides the project, which makes it a constant battle for me to figure out how much I can push the rest of the team. On one hand I demand that they prioritize the project a great deal, else nothing will get done. On the other hand, I cannot force them to prioritize it as highly as I do.

Anyway: Motivation is a tricky thing, but I am trying to keep it in mind, as it is a very important factor.

These three problems are by no means the only problems we have run into during our process, but I think more problems will make this blog post way too long. Let us get to...

How We Do Things Now

The problems laid out above have greatly been shaping how we work on Tale of Omni on the team, but I must disclaim: Some of the solutions to the problems, I will tell you about just now, are pretty newly implemented (some of them not fully), so exactly how well they will work, I cannot surely know. But game development is a process, and this is where we currently stand:

Externalization, a solution to problem #1: While externalizing our ideas and thoughts are generally great, this one is (at least for now) very much a task for me. I have spend a lot of time recently to externalize the project and make it readily available to the team. I developed a vision for the project, which we refined at a meeting, to grant us a general sense of direction, as well as a design document to make it clear what the game will feature, how exactly mechanics will function, etc. (Yes, truly, we had no game design document before this - the information were spread across my head and a multitude of different documents). More recently I have begun work on three "super users" - the target group for the game. These will still need further development, and especially the Oracle will play a huge part in refining them.

Accessibility, a solution to problem #2: Using Paper gives us a lot of niceties, as I described much earlier in the post. First as foremost, the overview is pretty clear! But what I believe, will become really useful for us, is the #tagging. We have not widely adapted it yet, but the Bard and I have begun development on some tags to use to mark ideas, so that we can easily find, return to them, and discuss them, without needing to search through 4-5 old meeting documents.

In a similar vain the integration of Paper into Slack makes it easier than ever to share meeting notes and other documents with the rest of the team, and summarize what happened on the meeting (in case some team members were not there). I think these improvements of accessibility have been much needed.

For problem #3... I honestly have no generic solution. What we can do, is motivate each other, but it is a tough chore shared by us all. Hopefully the added accessibility of documentation and externalization of the game design will aid to the documentation. Hopefully being able to read a clear vision will do good. We will see. I think, I need to eat something now.

Kind regards, The Architect

[taleofomni]

The Need for an Aesthetic Frame

The term “aesthetics” has become increasingly obscure with both scholars and everyday people using it in a myriad of ways. In the context of me producing the game-music for Tale of Omni, I would like to use “aesthetics” to describe the forms of expression used to achieve the coherence in a game’s music. To further achieve some coherence in a whole soundtrack, there is a need for an “aesthetic frame”, which sets some bounds to work within. So today I would like to share my initial thoughts on creating this aesthetic frame for the game-music of Tale of Omni.

Recently I began replaying Zelda: The Ocarina of Time, as it is one of the games that shaped my childhood, all while I actually never got around to finishing it (water temple burn-out, yes). It has been both odd and fascinating to come back to it, as time reveals how “simple” the game really is in forms of expression, while creating a near magical moodyness. Part of its effectiveness upon me is of course nostalgia, but what has really struck me is how well the game creates a synergy between visuals and audio. The title screen is the perfect example of this: Link riding through the plains at sunset, the mood set-up by the slow strings, Epona’s hoofs and piano-arpeggios, while Link’s sole figure is mirrored in the sole ocarina playing the mellow lead melody. Not only is this a plain coherence between the instrument playing lead and the games title, but it fits so well with what you are actually seeing, that you don’t even have to think about it. The game-music being sample/midi-based, the quite obviously static rhythm and destinct 90s synth sound fit in with the low-polygon count 3D visuals. The technical limitations further act as an aesthetic frame in creating coherence in the whole of the games music and its different moods.

With me producing the game-music for Tale of Omni today, I do of course not have comparable technical limitations, which give me this frame - I have to create one, suiting the game. The Architect and I have discussed the use of 8-bit sounds, as these could fit quite well with the parts of the game where Omni comes in near contact with “the computer world”. We agreed that an 8-bit aesthetic is way to extreme, to fit the game as a whole. There may even be a question in how coherent the game-sound of Tale of Omni should become, as we have a pretty radical shift in the story, going from game-in-game to meta-game. One of the dogma’s we carry here, in regards to the story and gameplay, is that the world outside of the game-in-game is still structured by Omni’s perspective and therefore is still somewhat familiar, thus the music should not just turn into noise, but be distinctly different from the game-in-game music. This means that the frame of coherence is extended, but still we need one. After having explored the formalities of how we want audio in the game, with my previous posts, I would now like to move forward to developing this aesthetic frame for our game’s soundtrack.

Darren Corb, the audio composer of the 2011 indie game “Bastion”, found his aesthetic frame in the limitations of his budget. Combining drum-loops and his experience as a guitar-songwriter he created the term “Acoustic Frontier Trip-hop” as a guiding genre-term. I don’t think i need an explicit genre term to guide me, but I definitely want to set an aesthetic frame, by limiting myself in tools and instruments. Playing Ocarina of Time I have to admit that I actually like the 90s sample-synth sound, so maybe we have a first contender for a spot on the Omni-instrumentation team, well have to see…

Sincerely,

The Bard

[taleofomni]

Visual cues in enemy design

Greetings followers!

It is time for another update from yours truly, the Artist. However due to a time constraint today’s update will be rather short, I know you’ll understand. I am currently working my fingers to the bone as a full-time project manager as part of my semester at DADIU - The National Academy of Digital Interactive Entertainment - as was also mentioned in a previous blog post.

Although by a minimal amount I have been doing some work on Tale of Omni. As of now my current task is to design and animate the enemy “the ram” which Omni will encounter as a part of his journey in the mountains.

Similar to any graphics I have developed for the game, this creature has gone through various iterations and redesigns. At first we even wanted Omni to encounter a goat in the mountains instead of a ram:

The goat was meant to be a mountain goat, hence the design of the mammal above. We saw this as one of the only reasonable solutions to having wildlife as well as an enemy obstacle in the mountains. However that was before we started to think about the potential it would have, if we switched to goat in favor of a ram.

Further down in Tale of Omni’s development we want the game to work as a meta-commentary on video-games and technology in general, which is why we found it hilarious that Omni potentially could encounter a ram instead of a goat. It just made a lot of sense in relation to our meta-game.

RAM is an acronym for Random Access Memory, a necessary part of any computer’s functionality. The ability to reference this little piece of important hardware was practically a gift wrapped for us. In addition to all of this we thought that a ram would function as more of an obstacle for Omni.

As I slowly developed the redesign from a goat to a ram, I began to learn about the fact, that enemies within games need visual cues for the player to have an idea about what to do. At least that is what I like in a game, the alternative seems rather unfair honestly.

My first iteration of the ram looked like this:

It seemed a little too on the nose, that this creature was an enemy, so I worked on making this fact a little more discrete. Gone were the fiery red eyes and serious glare, instead the end result was giving the ram a strong front section, a less menacing look and a slim down in a few places. I think the result is pretty neat:

If my team accepts this design, it will soon be animated either in Aseprite or Spine. You’ll hear from me when that happens, dear reader.

Sincerely,

The Artist.

[taleofomni]

A New Challenger! The Current Situation and Development Process

In today's blog post I will try to formulate the current challenges of the Tale of Omni game development process as well as develop an overview of its general state. I will start up introducing our fourth, newest member of team, the Oracle, who will be our QA and UR manager, then continue through an explanation of the reasoning behind the need of the role, and how this ties into our present challenge.

Good News Everyone!

Being the originator of the project as well as the person on the team wearing the most hats (read: roles), I am doing a lot of work. That is not, I believe, unique to this project at all. I believe the situation is similar in a lot of indie teams: We want to keep the team small, therefore we cannot limit ourselves to singular roles. We need to keep our team small, both because there is no money in the project, and because more people can generate more trouble. I personally have to trust every single person, and every single person; the Artist, the Bard, and now the Oracle, need to be ready to work on this game out of pure passion, because being part of the project is all I have to offer.

As the Artist has touched upon before, we started out being just the two of us, and then some short while later included the Bard as well. Since then we have been us three, with the Artist helping out with the art of the game, the Bard helping out with the story (and planned to make the music), and myself trying to bind it all together as programmer, designer, director, animator, and pretty much any role I need to be (at our meetings both the Artist and the Bard shapes my work as well - I might be the "boss", but I try to listen to their thoughts and ideas as well. They are both functioning beyond there roles).

I do not mind having a lot of roles. Actually I quite like it, as it helps me make everything come together without me always having to wait for someone to make an asset for me or something like that. It surely has some drawbacks too, but it is a way to work - especially while the project is passion driven.

However. Some roles I cannot and should not take upon myself being so very close to the project. One such role is quality assurance (QA) and user research (UR), even though it is the role I am working as during my semester at DADIU. I am simply too invested to ensure that any test of Tale of Omni would be properly detached and objective. It is still good that I know about QA and UR and the processes of it, since it allows me to better understand the needs of my QA and UR manager, but I should not do the tests myself.

Luckily, I know a guy. A guy who is also doing QA and UR at DADIU this semester. A guy who is even one of two lead QA and UR managers between us. A guy who takes interest in Tale of Omni and who wishes to help us in our endeavor. He is now our fourth team member, and he is known as the Oracle.

Why Do We Need This Guy ^

As you may understand from what you have read so far, it is not a light decision for me (or for us as a team) to bring on another member. I do believe bringing on the Oracle will pay of many times in the long run, as Tale of Omni plays around with a lot innovative and unique game mechanics. It is important we get to know what works for the future players of the game and what does not. It is important that we know which darlings to kill and which to take care of. But bringing on the Oracle has also been a leap of faith. While our education (we are from the same study) does revolve around user testing, neither of us have had experience with QA before DADIU. Should he decide that QA is not what he want to do - well, then we are back at being three (or we need him to fill out some other role).

I shared on Twitter when the Oracle joined the team, and it was well before we started our journey on DADIU. This is because we wanted the Oracle to become familiar with the project, as he needs to understand the project to properly test it. He has been part of our meetings since then and will continue to be so in our future meetings - but this is also where we begin to run into the challenges we are currently facing.

I see three immediate challenges: We are four on the team now, we are split up across the country and we are more busy than ever.

Regarding us being four team members: This is probably the least of our problems. While more team members equals more management and more opinions, the Oracle will probably not be very vocal in the design and development process (save his role as QA and UR manager of course), as it would be bad for him to get too invested in the individual features of the game, as it would make it harder for him to test them objectively.

Regarding us being split up across the country: While Denmark is not a large country, it is still a disadvantage for us to not be able to sit physically together, and to generally not be within proximity of each other. With the Artist and the Oracle on Sealand and the Bard and I on Jutland (but not in the same city most of the time), we will have to do our meetings online. To add to that a lot of our work flow outside of the meetings consists of sparring with each other. I would oftentimes sit and work with the Artist on the graphics or talk with the Bard about the world and story of Tale of Omni. This is still doable online, but it is not optimal.

Lastly, regarding us being more busy than ever: This is probably my biggest concern as team leader. First and foremost it worsens the previously described challenges: It becomes harder to manage the team and it makes it harder to plan meetings and sparring. It also, quite frankly, makes it harder for us to find time to work on the game. Progress is slower and it was not exactly rapid before.

While I kind of has found my own solution (I have a good 1½ train ride to and from "work" at DADIU, I try to put in some work during this commute time), I do not know if the others can manage to find time. I can hope, but we are all busy. The Artist, the Oracle and I working full hours at DADIU, and the Bard continuing his study. As I said: The Oracle is QA lead and has some extra responsibilities on top of doing the same job as me. I know I am busy, meaning I am plenty sure he is too. The Artist is testing his skills as a project manager, and I know this is an intensive role as well and probably quite the challenge. I am not too sure how much time the Bard has on his hands, but I know we need the meetings to properly iterate on the work he is doing, and however much he want to work, he can only develop the story so much between meetings, as we need to validate the work.

To Summarize

We are busy but happy - and growing ever so slightly. We have plenty of immediate challenges but the adventure is not at a halt - just slowed down while we adapt. I am sure we will get used to our new, busy, daily routines. Others before us have made games on the side with full time jobs, and so can we. We will keep you all updated as we progress through our obstacles.

Sincerely, The Architect

[taleofomni]

The Sound of a Tale

This week i will discuss the game “Undertale” by Toby Fox. My sound-design observations and discussion of these will not contain spoilers for anything related to the story, so you can read on safely, if you not played the game yet.

A while ago the Architect and I attempted to play through the game Undertale together, but we never got around to actually beating it (due to not finding the time to actually do it together). As i remember though we were both struck by the amount of love put in to the characters and how satisfying the quirkiness of everything was. Multiple times throughout the development of Tale of Omni we referred to Undertale as one of our reference points for what we would like to achieve - this mix between character driven storytelling and puzzle/adventure gameplay. The Architect decided that everyone on the development team should play the game on their own, so we could discuss it, but i somehow managed to postpone it until now. What a shame. Playing through the first half of the game for a second time i realised that it is a very different game from the one we are building. The quirky tone of Undertale is fantastic, but it is so unique in its expressions that trying to assimilate this can almost only go wrong. With my focus being storytelling and sound design it was really some of the more formal aspects of the interaction between the two which stuck out to me. A simple thing which Undertale takes huge advantage of is the use of “character themes”. Not only do places or situations have theme-songs, but central characters have these as well. Blatantly representing characters in musical form was - at least to me - very effective in focusing the mood of the encounters. I’m not sure whether this is a viable tool for Tale of Omni, but it is really interesting how themes can underline traits and add depth to characters. Place or situation specific themes are the norm, but extending this to the specific character seems to me, a very powerful tool if used right. The danger I could see in this is that it adds a certain intimacy to the players relation to the specific character, which is not always wanted. It may simply be more fitting to certain characters than others. Furthermore the theme-songs are often cut to emphasise moments of uncertainty, so only silence and the “voice” of the characters text-box can be heard. Different characters have different “voices” by having a unique sound-bite played in loop, whenever their speech is displayed in the text boxes. Here i found it not to be the sounds themselves which were important, but the way in which they underlined the pace of the “spoken” words. With Undertale’s great character-focus, pace of speech becomes a way of expressing feelings. Obviously it is not only the words we say which matter, but also the way we say them. It is amazing to me, how these monotonous “bleep” and “meep” sounds can liven up the use of text-boxes. Undertale surely isn’t the first game to have this (it didn’t invent character themes either, of course), but the quite lo fi sounds aesthetic pushes the “voices” to an extreme where i find it oddly powerful. The sounds used for these voices are scarce in content, it is not the sound of mumbling, but more like constant morse-code either firing away at you or dripping, drop by drop, with a specific tone of emotionality. We haven’t really worked out how the sound aesthetic of Tale of Omni will be, but it being a pixel-art game, it of course suggests the use of 8-bit sounds. We will not limit ourselves to 8-bit sound, but these “voices” really seem an appealing place to use 8-bit’ish sounds. Again we will have to see if we can make them fit the characters we are developing. A last interesting thing i noticed when playing the game was how the player is givin influence on the music at certain stages. For instance in Tyriel’s house there is a lamp, which you can turn on/off whereby you change the playing theme-song’s instrumentation and thereby mood.

It is of course not the power to change music itself which is interesting, but the way in which this can enhance the connection between game-world and soundtrack. Being a bit cynical one could say that it is not sensical that there is music playing everywhere you go in a game, yet some places it can make logical sense. Reducing game music to being perfectly logical is of course a bit ridiculous, but anchoring the music in the game world may actually be really interesting in regards to world interaction. Especially if the player can affect the music, not just by entering battle, etc., but by wilfully interacting with it. I do not quite see the potential use for this in Tale of Omni, yet just having this on a “gimmick level” like Undertale has it, could prove quite interesting in a world like Omni’s. A plausible integration of this dimension in Tale of Omni, could be the music’s effect on certain puzzle elements, where this would make sense in connection to the game world. To me Undertale is a great game for showing the effectiveness of quite simple uses of sound design to enhance the storytelling and character focus. I Definitely have to test these in the context of Tale of Omni!

That is all from me this time. It has been a pleasure playing Undertale, and i apologise to the team for delaying our discussion of it this much! Sincerely, The Bard

[taleofomni]

Graphical (re-)evaluation (pt. 2): Now it’s personal

Greetings everyone!

I am the Artist of the Tale of Omni game here to tell you about, one of the things that drives me forward the most: Experiencing my creations change drastically over time and looking back on previous iterations. 

Tale of Omni has been in development for a while now, years actually, and as time passes, we in the development team as well as the game we’re working on change simultaneously in a variety of ways. All sorts of interesting events are happening in our lives as we develop the game and they undoubtedly affect us and the way we act. Among many things we’ve become more enthusiastic, wise and skilled through the years. As I’ve mentioned in a previous blog post, when we began working on the game, the team only consisted of me, the Artist, and my comrade, the Architect. We met at Aarhus University and developed a great friendship. Back then we noticed a lot of similarities in each other: We were both huge nerds, had a passion for drawing and a very identical cartoony humour.  When the Architect months later would present me to his unique vision for the Tale of Omni game (originally called “Omni”), I jumped on board without any further hesitation. It just sounded like an insane amount of fun (and it still is). The Architect offered me the role in which I were to develop a lot the graphics for the game, which may originate from the fact that he noticed my distinct cartoony artstyle, when I sometimes doodled in class (sue me). In Tale of Omni’s infancy I only drew on paper and had plenty of experience from my early youth drawing in MS Paint (R.I.P). I had come across pixelart while playing on my Gameboy way back when - but never actually created pieces within this artform. All of this meant that early iterations of the graphics I made looked like this:

Furthor down the development-road I would learn the importance of the colorpalette, as well as using highlights and shadows sparingly to create a sense of depth within the piece, which hopefully can be seen in the GIF in the beginning of this article. 

As the Architect and I were the only two developers back then, we thought it would be hilarious and meta if Omni were to meet us on his journey within the game. Together we came up with the design of the Artist and the Architect, which was to be this enormous, hulking, ogre-like beast:

To show that we were united but different, we wore a pullover, two different colored shirts sown together and two different ties. I would change the character a lot since early 2016, when the first iteration was made. 

“What if the Artist wore an apron with color stains on?”: 

  “We might be a little too different now. But what if we wore the same shirt and ties?”:

“You know what? Screw the pullover and the apron. I’ll make this character more united than ever!”:

As of now the Artist and the Architect is wearing the same shirt, the same tie and the color stains remain. I think we will run with this iteration, however just as we constantly experience change within the development team, the characters within the game change too. This may not be the final iteration. Who knows? I’ll undoubtedly keep you posted.

Sincerely,

The Artist.

[taleofomni]

Inspiring Finland

Hello all!

I am the Architect, here to tell you about my vacation with my girlfriend, my sister and my sister's boyfriend visiting my brother and my brother's girlfriend in Helsinki, Finland.

...

What? Of course my vacation is Tale of Omni-related! Whilst I did not make anything on the game throughout my trip to Helsinki, Omni never truly left my mind, and a lot of my trip ended up as inspiration for the game. We all need fuel, and I believe inspiration is a fascinating topic!

Flight of Patterns

Kicking off the vacation, first I had to get to Helsinki. The traveling was done by plane, and it was a 1½ hour flight. I did not sit by the window, so inspiration was less composed of beautiful vistas, and more so of the book I brought with me on this trip: Game Programming Patterns by Robert Nystrom. I read some of the book both going to and from Helsinki, but I only made it through the first part of the book, which is kind of a recap of some patterns from Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Nonetheless it was well written and had me reflect upon my own code and how to improve aspects of it. I am looking forward to read the rest of the book, and I look forward to implement these new ideas.

One of these ideas was the use of observer objects to keep track of different things, such as achievements (as the book exemplifies). Especially in the case of our quest log system this approach can be giving. This pattern also mixes quite well with my trigger system, as the broadcasting functions can be used to pick up on specific events happening.

Another idea is the use of prototype objects. I have been using a similar pattern for a while, which I named "sibling objects", but in the chapter about prototypes (chapter 5) it was made clear for me, how I could improve on it, and how giving it could be to, for example, use a prototype object for both the player and AI controlled objects, and then combine this with the use of a state machine. In relation to this, the book also supplied some more tips and tricks concerning the use of states, which made me want to use them more.

There were a couple of more things I picked up from the book, and I believe I can learn tons from it. If you are interested in me going in-depth with what I read or the systems I develop for Tale of Omni, feel free to let me know on Twitter. You can write either @BlessHayGaming or @TaleofOmni - I am the one managing both accounts, so if you write, I am the one responding.

Anyway, that was the flight covered, lots happened at Helsinki as well:

Helsinki's Nature

We arrived pretty late on Saturday, ate pizza at the airport, and then went to our Airbnb and slept. Sunday we went to my brother's place, and then went for a walk in a large park. There is nature everywhere in Helsinki, all around the city. Lot's of actual parks too, and we went to one of the largest we could find nearby: "Månsasparken".

After walking for a while all six of us, following the main roads, my brother and his girlfriend had to go, and the rest of us chose to follow a smaller, cliffy path instead.

This detour led us to some beautiful sights with mountainy ground, and this whole mix of mountain grounds and nature inspire me in relation to the beginning of Tale of Omni, where you are on a mountain - I want to inject more nature into it: Bushes, trees, tufts.. And also rocky overlays, to break up some of the repeating tile sets.

We also found a small, old camp fire area hidden between some rocks, which I will draw upon when designing some fireplaces around the world, for the royal soldiers coming for Omni.

Lastly I found a good cliff wall to inspire some of the textures in the game:

It is some very generic findings, but it is sights that relate to the area we are currently designing, and we cannot find cliffs like these in Denmark. I am well aware that these are not exact mountains, but it can still inspire the feel of the place.

Tourists

Even though my brother has been living in Finland for around half a year now, this was my first trip to Finland ever. This meant that we spend a lot of time being tourists and taking in the city of Helsinki. In one of the souvenir shops we entered, I found a row of stone face figures. I am not sure if they are going to fit Tale of Omni, but I found them cool looking, and will keep them ready as inspirational material. In the world of Tale of Omni a lot of the environment will hint at a rich history, and they could inspire some fun stories..

Not everything inspiring will be of direct use - but I believe it is better to find a lot of inspiration and distill it, rather than working from a limited set of materials.

We were also at the Suomenlinna fortress, which was also a very much inspiring trip. In the latter part of Tale of Omni he arrives at the Queen's castle, and I believe a fortress is great inspiration for this area. Partly Omni has to sneak into the castle, and this fortress has a lot of dark, dark hallways and rooms..

Also, as you close in at the castle, you will come up against mechs, and a look inside a sub-marine may supply us with a nice, steam-punk-y, feel for them:

I also found some cool decorations around a church composed of huge chains, and I believe this could look cool in Tale of Omni as well.

And lastly, I found a gravestone, which just looked great, and which I might use in relation to Omni's parental figure, and which sparked some ideas which we have already discussed at one of our team meetings back in Denmark.

Now, I have shown a lot of images, trying to cover the inspirational sights, but these hardly scratch the surface. Not everything will be used, and the inspiration will properly be a looming factor, and not a direct "then this lead to this, and this became that". I do believe, however, that the sights and impressions will have an impact on the game, and having read this blog post, maybe you will be able to spot some of these.

Either way I hope you enjoyed this write. I will go work on the game now, whilst the inspiration lasts.

Kind regards, The Architect

[taleofomni]

Lets try a scoop of Vanilla WoW sound design!

As the first entry in my sound-design-examination series I will have a look at the Vanilla version of World of Warcraft. In order to talk about the sound design however, I will have to discuss my history with the game and also my experience of the game design. Lets start with the history…

I never played much World of Warcraft, when it released. I was fascinated by it and I did buy the vanilla version, but I never got around to buying even the first expansion pack. I think I made it to about level 34, but the grind and the amount of money it cost (I was 11 years old at the time) really killed it for me. Recently though, one of my flat-mates showed me one of the vanilla private servers out there and after interesting discussions about what the strengths and weaknesses of the game, he got me hooked on revisiting it and examining what this whole game-historic movement had been about. Still I have only played it very casually (now level 27 over a period of 2 months), so my opinion on the game as a whole is still not perfectly founded, but my focus today lies on one of the core concepts of WoW, which is present from the very beginning: WoW’s attempt to bridge the gap between “roleplaying” and “game” on the big scale. So what to I mean by this? The thing that amazed me about WoW as a kid was the world. The size of it, the many faces it had with all its colourful zones and the lure of adventure to be had with all the others engaging this world. This appeal of WoW I like to call the “roleplaying” dimension of the game. The term may be a bit of a stretch to apply comparing Vanilla WoW to more pure forms of roleplaying, but I am aiming for that feeling of world depth that it had. This feeling of course is prone to change with a more adult perspective, intellectualising the world of WoW quickly makes you see that a world could never function like this - for example, the amount of monsters in the woods, wouldn’t allow townships like Goldshire (given its very small size) to work properly on its own. With this, the game of course makes space for the gameplay, letting Goldshire only be a symbol of a township, for us to engage with. The focus of WoW-gameplay then, is the gear and the abilities your class brings to the fight, so apart from different professions (indirectly aiding you in your fight) and questing to make yourself stronger, you have the fighting itself as the core gameplay. This is what I tried to define as the “game” aspect of WoW before: the gameplay focus becoming stronger and putting you against somebody else, it either being a NPC or an actual player. Returning to Vanilla WoW, this “game” aspect of WoW, seems to have become very prevalent over time. The knowledge about the game has grown massively: every class, talent-spec and item-combination has been number crunched and people know what the best combinations are. You can find guides to every quest and every play style: it has been done before, there is a step by step guide for how to do it. This makes it hard to feel like there are still mysteries out there. Blizzard has of course challenged the crunching and de-mystification by releasing new content, but going back to vanilla specifically, I can feel that many players are very “game”-driven - focusing on efficiency, pre-chosen talent-trees and items. You may say that WoW is setup to be a very “game”-driven game - the grind being just a repetition based around numbers growing - but it never was this alone, without the world-depth, size and intriguing aesthetics, WoW would never have pulled in so many people. The interesting thing to me is that coming back to vanilla, even with all the knowledge out there (and me using some of that knowledge (to not be a total n0000b)) I was able to engage with the “roleplaying” aspect of the game - and this was via the music. Nostalgia is a big factor here, which wow player (however short a time he spent in Azeroth) doesn’t know how this sounds?

Apart from the nostalgia WoW is quite interesting sound design wise because it is easy to judge it as very limited in scope, from a contemporary technical standpoint. For example the horns in the Ironforge theme sound very synthesised (according to wowwiki, the whole soundtrack is synthesized, apart from vocals), the same sounds are being used for different monsters (gnolls and ghouls are one example) and professions have 2, max 3 sounds used upon product completion. The upside of these limitations are that they in part emphasise character, over technical “quality”, but also tie into the gameplay-experience - the vanilla experience prides in being a grind. This however wouldn’t work if the “crafting” sounds were actually terrible or the music scores didn’t have some kind of beauty to it. A main aspect of making it work I find to be hidden in the standard settings for music in the game when you launch it.

First off the music volume is set to be lower than the ambience (being place specific ambience tracks) and sound (everything related to player or in game objects, campfires for instance) volumes. Secondly the function of looping the music is disabled. This means that everything related to the player character and immediate environment is prioritised, then comes the ambience “glue” and then, coming in last, is the soundtrack itself. The soundtrack is downplayed even more by only playing once in a while, but this is where the fascinating thing happens: to my experience this “once in a while” makes the zone specific soundtracks extra effective. I experienced multiple times how the sudden reappearance of the soundtrack, “picked me back up”, placing me back in the world, after drifting off into the game grind and quest planning. The “emptiness” of only having “sound” and “ambience” tracks for a while gives the game space to just be a game, but then the music fades back in, and you are seduced back into the “world” and “roleplaying” aspect of the game. I must admit that it never got me to the point where I really felt like my quests actually meant something to the world, but the aesthetic beauty that I experienced in the meeting of visual aesthetics and music is a great part of what has ultimately kept me playing (the fun it can be to play with my friends of course being the other major factor).

Storytelling wise the sound-design doesn’t really do that much and to be completely honest Vanilla WoWs mechanics for storytelling are not that engaging and often fall short to the desire to level up. This maybe is where I tend to dream of the potential WoWs storytelling could have had, with the game appealing to such audiences as it did (hopefully I'm still in for a treat with end-game or later expansion storytelling!). My main take from WoW’s sound design, which I think can help in the development of Tale of Omni (ToO) and our soundtrack, is the power of soundtrack scarcity and subtlety. It probably differs quite a lot how much the game-soundtrack influences peoples game-experience, but me being sensitive to it, I had quite extreme experiences when turning off all in-game sound: suddenly it was all about efficiency, crossing things off on my in-game bucket list, not caring about the calm of being embedded in a game world. I want ToO to channel this “calm” at times, but with being a much more story-focused game than WoW, it also has to push for more integration between story and sound. The player centric sound priority is a powerful move on WoW’s behalf, given its player (vs. player) focus, and maybe ToO can profit from such a prioritisation, given that the focus is skewed towards in-game interactions and puzzle-clues.

This got way too long, but I feel like the WoW has made me realise the importance of “World depth” and how much sound-priority really means working towards it. I hope it has given you something to think about! If not only some nostalgic memories ;-)

Sincerely, The Bard

[taleofomni]

The Bard has joined the party! (physically)

For a rather short while Tale of Omni was a project done in a pair. The Architect and I, The Artist, was to make the whole thing a reality together. However that was before The Bard joined our common efforts. We would soon realise how much of an indispensable asset, he would become to our team.

This two-headed giant representing The Architect and I was in Tale of Omni’s infancy supposed to be “the guy behind it all”. Essentially a god in Omni’s world. In his journey Omni would meet this creature and all sorts of meta-humor and commentary would ensue.

Game development is like clockwork, it takes the right gears to get everything moving. The Architect and I realised that there was so much to be done, that doing it in pair would risk having Tale of Omni being finished after the creation of hovering cars. Developing a game can be done alone and in a pair but doing so can create all sorts of hassles. We needed more gears!

After discovering what great potential The Bard had, we realised that he meant a great deal in the creation of the game. You can read about this in The Bard’s introduction. He needed his own avatar in the game. In real life we, the team behind Tale of Omni, are currently like the three musketeers from Alexandre Dumas famous literary work of the same name. It was therefore fitting that the previously mentioned two-headed giant needed an ally within the game.

I created the physical manifestation of The Bard with inspiration taken from his real life counterpart. Due to his german and musical roots I gave his avatar a suitable pair of lederhosen and a neat pan flute. The result is currently looking like this:       

As for all interactive characters in Tale of Omni he got himself a suiting portrait as well. In its current state it looks like this:

Having your friendship and teamwork cross the boundaries of reality as it becomes part of a fictionary world is a great experience. 

Sincerely,

The Artist.