• It’s a friendly group of people, and we seem to get along well
• Alex Crouzen picked up Objective C and OpenGL, and Shi Daniels threw together some wall and floor textures. That gave us a very basic “here’s some walls and floors, running in OpenGL, on an iPhone”, but no walking, no movable camera, no interaction, etc. It actually worked! :)
• Brian Green and Wendy Despain (both games industry pros) joined up and did loads of great game-design and plot work. As a group, lead by them, we generated lots of pages of good design – although (my fault) the remit probably wasn’t as well constrained as it should have been
• Lots of good ideas and commentary from the other people in the group
• We setup a private wiki, a 24-hour skype group-chat, and a private google group, and had some pretty good communications going between the active contributors
• I picked up Alex’s code and rewrote the underlying OpenGL stuff (I’m very rusty; haven’t done any OpenGL for > 4 years), but got it integrated with iPhone GUI stuff, so you could use drag gestures to move around the map in 3D, and added some programmatic map generation

Bad news:

• A lot of people (I think more than half, in the end!) had to step back – or even drop out – due to time constraints / external commitments (work, life, etc). Ultimately, through no fault of any individual … our team was somewhat gutted before we’d got beyond the first milestone :(
• …as a result of that, and some mistakes I personally made on the project leadership side, we stagnated, and the project has ground to a halt with too few active coders

It’s not clear where we’ll go from here, but I’m now looking at whether I can take some of the lessons learnt from this and start it all over again, do it better, more simply, and more clearly directed, as a commercial project.

One of the biggest mistakes I made personally is that I tried to do this as a volunteer project – but simultaneously tried to do it unmanaged, Scrum-style. You could fairly argue that this was foolish, given that I’ve run a lot of volunteer projects before, and they have *always* needed huge amounts of vicious, aggressive project management. Not because people are lazy or dumb, but merely because volunteer projects are always the lowest item on people’s list of priorities (way below “day job” and “family”, for instance – which is fair enough).

But I’ve got so used to working this way now (team-based, distributed responsibility, etc) that I ignored my previous experience and actively avoided aggressive PM.

I’m putting together a detailed project plan now – as if I were doing this commercially. i.e. working it out based on me personally paying other people to work on it – it may not be viable / possible, but if nothing else it’s a good practice to plan to that level of diligence. It’s just a theoretical exercise right now, although I’m sharing it with some industry colleagues and some professional coders and artists, seeing if it’s convincing enough for any of them to want to try it.

One of the interesting things I’ve noticed already while writing it up that way is that – if I have to pay people – I’d start with a much smaller team, almost entirely coders, and only bring on other people once we have (*if* we have…) a substantial working prototype. Which is the opposite of how I was taught to make games originally. But it’s exactly how I was taught to do commercial startups. This could be interesting…

PS: here’s a screenshot of one of the first renders:

I’ve been playing around with GUI setups for DM / EOTB / Wizardry clones on iPhone, and thought I’d post some of the more interesting results here – I’m interested to see what other people think of each of them.

The first three are all assuming a single-character RPG, the fourth is something more like DM / Wizardry (could be 6 chars, could be 3).

Everything is clickable – small maps become full screen map, blue buttons fire spells, character portraits go to the inventory screens.

Screens with no arrow buttons require you to drag your finger forwards/backwards/left/right to move, and allow 360 degree movement. Screens with arrow buttons assume you can only turn 90 degrees at a time (like the original games), although they smoothly animate the rotations (UN-like the original games – because I have access to OpenGL to do the 3D for me).

What do you think?

PS: to all the people reading this blog for the MMO tech stuff, I hope you don’t mind the shift to a lot more business stuff lately. This is what happens when you put together a new startup :). I promise there’ll be more MMO-specific stuff in future…

Setting salaries for new startups is tough

At some point in the not-distant future I’m going to have to provide projected financials for the first 3-5 years of our startup. I prepared this many weeks ago (how do you know how much funding you’re looking for if you don’t know what you’re spending it on? My advice: create your financial spreadsheet as one of your first activities, but keep it simple), and it was all straightforward (I know most of the data I need for these things off the top of my head by now) – except for salaries / compensation for the executives (both founders and any other senior management – CEO, CFO, CMO, CTO, etc).

