Devember post mortem

So of course as this entire section of the blog is devoted to, in December 2015 I did Devember, for which my goals were the following:

  • Learn the TypeScript language to try and ease the pains of writing object oriented code in JavaScript for the web (specifically games)
  • Evaluate the workflow for using TypeScript in WebStorm, especially as it compares to using JavaScript
  • Get more familiar with GitLab as an evaluation of how well it integrates with my work flow (primary reason: it allows private repositories for free, which GitHub does not, but also I’m looking at locally install-able solutions).
  • Get back into the swing of game development again after a long hiatus

The outcome of this entire operation was a game prototype I called Rx which was a simplistic Dr. Mario clone. The “final” version is posted at itch.io:

[Edit: In December 2016, Nintendo swept through itch.io and threw DMCA take-down notices at anything that looked vaguely Nintendo related, so I deleted the project from itch.]

 

By final I mean that I have advanced the prototype as far as I’m going to. I never intended to flesh it out into a full game, and with the exception of the changes in scoring it doesn’t really have anything new to add anyway. The code is MIT licensed so hopefully someone can use it to learn what to do (or not do) to construct a game like this.

I did add a couple of extra commits to the repository on January 1st to fix a small bug (really just an incorrectness) and include preload progress for posting on itch, though.

TypeScript Thoughts

I have to say that on the whole I’m pretty happy with how much faster and easier everything comes together using TypeScript. Of course I’m not using all of the available features (most notably require-able modules) but for the workflow that I was trying to accomplish, I’m not too worried about that.

With more work I could make each discrete component into its own module and have each one require the appropriate code, which would take care of all dependencies automagically. From what I understand there are various ways to take such a structure and come up with the single Javascript file that I was aiming for, but for the scope of projects as I’m working on them, this seems like overkill.

As I’m basically just working on simple game prototypes here, I don’t want to fiddle around with a lot of boiler-plate build system type code; getting away from that is part of the reason I went with web prototypes in the first place.

As someone already familiar with other OOP languages, about 95% of all syntax in TypeScript came very naturally. I think the only stumbling blocks I really had were a couple of missteps in how namespace works, as well as the lambda syntax. In this regard I’m sure that would not be a stumbling point if I was more familiar with that syntax (I’m still using Java 7, for example). Again, this is nothing that really held me back at all.

The only down side really is the compiled nature of the code, and that’s not much of a downside, especially in regards to all of the benefits it brings. It’s really only a problem where you get used to just save-reload-test with JavaScript, which doesn’t necessarily work with TypeScript, since there is a slight delay between when you save and when the compiler notices and rebuilds.

On this point I did notice that the smaller the number of files that need to be compiled, the faster that this process becomes. When I introduced the commit that split the engine and game source into separate compiles, turnaround was a lot faster in this regard.

I’m sure this could be worked around with explicit builds but I didn’t obsess about it over much during my Devember time.

WebStorm and TypeScript

I’m not sure how long exactly WebStorm has supported TypeScript, but at this point the support just sort of feels rudimentary. That said, in some ways JavaScript is easier to use but on the whole the TypeScript support is still nicer to use in the IDE and everything is a lot faster.

As in all JetBrains platform tools, I spend a fair amount of my time working around bizarre usability bugs (most notably it’s absolutely god awful word wrapping for comments), but there are enough value adds that it’s still a net win overall. Certainly WebStorm is better with code completion in TypeScript as compared to JavaScript.

For example, JavaScript support in WebStorm relies pretty heavily on JSDoc comments to help it determine what types are expected. During code completion this tends to mean that you get to see every possible method of every possible class, even in cases when it should know better. This doesn’t happen in TypeScript (or not as often) thanks to the explicit type information the language provides.

There are up and down sides to this though, and the support seems sort of half complete or just unfinished. Where in JavaScript you can get WebStorm to insert a skeleton JSDoc comment for things, when using TypeScript it is hit or miss whether it adds an @constructor or @private annotation, for example. I was unable to decipher any logic as to why it thinks it has to sometimes but not every time.

While working through a couple of code samples that came right from the TypeScript handbook, I kept getting all kinds of warnings about code being invalid, which was not the case because it works just fine AND is clearly outlined in the language specification  This is what leads me to believe that the support is still in early beta stages; if it’s meant to be fully (or almost fully) mature, that would be kind of worrisome.

Speaking of which, one of the things I like about JetBrains platform tools is their in depth code checking (Inspections), pointing out where probably bugs are. I had to turn off a couple such inspections because they trigger too liberally, and unlike other languages (e.g. Java, JavaScript) where it is possible to insert a comment to disable a comment for a particular line/class/file, the TypeScript support is all-or-nothing for a few of them. I don’t know if this is still just in development or it requires more scope access than the tools are currently capable of figuring out or what.

Still, when it comes to cross platform tools for doing this kind of editing which are (for the time being, anyway; I’ve heard rumblings) easy to get running and installed even on older machines, it’s still the best thing going that I’ve seen. I have not had good experiences with atom, for example.

All of the above is my own personal opinion based on my use of JetBrains tools such as IntelliJ, AppCode and WebStorm. There may possibly be some user error in setup going on, and in particular I know that I’m way more OCD about how my comments are formatted than probably anyone anywhere, given how long the formatting has been broken without enough people complaining to get it fixed.

GitLab

This one is a little trickier because I’ve never really been large into using GitHub or other solutions (e.g. Gogs) for management of repositories and tasks. Although in all honesty I don’t collaborate with other developers all that often on public code, either.

However, I have been wanting to set up a system such as one of these for my own internal access and tracking, and so I thought this would be a good time to go about an evaluation.

Of course I haven’t really “collaborated” with anyone on this particular project, but I was more interested in the idea of keeping track of issues and milestones, as well as being able to graphically look at changes, which are also aspects that these tools seem to excel at.

Thus far I have been quite pleased with my GitLab experience. I was initially a little worried because as I was setting up the initial repository before Devember started the site seemed to be a little bit up and down. This was not an issue during Devember though, so I’m not sure what was going on there.

I think a little more time is needed for this aspect. I also want to revist Gogs, which had some usability problems the last time I played around with it. There have been several releases since then, so I’d like to see what kind of progress has been made.

Final Thoughts

In the end, I had a blast doing Devember, and I would recommend it to others. I really like the idea of supporting new software developers get started down the track. I still remember my first steps all those years ago and how thrilling it was to write my first programs. Something like Devember really captures that spirit again for me (as does working on Game Development again) so I hope that a large crop of new developers got a similar start.

The hardest part of Devember was coming up with a daily blog of activity. As you can see from the week (or almost) that passed between the end of Devember and this follow up, a daily devlog for a month is perhaps not enough to get into good habits.

Realistically after giving this a lot of thought over the last few days, I think a better way (for me) would be to jot notes into the blog on a daily basis but roll out posts once a week or something like that. I really don’t like to feel like I’m overwhelming people with content updates.

Of course, that requires that I actually settle on a new project. I’ve been spending the last week or so catching up on playing some of the games that I picked up during the Steam sale and getting more in depth with Pico-8 than I was able to (or willing to) during Devember. Who knows, maybe the next little bit will be playing with that. That’s like game dev!