Research never ends

The entirety of today’s changes are fairly anticlimactic from a development standpoint, but perhaps a little epic from a git merge hell perspective?

The goal today was simple: the engine and game code were compiling to the same output file, but it was time to have it compile into two parts; the engine and the game.

The rationale for this was to make merges easier, but also to speed up game compiles. One of the things that I’ve noticed over the last month (which didn’t surprise me) is that with TypeScript you can’t just save and reload the page; there has to be a bit of a delay there to allow the compiler to notice that things have changed and recompile. Oh, the number of times I mistakenly though I had not fixed a bug only to discover I didn’t wait long enough.

I also wanted to get some experience with using TypeScript that was already compiled to JavaScript in a project, so this seemed like as good a time as any, since the month is almost up.

This process is two-fold; in order for things to work nicely you need to have a .d.ts file (which the TypeScript compiler will spit out for you) which basically provides the type annotations needed to allow the compiler to know what’s going on and you need to let your environment know about it, in this case WebStorm.

In a classic ironic twist I didn’t see coming, the easiest part of this was getting WebStorm up to speed; the setup was simple and more important, actually seems to work. The harder part (such as it is) was generating the file I needed. Or rather, getting it generated in the location that I wanted.

This is where the research thing comes in, because I’ve known all along that you can get the compiler to generate you a .d.ts file via a command line option or a directive in the tsconfig.json file, but what I (erroneously) assumed was that there was some control over the placement of such a file.

It turns out that the TypeScript compiler will only generate the file for you in the same location that it generated the JavaScript file in. I would rather have the definition file generated in the game source directory, but that seems to not be possible without outside work, such as using grunt or some such.

I didn’t care that much at this point, so I just left it generating the definition file in the output directory and referenced it from there.

The other half of the operation was telling WebStorm about the definitions, which it uses for code completion and such. Just putting a reference to the definitions in the tsconfig.json file for the game caused things to compile, but code completion did not work until I added the engine.d.ts file as a library. The only hiccup here was my assumption that this would be added as a TypeScript library; it’s actually a JavaScript library, confusingly.

Just to get a bit of something done on Rx, I did a bit of sound tweaking. In particular, while play testing I realized that I was missing a sound effect. In the original Dr. Mario, you hear a noise as segments drop in the bottle after a match is made, so I added that to Rx. I also added in an extra sound that plays when a match happens that nets you bonus points due to a cascade.

Here’s a little video I threw together showing everything in action, including the audio, which tends to not come across very well in screen shots. I apologize in advance for the sound quality; everything has a wicked reverb on it for reasons I cannot figure out at the moment and I got tired of fiddling with it.

I’m thinking my last day of Devember may involve posting this whole thing online so someone can experience it without checking it out of git, and perhaps also doing a write up of how everything fits together (although the code is abundantly commented). I guess I need to throw some coding in there too, though…