This category contains posts about Devember, a little contract with developers everywhere to spend 30 days writing code, blogging about it, and sharing it with the public. Learn more at http://devember.org.
The code change for today is rather short due largely in part to the time of year; It was time to start doing some holiday chores like getting Christmas cards ready, as well as putting up some more Christmas lights to be more festive.
Nevertheless, code was still written, although not what I had intended.
Today I spent a small amount of time with some engine tweaks and changing the debugging controls that I implemented in Rx. This allowed me to implement some actual game play mechanics, which progressed nicely.
For the engine side, what I did was go through all of the classes and explicitly indicate that every method that doesn’t return anything returns void. This has no impact on the generated code at all, although I guess it would tell the compiler if you tried to assign a value to a function.
More importantly, WebStorm makes wildly incorrect assumptions about what a method might possibly return if you don’t say it returns anything and then you use Control-O to override a method. For example, it might decide that the function returns undefined, or it might assume it returns nothing. This causes it to mark up the code with weird return types and also include a call to the super method that calls return.
Today on Devember day 10 we finally run into the (probably common) issue of finding the time to write code for at least an hour (easy) and write a dev entry about it (sometimes tricky).
Today’s repository contributions involved adding some new engine functionality and creating a new Entity subclass which represents the pill bottle in the game and which will hold the bulk of the game logic; or at least, the parts of it having to do with the pill segments in the bottle contents.
Today on Devember day 9 we have, more or less, exactly what we had yesterday, but now including way more encapsulation (that’s kinda funny in the context of a Dr. Mario clone). I spent a little time with a piece of graph paper crudely sketching out a few different virus shapes to use as simple polygons, and then plunked the values down into a series of arrays so that they can be rendered.
Once I had that working I set about taking the code that I had previously set up in the Scene class to do all of this stuff while testing. As a result, the visuals look more or less the same as yesterday, except that the colors are a bit more muted and there are now viruses as well.
Unlike the original Dr. Mario, which (as far as I can remember; too physically conservative to check at the moment) has a different virus model for all three possible virus colors, I implemented three virus “models” and they get randomly selected whenever a virus is created. A little visual variety!
Second Devember Dr. Mario clone Screenshot
I also “fixed” the issue I discovered yesterday regarding the Event structure being KeyboardEvent or MouseEvent depending on the type of event it actually is, which I did in the engine branch and then merged over to the other branches (and got a conflict because I’m contravening good sense here). Unfortunately as I type thing I’m fairly sure that I actually only fixed it in one place and not both (i.e. Stage but not Scene as well), so I probably have to revisit that.
Now that I’ve finished the engine port from JavaScript to TypeScript, it’s time to actually try to use it for some game development prototyping so I can evaluate if the new workflow is better or worse than using JavaScript.
I waffled around a bit trying to determine what I should spend the rest of the time prototyping and then decided that instead of doing a full prototype (which I probably could not finish in the time allotted due to time constraints on my part) that I should try to do two or three prototypes of different sorts of games to gain more insight into different aspects of using the engine in TypeScript with the new tool set.
I’ve noticed at least one person doing Devember mentioning doing a Tetris clone from a tutorial. I’ve made Tetris a couple of times in the past, so that seemed like it might be a good place to start. However I’ve recently been playing a lot of Dr. Mario on my 3DS, and that’s a puzzle type game that I like more than Tetris and which I’ve never done a clone of before.
So, the first thing I’m going to try to prototype is a simplistic clone of Dr. Mario, which I’m calling Rx (or ℞, if your browser supports that particular unicode character in whatever font this WordPress theme is using). I’m not sure at this point if this will come out to be a full clone of the game, or only of the parts of the underlying engine that revolve around the pill bottle mechanics of gravity, match finding and so on. We’ll have to see how the time progresses.
To this end I’m using a new branch named rx in the repository that’s purely this particular aspect, which will get merged to the master branch every night when I make the Devember update. If/when I move on to the next prototype, it will be in its own branch as well and brought back into master. This way, along with the tags that I’ve been making for the repository state at the end of each day there’s also an individual record of the different portions of Devember.
So far the only steps taken were to start in with some dirt simple rendering of the different kinds of possible pill segments, and set up an invisible pill bottle to hold the segments that will be used in the game. The bottle contents are currently filled up with random segments in random (poorly selected) colors.
I managed to work with this new code base for less than 10 minutes before I uncovered a couple of bugs in the new TypeScript port, for which I have created an issue on GitLab (since I’m also using Devember to evaluate that as well).
I’ll finish up with a screen shot of what things look like at the end of the first day of prototyping on Rx. Just a simple invisible pill bottle filled with a random assortment of nonsense segments in eye watering colors. It’s interactive in that when you click on any of the segments (including an empty space) the segment type switches to the next segment type in the type list.
First Devember Dr. Mario clone Screenshot
The engine port is now fully complete (tagged as version 0.1.0 in the repository) and so the next stage of my Devember can commence.
The solution to the issues I was looking at yesterday ended up being simpler than I expected it to be (fresh day, fresh head and all that jazz) but still not quite as ideal as I would have liked. There may still be a better overall solution, but this one seems like a good compromise.
The technique that I was using in the JavaScript version does not carry across very well to TypeScript without some severe restrictions on the way you lay out your code, but at the same time it was also less than ideal because it kept a bunch of objects around that it didn’t need to.
This is yet another day on which the amount of code checked into the repository is lacking due to time spent working on research and the best way to tackle things. Even though I’m working in a separate branch in the repository I like to keep an outstanding large change like this that I’m not sure of as an outstanding change so that I can use the facilities of my IDE to easier track where all potential changes are.
The situation as it currently exists is this:
A bit later than more recent Devember posts, but work was still done. Weekends are bad for development with so many errands to run and chores to complete, but better late than never. This is just a preview of what’s going to happen (probably) in the last two weeks of December when I’m on vacation and in holiday mode full time.
Today’s changes all revolve around refactoring in the Stage class.
Making up for the lack of actual coding done yesterday in lieu of researching and benchmarking, on Day 4 things have moved along at a brisk pace!
All of the classes now have appropriate (or mostly appropriate; time will tell, I guess) member variable visibility. Member variables are also now marked up with leading underscores so that they can be exposed with less ugly names.
The amount of actual code I managed to spit out today for the time I had set aside for Devember is not a whole lot, although I did get some changes in place.
For the most part, day 3 has been taken up with various research elements. In particular, the tooling I’m using, and benchmarking.