Both BarHints are made up of a List of NotchHints representing the row/column they've been created for. The algorithm is a simple list of steps of checking the color of the current cell and comparing it to either the current accounted filled cells or the previous color.The beauty of this algorithm is it will work for both a monochrome grid and a color grid.The RC_NotchHint (RC standing for RefCounted) is a script that keeps track of a list of numbers and colors in its respective column/row. By adding onto these lists at the same time, I can be assured that the colors are directly connected to their associated number.

Grid Generation

The actual first code written for this project. Everything about the way the nonogram is laid out is based on the grid generation. The reason for this is that the GridGeneration node is held within a Subviewport. Within it's script, it calculates the shortest side of the viewport divided by the longest cell count, creating the overall cellSize of the grid.This Cell Size dictates the size of everything else visually: (font size of BarHint, notch thickness of BarHint, length of lines making up the grid, etc.)

The actual grid is created using Godot's in built _Draw() function and the handy functions that come with it.DrawMultiline() draws an array of lines from a starting position to an ending position while DrawSetTransform() helps to rotate the transform of _Draw() in such a way that I can reuse the exact code made prior with minimal change.

Dynamic Grid Sizes

The next most important part of the grid generation is the ability to accommodate grids of any size.This logic utilizes Godot's GridContainer. By changing the minimum size of the first Node in the GridContainer, the BarHints current size will be transformed along with it.

The actual logic for this is at runtime calculates the longest possible size of the BarHints and compares it with the current calculated allowance (labelled as "Consequence" in code) that the BarHints are supposed to be contained in.The comparison is called roomForImprovement. Too small, and the BarHints would be uncomfortably touching the edges of the screen. Too large, and the BarHint is taking up too much of the screen.The BarHintRatio is how much of the screen I want the BarHints to take up. By default, it tries to fit within 1/4th size of screen. If it can't, it'll move on to trying ot fit within 1/2 screen size.This logic all occurs in a while loop. To prevent the while loop from going rogue, there is a safety return true on Line 128 that'll stop it if the other logic fails.

This logic is done through an abstract class BarControl that diverges inheritance into a VBarControl (Generation of the left/Vertical bar) and HBarControl (Generation of the top/Horizontal bar).The only relevant logic stored in BarControl is within the _Draw() function. The font size is determined by the cellSize (taken from GridGeneration) multiplied by the fontSizeModifier (taken from BarSizeControl).

The code to the left shows the chunk of logic for creating the list of hints in each notch of the VBarControl. Here's a quick list of whats going on:

Grid Movement

The main mechanic of the game is the ability for the player to pick up and move the ingredients around the screen."Cooker" Objects are any objects that can transform an ingredient into another ingredient (Example: a block of cheese to grated cheese).

While I could use a raycast to point to where the mouse is on the screen, I prefer to use the _InputEvent() function that all Godot CollisionObject3D nodes have. This function automatically detects when/where the mouse is hovering over it.Passing in eventPosition arguement into my custom function GetGridIndexFromInput(), I can translate the 3D world position into a 2D grid position. This can then be translated back into 3D world position by inverting the calculations.The other aspects of this code is that it uses the propertions from both a PlaneMesh (CookerMesh in code) and a Subviewport (GridViewport in code) for visually showing the grid via a SubviewportTexture.

Ingredient Interaction Using Groups

Godot doesn't contain the functionality for C# Interfaces, but it does have a close equivalent through Groups: A string tag you can add on a node to group it with other nodes.With these groups, functions can be called on and node that contains the tag. This is utilized in my DragIngredientManager class.
Line 101 calls the TakeIngredient() function on the hoveredStorage variable.*NOTE: The StaticStringRef class is a custom helper class where I store all StringName/NodePath references for the entire project. This is to get around a quirk of how Godot translates C# into the engine. Most if not all functions that ask for a StringName/NodePath can have a string passed in. This should not be done due to the resulting lag.

The above code shows the logic of interacting with a Cooker while holding an Ingredient or having no Ingredient.(Line 101) Interacting without an ingredient will result in trying to take an ingredient.Interacting with an Ingredient will either (Line 124) result in placing it onto a Cooker or (Line 128) returning the Ingredient to its parent.

How Ingredients Are Placed

The actual Cookers store the logic for whether an Ingredient can be placed on it. 3 booleans are checked across multiple functions:

isCellsFree is checked when updating the tempTakenCells array in TryPlaceIngredientsInCell() and CheckIfTempCellsTaken().Ingredients keep track of what cells they take up in an array of integers. By cross referencing the taken cells of the Ingredients a Cooker is keeping track of with the current tempTakenCells, we can quickly find out if hovered cells are overlapping.

canFitInCooker is checked while pushing the tempTakenCells around to make sure dragging Ingredient stays within the bounds of the Cooker.This code utilizes Godot's Rect2I class to check if the Cooker grid encloses the Ingredient (Line 225). By checking the Intersection of the grid, we can move the Ingredient around to keep it within the bounds of the Grid.

Hi! I'm Phoenix Schmitt

I'm a recent Game Design graduate from Austin Community College. I enjoy sewing and drawing in my free time. I thoroughly enjoy coding and discovering the multiple ways to approach problem solving. Every bug is another opportunity to learn.

Email me:

• [email protected]

Discord:

@charlilouis

• Link to resume