64Digits

I quit my old job because they basically burned me out. It really sucked, because although I liked the place and people, they did not allow me to maintain a good work/life balance. Basically, they kept a way-too-accelerated development schedule, ignored repeated warnings and red flags about my stressing out, and I basically had a big breakdown :< But even with that happening, I still had to keep working, because immobile deadlines are by definition not movable. Once that was done, I finally got to take my two weeks vacation - too late though by that point - I couldn't work there any more.

This whole thing really fucked my head over, and I'm not willing to go through that sort of thing again. It is difficult for me to gauge my own stress because I can sustain an absolute ton without any observable effects, and I stay chipper and cheery and positive until the very end.

I wrote this when I was trying to figure out how to explain how I felt to my (now no longer as I changed jobs) department head. Zomg mopey drama stress.

Developer Currencies

When a developer is working on a project, he expends one of three currencies to maintain his pace.

The first currency is energy. Energy is your standard 40 hour work week. If this reserve is never emptied, there are never any problems. A developer will remain happy, content, and productive indefinitely.

When energy runs out, some people stop working and go home. A developer I once worked with fit this to a T. He was an excellent coder, but he had a clock. In at 9, out at 5, no exceptions. If all you want is a job and money, this works. Developers who only spend energy will get the task done eventually, but usually in a mediocre fashion.

The second currency is blood. When a developer is out of energy, they may instead spend blood. Blood is extra effort, overtime, unpaid work for the sake of making the project better, or crunch time. It is damaging, but sustainable for a surprising length of time. A developer spending blood can still be happy, if tired. Most developers are willing to spend blood to see a project get out the door, and sometimes it expected to spend blood. When blood is spent, the debt must eventually be accounted for - time off, bonuses, praise, or some other tangible form of reward. A developer who spends blood is a good developer, but should not be asked to spend it too often.

The third currency is soul. Soul is spent when all blood is gone. You cannot ask a developer to spend his soul, as it can only be spent willingly. Spending soul is fundamentally destructive, as it can and eventually will destroy the developer if too much is spent. The developer is unhappy, but continues to work past the point where others would stop. If milestones or marked progress is made, the resulting morale boost resulting in a brief respite, but with decreasing gains over time. A developer willing to spend soul is a rare developer - they care deeply about the project and are willing to hurt themselves grievously to see it come to fruition.

If all of soul is spent, the developer breaks. Whether or not they put together the pieces afterwards is up to them but things are not the same, as it usually results in a fundamental shift in the developer. Spent soul can only be recouped by significant change, and long lengths of time spent away from work.

A developer should only ever spend soul on their own thing.

Energy is life. Without it there is only work.

Blood is happiness. Without it there is only the task.

Soul is existence. Without it there is no developer.

It broke my will to work on personal projects for many months, including my VM project which I haven't touched since end of February. I spent my two weeks of vacation huddled at home slowly regaining sanity, and over the next month and a bit, I somewhat learned Haskell (a beautiful language). I really enjoy using it, and Haskell has many of the same design goals as what I want to accomplish. Learning it was quicker because a lot the design choices or constructs/concepts in my language exist in Haskell, which makes me happy because I feel it reinforces those choices in my own design. But although I will finish my VM/Language, I need more time before I can allow myself to focus on a dense, complex project like that. Instead, I'm trying to work on something 'lighter' in my spare time.

I almost wanted to quit iOS development, but instead I decided to leave the client-services industry and join my friend at Plum. The team there is very small, but hand-picked and is full of incredible talent (one of the guys here had a large hand in the Swift language and has written VMs, so hello knowledge base for my VM project!). Working there is a completely different thing as well - I'm really needed there (my addition to the project has really helped their development schedule), and its more like a group of friends looking to make some money together than it is a company.

Now, for that aforementioned `something 'lighter' in my spare time`, I said that when Unity finally came out with their UNet networking overhaul, I'd be making a game with that. Well, it came out, so I'm keeping my word. I've spent the last few weekends reacquainting myself with Unity and C# design patterns, and have made an exceedingly limited thing that fulfills three of the most fundamental game mechanics:

Player movement - something crucial to making a fun game is good player movement. So I spent forever going over different mechanisms in my head relating to inertia and thrust direction. The end result I am quite pleased with, as it is a smooth sixaxis movement scheme that can switch between your standard simple Newtonian physics, and a complex inertial siphon that damps/redirects motion against the thrust vector as additional acceleration. In a nutshell, applied radial- or backwards-motion friction becomes additional thrust, the efficiency of which is dependent on the angle between the thrust vector and the current inertial vector. This means the inertial dampers give a nice 'steering' effect with good control and ability to change direction, while still giving the player a nice chunk of inertia.

Shooting / deploying - it is just a gun that shoots bullets that leave shitty hitmarks that glow with heat and fade after they cool. And a deployment bay that tosses out things like (nonfunctional) mines. Simple but critical stuff.

Base constructs - A strong part of the game is oriented around defending your team's base, so one of the weapons is a constructor-gun, of which is able to place (nonfunctional) buildings (really, just cubes) accordingly on buildable surfaces.

Now to take advantage of some poor saps with dollar signs in their eyes. I need someone to make and texture some models for me for prototyping, do graphical design for UI and stuff, and I'm considering putting a bounty on it. I bought the ProCore Bundle back when Unity 4.6 was released, and used it to make a few prototype models, but A) it took forever B) ProCore is decent but limited (and slow hence A) and C) once upon a time I'd be fine with spending the time myself to make shitty models, but now I'd rather get one of you guys to do it. You'll do it better anyway - I'm shit at it :P

I'm talking like, Quake-3 level graphics - just simple, non-deforming models with diffuse texture (and maybe emissive texture). We're talking stuff like:

Player `core`, to which various submodules are attached - shield, engines, left/right weapon, weapon bay, and utility attachment are the submodule types; each is their own mesh

Player deployables (mines, sensors, other `droppable` items)

Constructs (player base buildings)

If there's any interest, I'll make some rough sketches, notes about sizes / style, and post a blog about it (along with bounties). I'm not looking for anything complicated. It needs to be representative of an intended final version, but mostly I just need something 'close enough' - something a decent modeler could mock quickly. Random brain says bounties would probably be on the order of 20$ per bounty.

So make it rain!

Updated with sketches:

Rawr, Need 3D Modeler (Will pay)

Comments