I have 2 co-founders, so between us we’re covering CEO, CTO, CCO (Creative). At some point, we’ll want someone doing the job of CFO, and someone doing the job of CMO (whether they get those titles depends a lot on how much the company needs them to do). So, potentially half the executive-level management of the company will be founders (with appropriate levels of equity / ownership of the company), and half will be employees (although – depending on how valuable they are to the company – probably with significant equity of their own).

But … what *is* “appropriate”? What’s normal? In an annual salary (including some level of bonus) how do you balance cash, equity, vesting, and options? I’ve worked in startups where the directors were paid the average wage for the anyone in employment (circa $60k at the time), and their upside came through having higher allocations of options / accelerated vesting at year end and in bonus. I’ve even worked at one startup where directors were paid much less – around the level of a high-end graduate-salary in their respective professions (which caused some issues of its own). Those were both companies with very very young staff, though – in each case I think only 1 in 10 of the staff were over the age of 30 (including the directors – which, again, caused some issues of its own).

So, when putting together my spreadsheet, I tried to find details on “normal” levels for startups (whilse being very aware that every company – and, more importantly, every investor – has a different take on this; don’t assume this is standardized – it’s all negotiable). I found a lot less data than I expected, and in the end I created reasonable estimates based on the salaries people of the right level could guarantee getting themselves elsewhere, and factoring in a positive opportunity cost for the fact this is a startup where they’ll get to do a lot more cool stuff than elsewhere, and I ignored the equity levels. That was OK for my needs back then, but I’ll need to do it properly soon.

StartupCFO, to the rescue…

And then I spotted this 2007 report of compensation / salaries for executives in IT and technology startups, courtesy of Mark MacLeod (who blogs at TheStartupCFO). This was very useful, and having a quick skim through, I noticed a few takeaways that I thought I’d blog now for future reference

Cash Compensation

• Base salaries for core execs are all very close to $150k, only big difference is that CEOs get a lot more ($215k)
• Averaged across companies, execs in all positions hit approx 2/3 of their bonus targets (very interesting when evaluating how much YOU might earn from your contract, or from the other side: when evaluating how high to set targets for your execs)
• Core execs all have a bonus that is 25-30% of base salary, big difference is Sales (but not marketing), who gets over 60% of base as bonus, and CEO/COO, who gets 40% for leading the company (?)

Where Companies Locate Talent

• Compared to average, Investors are more likely to refer / choose the CEO and/or CFO
• Compared to average, CEOs are less likely to refer / choose the CMO, CSO, and CFO (i.e. the sales/marketing side, and the finance side – interestingly, all of which are roles that traditionally fall on the CEOs shoulders in early stages; maybe they’re less keen to lose them?)
• Obviously … CEOs are less likely to refer CEOs (hey, want my job? here you go!), and massively likely to refer “President/COO” (due to the often ultra-close relationship between CEO and that position) – no news here

Equity for Execs

• President/COO position has massive discrepancy between average and median (this backsup to my theory that these two titles hide some very different meanings of the roles at different companies, and is part of why I discount the president/COO as being too vague in all the other results)
• When hiring a CEO, expect to give them 5% equity
• When hiring any other core exec (CFO CTO CMO CSO) expect to give them 1%-1.5% equity
• CTO and COO do a good job of aggregating some extra equity after being hired to the company, most other execs never get any more
• Most companies giving equity to execs when hiring them do it in the form of incentive stock options (two thirds) or non-qualified stock options (one seventh)

Severance

• CTO’s get the worst severance packages of any of the core execs (interesting given how in all other measures they tend to do in the top tier of the core execs – why? do they tend to be less inclined to leave, or be not so good at negotiating severance?)
• CTO and Head of Engineering are also the least likely to have any severace package at all (hmm…)

Organizational Structure (which execs do you even have?)

