Daniel Hook

Caviators

A 2D arcade cave

Scale: One semester (with other courses)
Team size: 4 programmers
Download: Caviators
Job: Various game logic, "game feel" systems, art

In Caviators you (and whoever you got to play with you) play cavemen who want to catch birds. Therefore you use all the technology available to you: Falling. Rapidly.

To bring a lot of loot home, you have to 1. catch the birds in the net between you, 2. take care that they don't fall out and 3. use the patented stoneage physics to stay in the air as long as possible.

Game loops first

All in all, it was a good lection in "build your game loop first". There was some confusion on how this game loop should look like, the flight balancing turned out to be harder than expected and some systems were built too complex.

Feel the fall

At first, we didn't get the game feel alright. The cavemen felt too slow. If we increased the speed, you'd just crash randomly into birds without the possibility to look or plan ahead. In order to solve this, we kept the slow speed but threw all "feeling of speed" techniques in there: Camera look-ahead, parallax for the wall, parallaxing clouds, parallaxing background, adaptive trailrenderer - even good ol' camera shake.

As game devs say: "Fail faster, fall faster."

Impressum

Daniel Hook
Oberföhringer Straße 73
81925 München

Haftungsausschluss (Disclaimer)

Haftung für Inhalte
Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Haftung für Links
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Urheberrecht
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.

Fails & Learnings

It's not common to put failed projects in a portfolio (since it's usually only as good as the worst piece in it). Also some of the learnings from the following projects are common knowledge. But as you might know: You don't really understand an advice until you ran into the situation yourself. What does it look like, running into those?
Well, this is my journey.

WoW Modding

online modding project
private project, 1 programmer

I had various projects, most centered around building a whole new world and less about editing Azeroth.

First tools, then work

In one project, we wanted to create a total conversion of WoW. New world, new story, new quests. Especially more interesting quests than WoW (with branching quest narratives and such). But while there is an excellent tool for world editing, creating quests was much harder. We had a tool that supported branching quests, but almost all other quest features first had to be reverse engineered by the quest designer, before they could be used. Fishing zones, rewarding honor for quests, only opening quests for certain races... the list of possibilities was endless and our tools were limited.
So as a quest designer you were forced to either stick to "kill 20 orcs" quests or put 90 percent of your work in reverse engineering, which wasn't motivating and inhibited to get into a “flow”. So, finish most of your tools first, then start working.
→ First tools, then work.

Player analysis tools

Something we didn't implement, but made me wonder: How would we know if a group killed our final boss? How many would even get there? What if a drop rate was so high that players would stack some specific item? These are interesting questions for balancing, which need specific developer tools, which are easy to forget since no player will ever see them. So don't forget this part of the work.
→ Develop player analysis tools (and make time for the development).

Feeling > realism

This is a variant of "My first game is gonna be much better and bigger than any other game ever before". When I built my first "thick" forest, I threw thousands of trees on it, all with slightly different rotations and scales. “Like a real forest”, huh? But that is not how the WoW style works. Trees in WoW are ridiculous big. If there are too many of them and traversing becomes horrible – camera glitches, you get stuck, etc etc. One other reason why I tried more trees was that you could see through the "thick" forest from every angle. Turns out, in WoW you handle this with mountains which brings me to my next point… (Small side note: Another way to hinder “looking through” your forest is just to limit the viewing distance. Since this can be drastically increased in newer version of WoW, you can see through a whole zone, which destroyed a lot of their magic to me.)
→ Feeling > realism

Scaling

We listened to the advice to make our first project as small as possible. But as we took care of keeping our map as small as possible, we threw zones in there like madness. In the size of around 1,5 "normal" WoW zones we wanted to put a city, a dense forest, a mountain forest, a swamp and snowy mountains. The WoW style just needs bigger zones, so you don't see all at once or, as previously mentioned, see right through the dense forest. Or not just traverse it within a minute. So, take care for the specific scaling your style and game needs.
→ Know your art style and how to use it.

Copy, rotate, reuse

