Get the latest Education e-news
 
  • A Comprehensive Guide To Successful University Group Projects

    [05.10.18]
    - Luke Haslett

  • Engine Etiquette

    If the scripting for your game is likely to be accessed by multiple people, it's really important to keep a professional approach by applying some organisation protocol. Doing so will increase the efficiency of how the scripts are read and maintained.


    For visual scripting, you need to ensure that graphs are consistent, readable, and able to be navigated without confusion. The following image shows a screenshot example of some UE4 blueprint I scripted for a recent project:

    From that, here are some things to note:

    • Commented backdrop to separate the script from other events in the graph.
    • Header title to provide a quick overview of what this script handles.
    • Tinted background colour that's divisive but not distracting.
    • Node connections are straightened, re-routed, and have extra space to refrain from too much graphical overlap.

    When using an engine editor, anytime there is a hierarchy of content you should be setting up suitable naming conventions for folders and files. These names should ideally be stylised in one of the following ways:

    • Camel Case

    This is a style that contains no intervening spaces or punctuation in phrases, and instead capitalises the first letter of each word (e.g. RuinsIndoorFoliage).

    • Abbreviation

    This is similar to how the C standard library abbreviates commonly used words (e.g. "charloc" for "character location").

    • Underscoring

    This is like how the C++ standard library highlights word separation with the use of an underscore (e.g. Forest_Ruins_Winter).

    The above are just examples of conventions that I've adopted and practiced, you may have your own, but the important thing to take away is that your tech team are using the same programming style. If it helps, you can write a style guide to ensure the same principles are adhered to.

    Here's some examples of well-known style guides:

    Microsoft's C# Coding Conventions.

    Google's C++ Style Guide.

    Code Ownership

    If everyone has access to everyone else's code, it can quickly descend into a nightmare when different people are making alterations to the same script. So, it's a good idea to implement an ownership system.

    Divide exclusive responsibility of entire scripts to individual members of your tech team, and set a rule that only that person can modify the code. If someone needs access to something in that code, request that it be made available via a public function that returns the information. Then, have a master build that people only overwrite their owned files on.

    Also, look at using managers for everything. They're very useful for listening to relevant scripts, and handling information to be stored and accessed elsewhere.

    Alternatively, dedicate a person to be the ‘Code Steward' and oversee the master build. It can be this person's responsibility to review replacement files for inconsistencies, and implement them into the live project.

    Version Control

    Also known as ‘source control', this is a software management system that handles tracking all changes across a project build. It saves iterative states of the project to protect the assets from being lost due to an error, human or otherwise.

    Because of this tracking, using version control allows for multiple copies of the same project to be distributed across the team for everyone to work on their tasks simultaneously. It can then merge selected changes from across multiple versions to create a new build with these changes applied.

    Here are some popular source control platforms to further research:

    Git.

    Perforce.

    Subversion (SVN).

    Concurrent Versions System (CVS).

    Changelogs

    If you decide to save time and have an open mind about ownership, where scripts are available for everyone to modify, and/or you choose to merge your team's project's manually, then make sure that all the tech team are keeping their changes recorded.

    You will definitely want to have a dedicated code steward that handles the merging in this case, and to make their role more efficient you all need to be noting down a list of changes.

    Consider tracking the following information:

    • The file path of the file or folder, whether it's new, modified, or moved.
    • The name of the affected files/folders.
    • What contents of the file was removed, added, modified, or moved.
    • Short description on the actions taken.

    Giving this changelog to your code steward, with the associated build, will be a much more efficient process as it takes you less time to make your notes than it does for the code steward to trawl through everyone's code.

    Build Often

    Once you've hit the first milestone deadline for your project, you should have a playable version of your game. Now I recommend that you build often, probably at least once a week. This gives you a good chance to identify and deal with any errors that happen to occur.

    I've made the mistake of leaving it until the end, complacent with the thoughts that it should be fine because it's my work. This is wrong. Don't do it.

    Approaches to Art

    For this header I want to note that I am not an artist, and am not familiar with the processes that students on the art-side are taught because all my modules were split between design and tech. I do, however, have a talent for observation, and could listen to and communicate with the artists in my projects. Therefore, this section will concentrate more on my opinions on what I saw.

    Establishing a Pipeline

    You should begin the project by having a discussion in the art team about where you should all slot into during the process of creating and implementing art assets.

    The most successful pipeline that I saw in my groups was set out as the following:

    • Design

    As mentioned previously in the design section, a ‘reference document' would be created as a guide to the aesthetic vision. This would be taken to the concept artist and lead artist to discuss in further detail how it would look to fit our game.

    • Concept

    The concept artist would then draw several versions of the design in rough thumbnails and return these to me and the art lead for further discussion. When we'd agreed on the one we liked, the concept artist would go back and draw it up in greater detail from several perspectives.

    • Creation

    Next, the concept would be modelled by whomever the task belonged to.

    • Asset Review

    The model was then forwarded to the lead artist, who looked over the asset and sent it back to the modeller if any alterations needed doing. When the model is okay, the lead artist would hand-paint the textures.

    • Implementation

    Next, it was myself that would bring the asset into engine and setup the materials, collision, scaling and placement within the level.

    • Polish Pass

    Finally, the lead artist, concept artist and lighting artist would give the asset a glance over in the scene, and give it the all clear if it met the standards we were reaching for.

    This may not be the industry approach, but this method certainly worked best for our project as a small university team. So, I recommend you also look at forming a flow of work that incorporates appropriate decision-making amongst your teammates.

    Asset Limitations

    Know your constraints, and work closely to those restrictions. The larger the project, the more constricting the budget will be for areas like polycount or texture size.

    Make sure you are also creating assets that are suited to the job. For example, if you're making a mobile game then it's probably not going to be wise to throw in 4K textures.

    Understand that restrictions aren't a bad thing, appropriate boundaries allow you to improve your craft as an artist by learning to be creative with the space you've got.

    Likewise, having no limitations can be a bad thing. In a constantly evolving environment like the gaming industry, there simply is no time to be a perfectionist.

    Consistency

    Once an art style has been confirmed, take some time to practice it, because there's nothing more jarring than a game with different styles attached to it.

    This feeds into the idea that, as an artist, you need to be flexible. I once witnessed another group argue with their concept artist because he refused to work to the art style that had been decided. When they asked him what he'd do in this situation in industry, his response was "I'll never work for a company that doesn't match my style". I never saw him again after that day.

    Lighting & Visual Effects

    Having someone on the team with a special aptitude towards the art of lighting or particles can take your game from looking like a student project, to looking like the work of an indie studio.

    If you can afford it, dedicate someone to a full-time role working on these aspects. Even if the person has a basic knowledge, make sure they are researching and practicing as part of their tasked timetable.

    I'm putting weight on this subject because I feel it's the approach to this aesthetic that can truly make or break a game's execution. Especially, if you want to mask the team's lack of design capability.

    Animation

    Unfortunately, I didn't have much luck in getting animators in my groups, so I haven't got much to say about the role and how it fits in. I'm not sure if this is simply my bad luck, or if this is a commentary about a lack of students pursuing animation as a career direction in games. I'll leave that research to you, but from what I saw in most other groups, a talented animator is hard to find.

    Reality Check

    An important point I want to make is that in game development, it's natural for aspects or full features in a project to be cut. This can be due to several reasons; like scope limitations where there's only so much time to polish x-number of levels, or a change in direction that makes more sense to the tone and feel of the design.

    Either way, I've found that artists, in general, are prone to being more sensitive about their work being cut than others. Probably due to their capability of being more emotionally tuned in. But please do not take it as a personal attack, you're still valued and have the work to show for your efforts.

    Here's a quote from Dishonored's Art Director, Sebastien Mitton, when discussing whole levels that were cut from the game:

    "It is always sad when you have to cut features, ideas, concepts. But that's the nature of our role in this industry. As an artist you have to stay really agile and react positively for the sake of the project."

Comments

comments powered by Disqus