1. CV

    Download CV
  2. mail

    mlynareknils@gmail.com
  3. LinkedIn

    My LinkedIn

Personal Projects

Prototypes | Ideas | Research

Here you can find a selection of my personal projects. None of them are aimed to be released to the public. My personal projects serve to satisfy my own curiosity, help me learn something or generally are fun to make. My projects usually start with a specific goal, idea or question and I won't stop the project before I found what I was looking for.

Tower Defense

What I made

A Roguelite tower defense game that requires tactical problem-solving skills similar to those in classic tactics RPGs.

Why I made this

I wanted to combine my favorite aspects of three different genres I really like.

  1. Tactics RPG: Deep systems that give players a wide range of options to complete an encounter.
    - "I found the best solution for this problem that fits my playstyle."
  2. Tower Defense: Effortless fun through simple mechanics, playful visuals and exciting mayhem.
    - "I make things that make other things go boom."
  3. Roguelite: Steady overarching progression while occasionally allowing overpowered, seemingly unbalanced builds in individual runs.
    - "I broke the game with this build."
Learnings

Let me highlight a few key changes to the design during prototyping:

  1. Original Design: Gold, damage, costs etc all was in the hundreds. Waves had 20+ enemies.
  2. Changed Design: All numbers are low, in one-digit range wherever possible.
  3. Reason: Clearer information that is easier to calculate, which allows players to make informed decisions to solve a given encounter.
  1. Original Design: Only one Tower class. Each tower can be upgraded with 8 mods which makes them super powerful and every tower can be upgraded in vastly different directions.
  2. Changed Design: The original class is just one of many (currently 3). Each class incentivises a different playstyle. Each run the player selects a main and secondary class.
  3. Reason: Introduces a new higher-level system that unlock a lot more variation and playstyles. Selecting 2 classes provides interesting synergies.
  1. Original Design: There was no grid. Enemies walked along a spline and towers could be placed anywhere.
  2. Changed Design: 12 by 12 Grid more akin to traditional Tactics RPGs.
  3. Reason: Discrete options remove fussiness in ranges and placements. Fiddling with perfect placement is not fun and distracts form the decision.
  1. Original Design: Some Towers and Mods increased crit chance or crit damage.
  2. Changed Design: Removed all crit-based abilities.
  3. Reason: Input randomness makes it very difficult to make reliable strategies.
  1. Original Design: Earn gold for every kill. Gold persists between waves and levels.
  2. Changed Design: Each wave the gold is reset to fixed value (think gold in Hearthstone).
  3. Reason: Gold on kill creates a negative reinforcment loop.

Gets

What I made

A Chess-like mobile game with an enemy AI trained by machine learning.

Why I made this

I wanted to learn how to make an enemy AI using machine learning in Untiy and find out if this is a viable, scalable approach to game design. What are the pros and cons?

The Game

The first player collecting 2 coins Coin wins.

  1. Coins can be picked up by moving a unit on to the coin's field.
  2. A coin is collected when a unit carrying a coin, reaches the base base.


Units can perform 2 kinds of actions:

  1. A unit can move move to another field without a unit.
  2. A unit can attack attack another unit (friend or foe), removing it from the field and returning it to the player's bench. When a unit attacks, it will move to the field of the attacked Unit.
  3. Every unit has a differnt attack and move pattern.
Learnings
    1. (+) Very scalable solution for difficulty. Simply use different training data with different amount of iterations.
    2. (+) Let's you easily identify dominant and inferior strategies.
    3. (-) Training requires extremely well thought-through test designs to achieve a usable outcome.
    4. (-) Requires re-training and potentially new test design after every game balancing iteration.
    5. (-) Complexity of implementation increases significantly with complexity of game.

    Result: not a viable solution for games more complex than Gets.