• Everyone has a CEO (duh!)
• Most have a CTO (duh!)
• CFO’s suddenly become VERY popular as soon as you raise a second round of funding, and remain so for future rounds
• Slightly more companies start with a head of Sales than a CFO, and although it switches round (still only small difference) when that all-important 2nd round funding comes in (and a CFO is foisted on the company, or the amount of money being dealt with simply now demands a dedicated senior exec to handle it) … if the company goes to future funding rounds, then the CSO / Head of Sales becomes massively popular – practically everyone has one! (i.e. the company becomes secure, no longer a startup, growth and profit becomes primarily through plain sales, like normal companies)
• Founders that were other execs tend to transition to becoming Head of Business Development as the company grows and goes through more and more funding rounds (no surprise – it ain’t a startup any more, so they get replaced by people more experienced with corporates; they also know the market/business better than anyone)
• Companies tend to shed their founding CEO – although a good third of them hang in there to make the company a massive one, with four or more rounds of funding
• Companies tend to retain their founding CTO’s, if the CTO survives the first round of funding

Dilution

• CEOs tend to start by owning almost half the company, even after one round of funding (less 10% – they probably sold 20% to an investor, losing 10% off their 50%, going down to 40%; the rest coming out of co-founders shares)
• Other core execs tend to start with a lot less – around 20% for the CTO, for instance (I think this is being skewed: we know all companies have CEOs, but where they are a 2-founder company, the other founder will vary among the core exec roles. So, CEOs averages get disproportionately more benefit from the 2-founder case; CTOs are often present in companies with 3 founders, hence starting with 20% – this suggests that in those cases, the CEO is also starting with 20% after first round funding)
• If the company goes to 2nd round funding (i.e. its doing well, becoming a real company), then the median ownership levels out at around 5% for each core exec – but a small cadre of CEOs hang on to a lot more, dragging the average up to 10% (c.f. above comment about skewing in the 2-founder case)
• Companies that go really big, and reach four funding rounds, the least well-off CEOs bottom out – the 25th percentile drops from 5% equity to a mere 2% equity – but the good ones all suddenly cluster tightly around %8 (I suspect this may be skewed by 2-founder companies reachign a 4th round that is more like the 3rd round for other companies? Reaching a 4th round of funding is pretty unusual)
• For those same companies, something odd happens with the core execs – the average equity ends up above the 75th percentile (is this because they have to pay really high equities to attract talent good enough to join someone else’s company instead of starting on their own? I have no idea, just guessing)

Anyway, go read the report for yourself – but some of the above figures (the real conclusions, rather than my random observations ;)) are useful enough for me to use directly in future as rules of thumb.

Death to proprietary Grammars!

In my first attempts at writing Korean applications, before I had any font rendering up and running, and with no special XML editor to hand, I had a simple but nasty problem: how do you store Korean characters persistently? I wanted to have to type out the vocabulary once and once only, and re-load it in multiple applications.

I knew lots of theory about how unicode “might” work, but also knew a lot of it was poorly implemented in practice, so I tried to avoid being dependent on everything working “as it is supposed to”. Instead, I went with a simple hack: I took the “standard” transliterations used in English/Korean today – a,i,o,eo,u,ya,yo,yeo,yu etc – and used them as an intermediate language that I could:

1. write out to an ordinary ASCII file
2. read in from an ASCII file
3. guaranteed readable *correctly* in every IDE, tool, editor etc (everything speaks ASCII…)
4. 100% correctly translate from this into Korean for display
5. 100% correctly translate into this from typed Korean characters to check that the player typed the “correct” translation in-game

But…that’s pretty nasty to write a grammar for, and yacc and lex and friends were still horrendously under-documented last time I checked (NB: years ago at University, back when the smorgasbord of Compiler Theory was still in my head, these apps were merely tricky to use, but I could manage. In the years since, as the knowledge faded from the front of my mind, and I’ve had reason to re-use those tools, I’ve found them a complete nightmare. The last few times I needed them, I actually didn’t use them at all and knowingly wrote *bad* source code that I knew to be buggy, fragile, and I even knew was taking me substantially longer to write than it would have taken just to use the tools. Why? Because they are so obtuse and weakly documented that I gave up all hope of working out / remembering how to use them. I felt pretty guilty. I also felt very frustrated. I hope things have improved by now, but I’m trying to write these Korean games as rapidly as possible, and didn’t want to risk the loss of time finding out)

So, I took the short-cut, and converted the standard transliterations into a context-free grammar (because context-free grammars are excessively easy to implement parsers for, by hand, by humans). This means I have a bunch of vocab files with things like:

