Can you be my duck for a second?

Evil Quacks Studios
Sep 11, 2021
6 min read

Hello, Ducklings!

Did you know that our name, Evil Quacks, has a lot of factors to it?

A group of ducks is called a badling. Get it? Bad -> Evil...yea.
Quack is a sound a duck makes but it's also a person who is dishonest about knowledge or skills. While we can assure you we have plenty of knowledge in Game Design, we may or may not have been slightly dishonest about creating EVIL inventions and taking over the world.
Rubber duck debugging is a term used by programmers where they explain their code line by line to a rubber duck. In doing so, it becomes easier to spot faults in logic that would cause errors. Did you know the term comes from a story? The Pragmatic Programmer by Andy Hunt & Dave Thomas

Speaking of programming...

(nailed that transition)

Let's welcome back our System Architect & Lead Programmer, Joseph!

He has been away for a while focusing on his own mental health. He has returned to us ready to continue working and able to join us during our weekly work sessions!

He has already made great progress. Here are some items he completed recently:

Got SQLite to work with Unity
Local queries are executable
Ensured the .dil used will allow for PW-protected DBS
Set up testing to check compatibility with basic JSON IO operations
Allows for local LINQ queries to avoid storing data in controller classes.

Woo! With the addition of SQLite to our structure, we can now easily query for records we need, when we need them. This allows us to load small chunks of data instead of large chunks that contained information we don't need.

Since all of our records have IDs that are associated with them, we can use these IDs to find what record we need based on information we already have and just pull the record we need. Previously we would have had to pull the full mission and then find the data we need within the mission, but all the data being embedded was messy, difficult to read, difficult to manage, and not optimized in the slightest. Now we just use the mission ID we have as part of the WHERE when querying and we'll get just the information we need.

Now a different type of programming!

Our UX artist, Mickey, has started to implement our UI into Unity. For the past few weeks, he's been learning Shader Graph & working to create gradient shaders to allow us to color UI assets in the engine instead of importing multiple colors of the same asset. Shader Graph utilized a node-based interface to generate shader code.

This method is friendlier to our team members that may not have official coding experience. With this, we'll be able to import fewer UI assets, unload/load less while running the game, and create quality visual effects to add some juice to our game.

More Activity UI Mockups!

Our UI artist, Tetyana, continues to work on screen mockups that the players will see when they do certain activities. Last blog post we showed off a network of neurons the player had to select in the correct order. For some of these activities, the player will have to select a choice within a time limit. Look, we all hate timers because they stress us out but that's the whole point; tension has to be created for it to be released. The team opted for a simple screen border timer that shifts colors as time goes down.

To the left, we can see the timer on the actual mockup. The timer is left white so that we can color it programmatically based on the time remaining variable.

The background image will change based on the locations in the story. Here is an example of looking through a security camera where you must choose which way "Jenkins" went within the time limit. In other instances, the location may be in a digital cyberscape.

In addition to this activity, we've focused on how we'll portray encrypted messages and how the player will utilize a cipher to decode them.

(shown below)

(left: shown mid-conversation with SAM. right: shown in the chat log )

Throughout the mission, players will receive hints that will help them discover what type of cipher it is. These hints can be hidden in contacts, recovered files, talks with SAM, or as rewards for completing previous activities. In the end, the players will have to solve the cipher to decode the message and figure out their next steps.

To prevent players from simply spinning the dial and trying to uncover the cipher without honestly attempting, there will be a penalty for submitting incorrect answers. The more incorrect answers a player submits, the less of the full message they'll have in the end. This means that for each X incorrect submission the player will lose Y letters from the full message. These letters are not immediately recoverable. When successful, the player must utilize the clue they decoded to select their next move. If the player loses the entire message, they will be unable to progress. To prevent players from having to restart the game entirely, the team is considering how to handle this situation. Should the player have to replay the mission? Should they be forced to wait Z hours for the message to be recovered? The goal is to encourage players to search through the evidence they acquired for hints and solve the puzzle utilizing those hints.

An example of an item the player may have that would provide them hints are audio transcripts. SAM can be asked to hack into listening devices to eavesdrop on conversations. The mockup of an audio transcript includes a track of audio that the player can scroll on and watch the conversation play out above.

Now with improved documentation...

While that sums up what everyone else on the team has been doing; what have you been doing, Madame EVIL? Well, I'm so happy you asked.

Since we're a small studio I have a few titles associated with myself. These titles include Project Manager, Studio Owner, Social Media Manager, and Lead Designer. With each title comes an array of responsibilities. One area I felt like I was neglecting was the design responsibilities. Which, truthfully, is quite sad. I love to design and program but have been more focused on all the other areas instead. This has caused an issue as development moves further along. The solution? Drinking a lot of caffeine and diving into the GDD.

A GDD is an abbreviated term for Game Design Document. It is the single most important document when it comes to anything & everything about the game. It is used as a communication tool, documentation, planning, records of past decisions. It links to other important documents like The Art Bible, Branding Guide, and Monetization Plan. Previously our GDD had been lacking. It had outlined everything it needed to have but lacked the in-depth information expected of it. As Lead Designer, it is my job to make sure that the sections are updated, understandable, and useful to the team members.

GDDs can get to be hundreds of pages. They are important, large, and quite frankly intimidating to sit down and write. However, this past month I have been working through and updating the GDD. I am halfway through the outlined sections of the GDD and the page count has gone from a measly 10 pages to 33. The GDD now includes images, charts, graphs, links to resources, and detailed information for the first 5 sections.

These sections are:

Overview
Core Gameplay
Targets
Monetization Options
Project Scope

The sections left to update are:

Project Details
USP (Unique Selling Points)
Story & Gameplay
Assets
Schedule

As always the GDD is a living document and will change as we move further along in the process. Right now my main priority is making sure the team can utilize it for any questions they may have and make sure everyone has a unified view of what the game is supposed to be.

That's All Folks!

I believe that sums up what the team was working on from July through August. If you want more frequent updates be sure to follow us on Twitter, @EvilQuacks, and Twitch under the same name. The Pondcast was on hiatus but we've started recording episodes again so I will be sure to keep you all updated on when that will startup.

Otherwise, remember Ducklings, stay EVIL.