View source for Riding the Waves: A Workflow Tip Guide

On this page you will find a bunch of tips on how you can '''potentially improve''' your workflow. Just in case any of you don't already know what workflow is, it is the '''efficiency''' of how you work, which can summed up as so...
<hr>
▫️ How '''long''' does it take you to perform specific tasks?
▫️ How '''consistent''' is the time it takes you to perform said tasks?
▫️ How '''much''' work is involved in performing said tasks?
<hr>
Now that you know what workflow entails, is there anything you could do to '''increase the efficiency''' of your workflow that will help you '''decrease the time''' it takes you to perform tasks while '''reducing the amount of work''' involved in finishing the tasks? The answer to that is '''yes''', but it may take you some time to figure out what workflow works best for you, as everyone is different & there's no one-size-fits-all solution.

Anyway, let's crack on...
<hr>
{| class="ts"
|-
| ''Quick note: I just want to point out that this tip guide isn't really a tutorial, just think of it as a sort of text based Ted Talk. My goal here is to give you an idea of my workflow & why I work the way I do, & not to tell you how you should work, but instead hopefully provide you with some ideas on how you can potentially improve your own workflow. In the end, however you choose to work is entirely up to you.''
|}


== Always Make a Plan ==

I'm not saying that you have to type up a 1000+ page in-depth document detailing every single little thing to do with your game, but ideally you should come up with some kind of plan, even if it's just some daily or weekly tasks that you want to work on.
<hr>
{| class="ts"
|-
| ''Quick note: Any kind of plan is better than no plan, because no plan leads to chaos, which leads to an inefficient workflow, which often leads to frustration, a lack of focus, & eventually a decline in overall motivation to work on your projects. Trust me, chaos is a project killer.''
|}
<hr>
Here's a few methods you can use for planning out your projects & time sensitive tasks...

=== Game Design Document ===

The game design document (GDD) is usually a large document that would typically be created to share with other members of your project team as a guideline of what your game is about, which includes: a general summary of the story-line, the game mechanics, puzzle designs, character bios, location information, etc. etc. Game design documents can also be used for pitching your game to potential game publishers in the hopes of getting funds to create the game of your dreams.
<hr>
{| class="ts"
|-
| ''Quick note: Instead of a written up document, you might want to look into applications like articy:draft, which allow you to create professional looking in-depth interactive game design documents via templates, nodes, scripts, & visual layouts. The application takes some time to learn & master, but if you have access to a laptop & a projector or large screen then this could potentially be used to wow some potential publishers. The other benefit to articy:draft is that some game engines will let you import data directly from articy:draft into your projects - unfortunately Visionaire Studio doesn't support this feature.''
|}

=== Mind Mapping ===

Mind mapping, cloud mapping, thought mapping, you can call this whatever you like. This involves using a piece of paper or a whiteboard/blackboard or an application like [https://www.yworks.com/products/yed yEd] to create flow charts. Flow charts work really well for puzzle design, dialogs, & figuring out what events, locations, etc. are connected to each other.

[[File:mm_example.png|800px]]

=== Sticky Notes ===

They are kind of messy, but if you are a messy kind of person you will probably love scribbling on these & sticking them all around the edge of your monitor & wherever there's a bit of empty space on your desk &/or walls. They are mostly useful as reminders if you don't have the best of memory like me. I don't personally use them myself as I prefer to keep desk & work area as clutter & distraction free as possible as it helps keep me focused on whatever I'm doing.

=== Tasks & Goals ===

Jot down some goals for the day, week, or month on a notepad, in a text document, or use one of those online project planning websites - there's plenty of free ones available. It doesn't matter what you choose to use, just that you have some sort of plan, because if you are jumping around doing little bits here & there instead of working on something & finishing it then moving onto the next thing you will find that you will probably have a hard time keeping track of everything that you have done.
<hr>
{| class="ts"
|-
| ''Quick note: I even created a small text document with a list of some of the topics that I wanted to cover on this wiki page, however as per usual I often end up thinking of additional things I want to cover after I've started typing up the page, but that's ok as inspiration sometimes comes from doing instead of thinking.''
|}


== A State of Mind ==

Never force yourself to work if you aren't in right frame of mind, unless you have no choice due to a deadline that can't be adjusted. Why? Because forcing ourselves to do something when we aren't in the right state of mind, or when we have no energy or patience will often lead to sub-par work quality, frustration, & mistakes, which is often due to a lack of being able to properly focus on what we are trying to do. Forcing yourself to do things will eventually lead to a lack of motivation & it also kills inspiration & leads to procrastination - I'm the master of procrastinating, so I know what I'm talking about; don't believe me? Check out the tv tracker website I use... ''actually don't as I don't need you lot knowing what I've been watching.''

Make sure you take regular breaks - jot down whatever you were doing so that you don't forget what you were working on when you come back from your break. Go grab a drink, a snack, do some exercise, or watch a bit of tv or something - but nothing that will stress you out. Keep it simple.

If you mostly work by yourself, try listening to music while you work - nothing too energetic or loud, as you still need to focus. I find that listening to music helps set a rhythm for when I'm working & prevents me from getting bored while I'm typing out code or doing other things that are equally repetitive. Game development can be quite boring as it involves a lot of repetitive work.

Try mixing things up a bit. You don't have to finish each task in order, however make sure you jot down your progress so that you don't have to comb through your project later on to figure out where you got to with each task.

Finally, make sure your desk & work environment is as clean & tidy as possible. I find that when my desk is full of clutter & distractions that it reduces my focus on what I'm doing. If you don't live by yourself, try to find a quiet place out of the way if you can as a noisy environment can be very distracting, which leads me my next suggestion. Consider investing in a decent pair of noise cancelling or over-ear headphones as they will help you focus by removing background noise & will work even better if you play a bit of relaxing music into them while you work. My last suggestion is in regards to notifications. Make sure you enable do not disturb mode & disable/turn off all notifications (visual & sound) on your various devices. Also try to curb your instinct to constantly check your emails & messages while you are working. A distraction is distraction no matter which way you look at it, & it's '''counter-productive''' to maintaining an '''efficient''' workflow.


== Naming Convention and Folder Structure ==

When it comes to naming convention & folder structure I like to keep things as simple, yet as organized as possible because good naming convention & folder structure helps keep things organized for you, your project team members, & any potential third party freelancers that you might need to hire further down the line.

=== Folder Structure ===

My preferred folder structure is something along the lines of this...
<hr>
* root
** data
*** characters
**** playable
***** animations
**** npc
***** animations
*** cursors
*** interfaces
*** scenes (background image, reference image, & static images)
**** animations
*** sounds
**** general
**** scene_name
*** videos
*** etc.

=== Naming Convention ===

Here's a list of some of the naming conventions that I tend to use...
<hr>
* interactive scene object: obj_
* point of interest: poi_
* non-interactive animation: anim_
* non-interactive image: img_
* object that can be added to inventory: itm_
<hr>
I also tend to add a prefix to scene names, which I also tend to include in the names of called by other actions, conditons, values, & animations that were created in the same scene, & it looks like this: '''101_example'''. It can simply be broken down like this, chapter/episode 1, scene 01. The reason I like to include the name in conditions, values, animations, & called by other actions is so that I can use the same names throughout the project without having to worry about conflicting names when I try to access them globally via script later on. It's just something I do to save time by not having to direct link to the full path of the thing I want to access/manipulate via script.


== Editor versus Scripting ==

A lot of you are probably going to be '''facepalming''' right now, as most of you that know me (AFRLme) know that I am very script heavy when I provide answers on the forum & Discord server. The reason I prefer scripting over action parts is because for me it's much faster & easier for me to type than it is to drag the mouse cursor all around the Visionaire Studio editor clicking on this & that - for me it's that simple, it's faster & easier.

I'm not saying that you should all switch to scripting, but scripting is so much faster if you are willing to learn it. Why? Because something that you create in the editor might require a 100 action parts, but might only require a line of code, or a few lines of code at most.

Having said that, I am not averse to using action parts, I do still use them when they are easier & faster than doing something with script. I also like to mix & match action parts with scripting via '''execute a script''' & '''if lua result''' action parts.

A quick example of when action parts can be faster than scripting would be simple condition/value based queries where you only need to query a single thing. If you need to query multiple things or perform complicated queries that involve the '''and''' or '''or''' query operators then you should consider using the '''if lua result''' action part as that is what that action part is for, but it does require scripting knowledge to use.

In other words it's all about figuring out what works best for each situation & not being afraid to get your hands dirty, experiment, & learn new things. If you aren't willing to do that, then enjoy working at the speed of '''sloth''' on all your projects.


== Conditions versus Values ==

When it comes to conditions & values, conditions are very simple to use compared to values as they only have two states, which are <span class="green">true</span> & <span class="red">false</span>, however that doesn't mean that they are efficient workflow wise.

I tend to work with values a lot more than conditions, & the reason behind that is because they are excellent at dealing with multi-state situations because they have multiple operators types you can query. This means that you can create a single value & assign it to multiple scene objects & use the different available query operators to control how the value affects each scene object.
<hr>
{| class="ts"
|-
| ''Quick note: By assigning a condition or a value to the properties section of scene objects & interface buttons, you can control when the object or button will be visible (active) or hidden (inactive).''
|}
<hr>
Here's a quick example of defining language via conditions & values...

=== Condition Example ===

 change condition "language_is_English" to true
 change condition "language_is_German" to false
 change condition "language_is_French" to false
 etc...

=== Value Example ===
 value "v_lang" = 1
<hr>
As you can see values are much faster as there's much less work involved.


== Animations ==

When it comes to animations I tend to save a lot of time by using various tricks I've learned over the years to control animations, such as using script to scale them up or down, rotate them, move them about the screen, control the animation frame range, control the playback direction, & many other things. I'm not going to list them all here as I've already written up a tips & tricks guide for animations, which you can find [[Animation_Tips_and_Tricks|here]].


== Resources ==
{| class="ts"
|-
! style="text-align:left" | Name !! style="text-align:left" | Description
|-
| N/A || Project file & resources are not available''.
|}{{toc}}