“ngaan1 n1yeong haa s2ay ngyo”

where the real transliteration would have been:

“an nyeong ha say yo”

Similar enough to be workable, but confusing and, frankly, starting to get irritating – I know I’ll have to fix it sooner or later (assuming I ever want anyone else to write their own vocab files), and it’s such an ugly hack, and definitely not the best way to do things long-term.

Although, incidentally, there was an minor beneficial side-effect to this proprietary grammar: by accident, I ended up learning my consonants in Korean better – I learnt by accident which can conjoin together, which can be doubled, which are single-only, etc. This is mostly because I had to explicitly make each different letter unique in my grammar, and then whenever writing out vocab – or debugging my games – I had to remember what I’d named each letter, and also which letters were transliterated as one latin letter (e.g. h, which is only ever alone), and which as two latin letters (e.g. s which can be single or doubles, leading to two letters in my grammer: s1 and s2)).

But the time has come to “fix” this: my font rendering is, dare I say it, pretty good now, with my applications happily switching back and forth between conjoining jamos and single-ideograph rendering pipelines on the fly, and with auto-detection of fonts (they find the prettiest font you have installed when they startup, and adapt to use that one – or pop up an error message to tell you to go install some Korean fonts).

And now the fun starts. There’s only one correct way to do this: store Unicode characters directly in my vocab files (this is practically the raison d’etre for the existence of Unicode; it excels at doing this well)…

Unicode, unicode everywhere, but ne’er a char to read

…and this is where I had some good news, and some bad news.

Good news: Eclipse’s ultra-simple XML editor not only fully supports typing unicode Korean characters directly into its editing window, and automatically render them in a Korean font, but it even automatically correctly saves the entire XML file with whatever encoding you specify in the first line of the file (it notices when I change that line and silently changes the save format when I next save! Rocking!).

(NB: I thought this was one that I’d installed manually, but when I tried to find out what the name was and who wrote it so I could give them a link here, I could only find references in Eclipse’s plugin list to a generic, Eclipse-provided, XML plugin. Anyone want to confirm/deny?)

