Guidelines | CodeRedCat

It is important to stay honest and responsible towards your statements. It is better to stay at realistic goals and achieve them in great quality.

Software development comes with a unique set of challenges. That's why a lot of base knowledge is mandatory, as well as a high tolerance for human failure and technical failure.

Friendlyness opens doors. It signals readiness to listen and to help out. You want to have everybody express their thoughts, so you get the full picture. Misconceptions, criticism and failures have to be communicated, but it can be done in a good constructive way!

Focus on Productivity

Rushed software sucks! But a developer still needs to work towards a goal in a certain timeframe. That's why optimization of pipelines and workflows is so important. Always identify bottlenecks and work out solutions.

Analyse the situation, plan accordingly, avoid feature creep and adjust in fast and effective circles.

This also requires in-depth analysis and the right tools for the right jobs. Early problems can often be avoided through fast adjustments, but whatever is dragged through a project, will decrease either the quality or increae the time to finish.

Game development resolves around 4 key areas: Programming, art, design and management. All areas are important, but software is the supporting pillar for art and design. Most code and will often be rewritten by multiple people. That's why the code must match coding standards. It should be "secure, reliable and maintainable".

Code has to be consistent in form and style. It should be intentional in function and form. And it should be adaptable in its modularity and distinctiveness. This way, the technical debt is kept low, as time progresses, giving the project a way higher success chance.

Authenticity, respect and friendliness

Clean Code

Core Values

Software Development With Good Taste

Working self-reliant is nice, but software skills have been developed by thousands of developers, who spend lifetimes in finding the best solution. Communicating and reviewing with other developers is therefore key.

Understanding other Developers

Development has faster, if the process streamlined on the most important areas. Reducing complexity helps speeding up development time and increases the software quality.

Focus on important keys

How software was developed. Example: BrushForger - ParallaxScroller

The problem: During Unity development, parallax effects spice up 2D environments in give scenes some kind of 3D-ish coolness effect. In bigger game projects, parallax backgrounds get drawn and adjusted to fit specific areas. So you end up with very stylish, nice effects around places that are unique and fit the overall scene. However, if you now change the layout of the scene, you have to reposition and often even redraw the parallax layers as well. As you draw many parallax layers, like 7 in the foreground and 7 for the background, this takes initial time. And if you do not have the time to redraw the background, you might not change the scene at all. So a problem in the scene might not get addresses and the whole quality of your project suffers.

The prototype solution: As a solution, the parallax effect was brushed in as several game objects, which then can be adjusted or redrawn on the fly. Instead of drawing each parallax layer, all layers get drawn at once. To achieve this, the Unity TilePalette was extended with the ScriptableBrush system, which allowed making custom brushes and instantiating them into tiles.

The prototype limits: Unfortunately this had some problems. First, the system was limited to a tile grid. This was in practice and in code, while the real solution was moving freely, not caring much about the grid system in place. So a lot of code had to handle grid system requirements, which never got used.

The asset solution: To have a full solution, a new base system was born. The base system would create a UI interface and handle all the background management for the brushes. After all of this was complete, a brush was created that was able to draw objects into the scene. And after this, a brush that would draw on multiple parallax layers. This was not the simple solution that was planned, and it required a flexible, expandable code base with customizable code and many, many support functions. In the end, the system has to work solid and in daily use, no one should care about the thousands of lines of codes, managing the save data, 3D position calculations, interaction requests and much more.

Clean architecture: As users should be able to create their own brushes and tools, these have been abstract classes from the start. While they could also be interfaces, some methods will most likely be the same in every brush, so an abstract class will shorten the code quite a bit, while you could still override the base methods, if desired. The system was then split apart into 3 parts. The base system, which now has to be able to handle any kind of brush, regardless of its type, the prefab brush, which can brush prefabs and the parallax brush, which takes the capabilities of the prefab brush to create parallax effects.

Documentation: As the goal to make an asset for the Unity market store was clear, the documentation had to be able to address a variety of people with different backgrounds. From the experienced coder, who wants to create his own system, to the artist, who never touches code. So there could not be one document to address them all. But that does not mean a multitude of PDF documents is required. Code can be documented with XML. This makes it easy to read what a method is supposed to do and what each parameter does. A cool rule is to not document what the codeline do. Coders can just read the code and sometimes code changes and the documentation does not match anymore. But you can document why something is done! UI can be documented with tooltips, so you can find out how something works while using it. This is always the preferred way! And a document and video tutorial can address people who like to read or watch.

Testing: Unfortunately there is currently no code solution for running runtime tests in Unity. While possible in theory, in practice, coded tests at runtime cost more time than just testing yourself. However, interest in testing the code remains high, as it is a standard in many software development project and it just does not feel good to not have it. What has been done, though, is to give the asset to other experienced developers, get real reviews and solid feedback. The feedback then got implemented and is in the very first version of the BrushForger system.

Marketing: While writing this, marketing is still not finished. Often underestimated, marketing requires a good look, clear text and thumbnails, a solid presentation and clear language. What use is a good product, if no one knows it? Good marketing communicates the core of your work, the advantages it gives to the user and brings it to the point. The initial decision is often made in 10 seconds, where the viewer takes a glimpse of the product layout, the trailer, the style, the logos and can see if some work has been put into the asset.

Further Fields

Other technical sideprojects, which are technically challenging and come in handy!

Experience in assembling, repairing and troubleshooting PC builds.

Game Modding

Commitment coming from the creation of several mods in the Starcraft, Warcraft or Doom world editors, which allow fast creation of game content and story lines.