Obviously, your first game will be completely handcrafted. While you maybe lack skill, you don’t lack determination and will place every tiny rock by hand, draw every texture, etc etc. Turns out, this is a horrible idea. I spend hours painting mountain textures that looked like sh*t, while WoW devs drew some few interesting patterns and just copied them. You only need to create so much original content, that players don't notice that you are reusing stuff. That leaves more time to make your content good, and in total in a better game. Also, you should have seen my eyes when I found out that WoW (as many games) uses four tree models per zone, tops.
→ Create few really good content and then copy it with variations.

Modding projects usually don't get finished

Working with persons over the internet, that you never see, living in different time zones, for free, most of them in their teens, on a system that needs a lot of reverse engineering. Sounds hard, huh? There are some great modding projects that work out like the Skyrim total conversion Enderal, but they are rare. That shouldn't mean that you should never try modding – in the end, it was my stepping stone into the games industry and you’ll find most of my early learnings there. Just don't be too surprised if things don't get finished.
→ Modding projects rarely get finished, but they are worth the experience.

Look from the player's perspective

Especially for level design. Remember the forest from before? Yeah, looked good from above. Almost all world modding videos on youtube are from bird’s perspective. This is how people built them, they look best from there. Also things tend to look better from above, since you have much more details on the screen. Still doesn't help, if this is not how your players will see the game. So regularly check from the players perspective and at best start your design there.
→ Create your level from the player’s perspective.

Most gets done when you have some time

Sounds kinda stupid, but is a general rule for private projects. "I worked on this for three months" mostly means "I had five days in the last three months where I could concentrate on this". So if you have the time, use it. And remove all blockades that would require a team member to wait for somebody's input. Two people having a lot of time together is a rare occasion, and you loose one of those precious days where things really get done.
→ For private projects, use the few days you have to work on it. Don’t make people wait for others input.

Honor every work & don't mind throwing it away

There is a thin line between this. Getting your work thrown away hurts, but keeping everything slows down the project a lot. I guess the best way is to teach your team the Elsa way ("LET IT GOOOO"), while also being cautious not to assign tasks that are likely to end up in the trash bin. Also - if possible - let people rework their own stuff from scratch, than replacing it by somebody other’s work. Especially in a teaching environment, it's really frustrating if your hard work is replaced, because somebody in the team has more programming experience and his code is slightly better. Also, again: Let it go.
→ Be okay with throwing away huge parts of your work.
→ Avoid throwing away other people’s work, or assigning tasks that will be discarted.

Lerpz in space

january 2014
1. semester project, during the semester 1 programmer 1 artist (me)

A 2,5D platformer that would become a crazy game of the famous "shoot spider with cows on a circular rainbow" genre.

Physics are fun

Man, did we had a boss fight. You would ride a couch on a rainbow, catching military cows and shooting them at a spider, fighting back with pompels (- is this a word?). Despite the lot of work we put into it, it was fairly simple: Dodge pompels, catch cow, click to shoot.
Before that though, we had another passage, which you had to cross with your spaceship, dodging magnetic mines. We already had the whole player controller, and only needed to add a force to the bombs if the player got too close. And boy, was it fun sneaking between those mines, crashing them into one another and nearly dodging them. Without much work, we had the much better game than our “epic boss fight”. Just by adding a little physical magic and ctrl+c & ctrl+v.
→ Physics are fun.
→ Polish your random design gems, instead of forcefully building a new design from scratch.

Some is much better than none

We added some rough sketches as a "story cutscene" and as it turns out, this felt much better than, well, nothing. Sometimes it's the small changes that make a huge difference, like the short text boxes at the end of Dragon Age: Origins that explain how your decisions turned out. Or the main menu for your gamejam project. The jumping sound. Almost no time, big effect.
→ Some > none.

Watchout

march 2014
voluntary semester project, 5 days, 2 programmers (me) 1 artist

2D puzzler with gears in a clock, where the whole world can be rotated.

Bite through new systems

As I started out the project I just finished my first semester and didn't know much about Unity. When I got told "Now, you just do this clock in Unity." I was extremely stressed. But when learning something new, you sometimes just have to bite yourself through. Everything will work out fine.
Bite yourself through learning a new system. It will become much easier.

Crash bugs wait until the last hours