I had assumed I’d need to go and buy a commercial XML editor to get full unicode support (unicode support being something that most apps do “partially” these days – c.f. my first post on writing Korean apps, and the detailed look at how Microsoft’s unicode fonts get all the conjoined jamos wrong, so that they won’t even render Korean :( ). But instead, I just type direct into the IDE.

Although…I can’t type Korean characters in Windows yet (sadly, Windows comes with this functionality uninstalled by default, and has to be installed off the original CD – but my Windows CD is several hundred miles away :(). However, using Character Map, which is part of the base windows install, I can get it to type them, and then I can copy/paste them into the text editor, and mostly get by for now.

Bad news: Java’s standard libraries corrupted the unicode characters when reading them from disk; in some cases, they even outright refused to load the files at all (SAXParseException’s being thrown for invalid file data) … which was what gave the game away in the end. This took me a long time to figure out … it wasn’t until I started experimenting with different UTF encodings that I saw the parser crashes and worked it out. The root cause was the last thing I suspected: depending upon a very minor change in how you invoke it, the XML parser from the standard library completely ignores the encoding of the file. Argh.

Various exceptions that can be thrown that are symptoms of this problem (all depends which encoding you’ve used):

• Exception in thread "main" org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed.
  	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
  

• Exception in thread "main" org.xml.sax.SAXParseException: Content is not allowed in prolog.
  	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
  

Or, if you use UTF-8 encoding, you just get gibberish printing to the screen, such as this:

For reference, once I fixed the problem, the same code rendered like this (as I intended):

This is bad. Really bad. You get no warnings about this. Also, as far as I can remember, the way I’ve usually seen this library invoked in all the hundreds of times I’ve seen it in source-code on the web and in books and tutorials … is the way I was using it – which simply isn’t correct. It works in some situations, but it assumes too much. So long as you only ever read and write XML with US-ASCII, and only ever live in America or England, you’ll probably never even notice. The moment someone starts giving your app a 100% valid perfectly-formed XML file which just happens to have an encoding different from the one that your JVM uses (based on your OS settings and language settings) … BOOM!

This is documented in the library docs – as soon as I realised it was the parser doing something it shouldn’t be doing, it took literally only a couple of minutes to find the ref in the docs, see the problem, and fix it. Here’s the documentation:

org.xml.sax
Class InputSource

The SAX parser will use the InputSource object to determine how to read XML input. If there is a character stream available, the parser will read that stream directly, disregarding any text encoding declaration found in that stream. If there is no character stream, but there is a byte stream, the parser will use that byte stream, using the encoding specified in the InputSource or else (if no encoding is specified) autodetecting the character encoding using an algorithm such as the one in the XML specification. If neither a character stream nor a byte stream is available, the parser will attempt to open a URI connection to the resource identified by the system identifier.

So, where I had this line of code:


xpath.evaluate( "vocab/*", new InputSource( new FileReader( vocabFile ) ), XPathConstants.NODESET );

I had to change it to this:


xpath.evaluate( "vocab/*", new InputSource( new FileInputStream( vocabFile ) ), XPathConstants.NODESET );

The first line asks the Java standard library to automatically do byte-to-character conversions – and the JVM will typically buffer its reads from the hard-disk, providing (potentially) much better performance. The second line does raw byte reading from the hard disk, with no buffering. Java programmers who care about performance generally never use the second approach, unless forced to. And, in general, the first approach is the “right” one, because it causes the JVM to correctly perform all the character conversion too.

But in this case … raw bytes are the only way to go.

IMHO, this is a flaw in the XML parser – I would have expected it to at least notice when an incompatible encoding was being specified and signal an alert, perhaps output something to stderr? Or even throw an exception – if you get an incorrect encoding, that’s a pretty big sign that incorrect data is being fed in, and “do nothing, but crash a few thousand instructions later” doesn’t seem to me to be the most appropriate response…

Conjoining revisited – more valuable than first thought?

I mentioned in my first post the concept of Conjoining Jamos – a system of rendering Korean ideographs/glyphs by assembling them from the individual letters that make them up (which works because Korean is an alphabet-based language, but the letters have a more interesting positioning scheme than Latin’s right,right,right-a-bit-more, etc). I pointed out that Microsoft’s Unicode fonts that provide Korean characters are fundamentally broken and can’t render conjoined characters at all (the tables of metadata inside the font itself have the wrong information). A commenter pointed out that in practice conjoined jamos may rarely get used anyway – instead, nearly all applications simply calculate the pre-made ideograph (because Unicode can have hundreds of thousands of “letters”, they’ve actually worked out every possible combination of letters into ideographs, and put ALL of them inside Unicode. Cool).

And, for completeness, I added an implementation using these pre-baked characters (which actually render correctly even with Microsoft fonts!). Lovely. Ah. But, when adding some new features to my game, I realised that maybe I *have* to use conjoining jamos. How the heck do you hilight individual letters within an ideograph if you’re NOT using conjoining jamos?

I would guess that in every situation where you can hilight text, you probably need to use conjoining jamos – which means a large percentage of computer applications. I’m not entirely sure (I can think of ways you could hack around it) but conjoining seems the only sensible way to do it.

All *I* want to do is change the colours of individual letter-groups within the ideographs. Because I’ve written a new minigame: words and phrases fly towards you, and you have to type them in Korean to nullify them before they collide with your avatar.

I haven’t worked out how I’m going to do this yet – I don’t have any fonts that I can really use. I need a font that is:

• Pre-installed on every windows PC, or easy to install
  • Only Microsoft can pre-install fonts on windows, and they don’t pre-install ANY Unicode fonts. If you have MS Office, that automatically installs some unicode fonts, so … “partial”
  • For everyone else, I recommend UnBatang, which I’ve been using. It’s free, but sadly until/unless I find a license I can’t include it in the game – you have to download it manually
• Includes all the letters, and renders them correctly
  • You may think this is guaranteed – but no, Microsoft’s fonts seem to be broken for the conjoining jamos. Non-conjoined characters render perfectly, but you’re out of luck with conjoining.
  • UnBatang renders ALL the characters correctly – but the conjoining jamos it has are extremely ugly, so low-resolution that they’re almost impossible to read a lot of the time