We didn't have any problems until five hours near the end, where we had a crash bug. We didn't "find" the bug, it found us. When we rotated the world, sometimes the game would not only crash the game, but the whole Unity editor. Obviously without any error message. I guess that's just the life with game development, but it's always good to reach this state sooner (e.g. by preparing a vertical slice) and planning for a bug fixing phase. We didn't find the problem in the end, but reducing the amount of rotating colliders made the bug at least less common.
→ Bring your game to the limits early in development.
→ Plan for bug fixing.

Game Design: Limitations are important

You remember I said you could freely turn the world as you wished? This allowed for almost no platformer challenges, since with some skill you could just get everywhere. We added some walls to tackle this problem, which wasn't the most elegant method. I list this here, because I saw this problem come up again and again later. "Flying" is usually a thing that makes your level design MUCH harder.
So have some limitations for your level designers to play around. And if you are especially fancy, do the WoW way and lock off some region with ever stronger monsters.
→ Have limitations in your level design.

Neuronauts

april 2014
private team project, 1-2 months, ~5 programmers

A 2,5D puzzle platformer.

Tools have to be usable

For this project, our coders created some beautifully coded tools with one flaw: The beautiful coded design was horrible to handle. Also it was limiting: E.g. there was no possibility to create a button that would only disable a moving platform, because this might create problems if there also was a button that would only enable it, and both are pressed at once.
In the end, this obviously is a trade-off. You cannot have a completely hacky system that allows for everything, because this will result in bugs, much work and not being able to enlarge it. But on the other side your game designers need as much freedom as possible.
→ Balance “Game Designer Freedom” and “clean code”. Prefer freedom, then refactor.

Puzzles are hard

We had everything: Coders, artists, sound,... but we didn't have our core gameplay: Puzzles. Turns out that puzzles are extremely hard to design. And even if you finally have a good one, you'll need many more because it's non-repeatable content.
I, myself, don't like straight-up puzzles too much. Yes, in the end every game can be seen as a puzzle. But "puzzles" like the boss fights in Shadow of the Colossus also add other elements like reaction games, spotting and aiming. This mixture is not only easier to digest for me, but also stretches the playing time, so the designer can really focus on this one puzzle, without lacking content.
→ Puzzles are really hard to design.

Early project -> vertical slice

Neuronauts was one of our first projects, and as most people know those never get finished. We tried to go "full production" mode and first build all the levels from the ground up and then iterate on it. Which left us with some experience in greyboxing but nothing else, when we abandoned the project. I think it would have been much better to aim for a vertical slice. This way, we would have something to show-off as well as experience on the many details from UI to VFX that need to go into a game.
→ For your early projects, make a vertical slice first.

Scaling 2

Again, take a look how your player is gonna see the game. Our main character model was very detailed, but later we found out that our camera would have to be far away to get an overview over the puzzles. Just scale first, then the rest.
→ Scale first.

Watergate

january 2015
2. semester, SemesterGameJam project, 42 hours, 3 programmers

A 2D platformer of a small mage, that can shoot, freeze and vaporize water to get through a level.

Performance

Even simple looking games can melt your graphics card, if not correctly optimized. Watergate was supposed to look like Super Mario World, but made my laptop kneel to 6fps (most likely because we forgot to activate batching). On the bright side, this was our first time developing performance tools, disabling everything that was of no vital necessity.
Also, we would have seen this problem sooner, if we listened to the next learning…
→ Simple art styles can also be slow, if not properly optimized.

Gamejam: Work on your level early

The level for our game was done within about 15 minutes. 48H of gamejam, and only 15 minutes on the thing everyone would play in the end. Just spending some more time in it, we would not only encountered our performance problem sooner, we would have a much better and longer level to play. Especially because we forgot the…
→ Start working on your level very early.

Many easy challenges

We tend to play our games a lot, so we are good at them and design them to be too hard. We are even scared to bore our audience, if we design some parts of the game to be too easy. But if you have around 20 minutes of easy content, that is not only not bad, but maybe even helpful. People need some time to get into your game. Even if they are too good, they will feel good, running through your content like pros.
I saw this problem with a developer who made a reaction game, that he would only playtest on esport players in the genre. So for me, he could have easily just added 30-100 easy levels where I could play with the mechanics. But he didn't, so he lost me (and most likely every non-esport-player) as a player.
→ Add a lot of simple challenges.

Cactus Tank Game

january 2015
3. semester project, interaction method course, 2 programmers

A 2vs2 game, where one person drives the tank while the other person aims and shoots. Using the cactus controller device.

Be clear about the vision

This kinda contradicts "change your vision". You know, all is a trade-off, thin line, etc etc. This here is the other side. Our game started out to be like the Nintendo Wii tank game and ended up with four overloaded split screens. Which was kinda sad. Funny enough, a german developer released a game similar to the one the game we initially planned. So if your vision has some potential, take care that you don't drift to far away from it.
→ Stay true to your game design gems and don’t overload them.

Physics are fun 2

Best mode in this game was, again, by just throwing some physics in. We built bridges from boxes, because it's always more fun to shoot away the ground under someones feet than just shooting at their hitpoints.
→ Physics. (heart)

Controllers can take performance

...especially custom built ones. We never tried the game with four controllers till the very end, which surprised us with horrible lag.
→ Test your game in a playing-scenario early.

No imperformant systems

Just no. But maybe, it's so nice and-? No. We had the possibility to blow away smoke particles in a really fancy way, but it was identical with blowing away the framerate. And at 4fps, it also wasn't beautiful anymore.
→ Don’t add systems that crush your performance from time to time.

Agententrainer 3001

june 2015
4. semester project, kinect project for university, during one semester, 2 programmers

A kinect game where you play as an agent, going through some virtual training in hiding and shooting.

Use the same editor version

We had a newer Unity version on our laptops than on the machines we used the kinect, destroying many of our prefabs. Just change to the same version, even if it's an earlier one.
→ Use the same editor version.

Simple effects, much graphics

In my opinion, the best effect in the game is the distorted ground, which is just the Unity water shader over a texture. A good example, that a simple effect can enhance the graphics a lot. Also the human model was made with makehuman, lifting a lot of work from our shoulders.
→ Again: Some > none. A simple effect can look surprisingly good.

Kinect in general

Social Schnitzel

june 2015
4. semester project, location based mobile game, during one semester, 6 programmers

GeoTracking game, where your team has to race to coordinates to get hints at the coordinates of a price.

Finish setup early

Setting up things is horrible, especially Android studio. More so, if you don't have a smartphone. So get this out of the way, or you will have no motivation to start working. Also, don't start private projects where the setup takes longer than the actual development. This is very frustrating and can really drag you down.
→ Finish the setup early.
→ Don’t do private projects where: setup time > development time.

Scaling. There is a "too small".

"You cannot scale too small" is actually wrong. We tried, and we scaled so small that nobody wanted to develop the game anymore. In the end we even handed in even less than we planned for. Also we had a really horrible setup-to-development ratio. The project could have easily been better and more fun, if we dreamed a bit bigger.
→ Don’t scale so small that people loose motivation.

Sit in one room

Remember the tip "only one feature at once"? Now, this time we should use android studio, a server/client structure and facebook/google apis. With six devs we had to organize. Everything was entangled, so work was horrible to split up. The best teams had two programmers that would work closely in a room together and the rest was doomed to create assets. So if you plan to work with many people, take the time to work in the same room together.
→ Work together in one room.

8i Racer

august 2015
voluntary semester project, 5 days, 3 programmers (me) 1 artists

An online racer, where every player has 8 ai controlled cars that can be used to block the road or attack other cars.

Only one challenge per GameJam

We didn't get to finish the game. Easily, because we wanted to implement AI, wheel physics and networking, which are just two new features too many. On a gamejam, and also in general, do not try to implement more than one or two new big features.
→ Gamejam: Only implement one new feature.

Lead, even if you are less competent

...in the specific skill. I was working with a really skilled programmer with whom I worked with before. So I thought he would finish his parts on time. But "skilled" means "fast" but not "on schedule". Especially when you are good at something, there is the tendency to get stuck in the details or have a to general approach. If I would have pushed the team back on schedule, the game would be more finished. Also again: Don't fall into the trap, that communication is gonna solve itself just because you worked together once.
→ You need a team leader, no matter of her skills on the subject.
→ Communication doesn’t solve itself just because you already know each other.

Flipwars

december 2015
SemesterGameJam project, 2 programmers 2 artists (me)

A round based two player strategy game, playing at the top and bottom side of a board. After each turn the board turns. In order to reach the enemy base, players have to push blocks through the board to make space for themselves and blocking for the enemy.

Communication is key, which can be a leader

A leader is a useful communication device and not the first thing you might think about if you are working with friends, since "everybody knows each other so well, and you decide together". Well, a leader doesn't have to be a dictator, and even if you know each other well, you still don't know what they are working on. Think of a “coordinator”. You might want to have a person that walks around and checks if everybody is still working on the same game. In our case, almost all art was scraped, since the programmers didn't plan for the assets, and the artists didn't know the assets weren't needed.
Don't do double work, have a leader that keeps your team together.
→ Have a team leader/coordinator.

Double tap

We had one main programmer who did about all the systems. He worked through the first night of the jam, then he was sick. This was about the end of the project, because I couldn't get through his code. Not able to expand it or fix some bugs, we couldn't finish the project. This is also part of the communication aspect. You might want to have at least a second person that can jump in if one team member gets sick. And also leads to the next point…
→ Every team member should be replaceable (with some effort).

First easy, not beautiful

As previously mentioned, beautiful code is not necessary good code. Every cell on our grid board consisted of five (!) prefabs that, for some reason, could not be reference by position but only referenced the surrounding cells. I tried for three hours to get through the system, but couldn't. So: If your game does not need such a beautiful (and complicated) code construct, you might first want to go with the easier (and easier to understand) solution.
→ Make your code as simple as possible.

Good code = understandable

Basically the same again: Take care, that your code is understandable. If nobody else can use it, you made yourself invaluable to the team, but that's it. This also includes only using fancy programming techniques if they are really necessary. It's always a trade-off between short code and understandable code, so think of both sides.
→ Understandable code = good code.
→ Balance short code and advanced programming techniques.

Highway in Hell

january 2016
5. semester project, worldbuilding prototype for storyworlds course, 1 programmer 1 (technical) artists (me) 1 writer

Hell is not hot enough for the hard biker you are, so you go on a journey to kill Satan and set the hell on fire!

Know your tools and limitations

The Unity terrain tool is horrible. I didn't think of this, since I only worked for WoW modding with a really good terrain tool. And Unity couldn't be worse than a modding editor, could it? A lot, as it turned out. But I also didn't search the asset store for a better one, so also kind of my fault. If I had looked into this sooner, my approach to the level building would have been more effective.
→ Know your tool and its limitations.
→ Search the asset store for tools.

Trunkenbold

march 2016
voluntary semester project, 5 days, 4 programmers

A first person game, where you have to drink in a club to stay awake, but not get thrown out because of the problems with your alcoholism.

Balancing needs time

Very often, I had systems that could work fine, if they were balanced correctly. But especially at gamejams balancing time is missing. For Trunkenbold, the balancing was planned that on the one hand you have to try to be so drunk that you don't fall asleep, but on the other hand still able to get more alcohol without running into people, barfing it back into the glass, not getting to the toilet anymore, etc etc. But all those systems would need to be balanced to be fun, and we didn't get that far.
→ Balancing really makes or breaks a game.
→ Balancing needs a lot of time.

NOT_RACIST_BUT.exe

june 2016
SemesterGameJam project, 42 hours, 1 programmer (me) 3 artists

A wario ware style game, where you have to solve mini games, by thinking in stereotypes.

Artists should be able to implement their work

I had the luck that for this project I worked with three artists, instead of the usual zero. The artists didn't have too much experience with Git, so we decided that they would just give me their assets on an usb stick and I’d implement them. Which was a bad idea, because I couldn't implement the art of three artists, while building the whole game logic at the same time. A lot of the art couldn’t be implemented, which left me with only showing it off in a special level at the end, which was very sad. For future projects, it would be better for everyone, if every artist is shown how to implement most of their art, to better divide the work.
→ Your artists should have a pipeline with which they can implement their art.

Don't forget effects & sound

"We'll add sound and effects at the end." is what I very often thought. This turned out to be really hard, since the game wasn't planned to wait for e.g. our explosion animation to finish before it changed the level. Just an important point to think of earlier.
→ Again: Some > none.

Tapblock

october 2016
private project, 1 programmer
Mobile game, where you jump in the direction of a platform. Charge jump by pressing longer.

Change vision if needed

While the tapblock gameplay turned out to be quite fun, I had bigger plans for it. The original idea was that behind the simple gameplay, there was a big story with a Glados style ai, breaking the fourth wall, etc etc. But this was hard to implement, dragging the project back and especially my motivation. Instead, it would have been way better to focus on the core gameplay, until it was a full game.
→ Change your vision if needed.
→ Focus on your game design gems.

Convenience controller

Player controllers are hard but can also be a lot of fun. Since the controller in this project was fairly easy, I had a lot of time tweaking it. Some tolerance if you let loose too soon, the weight of the cube, visual feedback,... Just don't forget to add all this, since it takes the experience from "horrible" to "fun.
→ Add “quality of life” features to your character controller, and polish it.

Shaders, but not for mobile

This was actually the first project where I really tried out working on shaders. And it turns out, shaders for mobile are a lot harder, since not all devices (especially my old 60€ tablet) don't support nearly half of what you would expect.
→ Shaders on mobile are hard.

PonyoGame

january 2017
private project, birthday present for brother, 1 programmer, 16h

Ponyo fell from the boat in the water! You have to lure fishes to the water surface by throwing bread, so they push Ponyo back into the boat.

You can do a game within a day

→ You can do a game within a day. Make one.

Monster AI

april 2017
private project, 6. semester, two persons, 48 hours, 2 programmers

You're a monster in an apartment and try to eat as much as possible, to be really big when you scare the hell out of the inhabitant.

Be sure what you want from a jam

Gamejams can be really good for two things: Getting a new project for a portfolio or learning a new technique. Ironically, both is mostly hard. If you learn too much new stuff, you won't finish your game. For this jam, I wanted to get a game to show off, but looking at the scope of the project, I would have rather focused on creating some more clean code, learning more and maybe being able to present the code.
→ Decide whether you want a beautiful portfolio project or learn something new.

Unity Pathfinding and AI

→ Unity Pathfinding is easy to use.

Deserteur

september 2017
private project, 1 programmer

A strategy game, in which you always outnumber your enemy but with unmotivated mercenaries which will flee if it gets tight. Your only way to move your units is to shoot deserters, scaring the rest back into the enemy.

Design needs tools

I didn't have the full design yet, as I started out (as if you ever have). I only knew that the units should somehow move like fluids, repelled by killed comrades but also hurting enemies. How the repelling surroundings worked was important for the design, but a task in itself to visualize. Especially since the design constantly changed (e.g. should they get more repelling if they got closer to a source, or the same amount if they were in the influence radius?).
Also I was afraid that the visualizations would make me balance the game with all those visualizations in mind that shouldn't be in the final game. Which was, in retrospective, a stupid thought. Game design needs good tools.
→ Make game design tools (e.g. visualization).

OpenCV in Unity

february 2018
private project, 1 programmer
Using OpenCV to track the head position, adjusting the viewing cone, creating a 3D feeling.

Don't stop till it works

It's highly demotivating to come back to your broken code, so don't leave it broken. Always continue, till you finish something and at best leave a cool "cliffhanger" feature that you want to implement for next time. This worked for me really well, until I encountered a crash bug that I couldn't solve before I had to stop working, leaving the project on the dry for a while.
→ Don’t stop working on your code until it works.

Calling C++ dlls in Unity

Easier than I thought.

Threading for Unity

This is still where the crash bug lies...

Hi! I'm Daniel Hook, a game programmer/designer.

About me

Portfolio

Recent Projects

reFit Gamo

Gamo Overworld

aiimag.es + SOURCE CODE

WARP

Endless Terrain Generator + SOURCE CODE

3D cage deformation

A (far too long) list of (mostly failed) projects and my learnings.

It's dangerous to walk alone. Take this!