-
Day0
This is the state of the project prior to any development being done for Devember.
-
Day1
This is the project code as of the end of the first day of Devember. Some initial porting has been completed, with some internal code notes of areas to focus on more once the initial porting effort is complete. These should be turned into issues to track them better, possibly added to the milestone.
-
Day2
This is the project code as of the end of the second day of Devember. The initial porting efforts of all classes is now complete, but more work needs to be done before I consider this completely done. Some of the code is a little dodgy in how it is written and can be cleaned up a bit. In particular, there is a real hodgepodge of private vs public going on. The initial code was all public and I implemented the new code as all private except where absolutely neccesary. However the classes should be gone over and given appropriate read or read/write access using property accessor methods. I want to do some investigations to see if there are any performance ramifications. Also I am rather unhappy with how the property accessor and the actual property can't have the same name because I hate "warty" members.
-
Day3
This is the project code as of the end of the third day of Devember. There is not a lot of practical code change here, just a couple of things cleaned up. The bulk of development effort today went into researching the speed implications of using Object.defineProperty() to set up read only properties on objects, since the last phase in the initial porting effort will be to enforce good data isolation. The results of my benchmarks (assuming I did it correctly) indicates that there is no real speed degredation, so plans can continue as planned for tomorrow.
-
Day4
This is the project code as of the end of the fourth day of Devember. Making up for the lack of code yesterday (since so much time was spent doing research), this includes a bunch of commits which are code cleanups. The cleanup is almost complete so we're almost ready to knock that milestone off and call the port officially done, and then move on. The code has been tightened up as far as property access is concerned. Also some other refactoring has been done, most notably in the Stage class. This code uses "instance functions", which are basically functions that capture the "this" context into a hidden variable, so that whenever they are invoked they refer to the appropriate object.
-
Day5
This is the project code as of the end of the fifth day of Devember. The last of the Stage class refactoring has been completed. Rendering is now done via an interface named Render and a concrete class named CanvasRenderer. The stage has a .renderer property that contains all of the rendering methods as they used to exist. This does mean that as of now the code responsible for rendering things has an extra indirection. I'm going to leave that alone for right now and see how things shake out speed and code beauty-wise.
-
Day6
This is the project code as of the end of the sixth day of Devember. There are not a lot of changes here as the main feature being worked on is currently not in a state that I'm willing to check in; that being how entity properties work with regards to defaults being applied. More research needs to be done as to the best way to go about this in TypeScript to create type safety at compile time.
-
Day7
This is the project code as of the end of the Seventh day of Devember. On this day I deem the port to be officially completed; all of the functionality is now present, along with the (few) design changes and tweaks that I wanted to make. The next steps will be to start actually prototyping a game to use the rest of Devember to evaluate how much easier this new port is to use and maintain than the JavaScript version was. Thus far I feel cautiously optimistic.
-
engine-v0.1.0
This is the Official engine version 0.1.0 This represents the initial TypeScript port of the engine with no other modifications.
-
Day8
This is the project code as of the end of the Eighty day od Devember. Since the official port of the engine is complete, it's time to embark on some actual prototyping of some games to see how the workflow changes affect development (better or worse?) The first thing I'm going to prototype is some of the mechanics for a Dr. Mario puzzle game clone. I'm undecided yet if this will become a fully functional prototype or if I will split away later in the month to try prototyping a different sort of game, just to get more experience with different kinds of prototypes.
-
Day9
This is the project code as of the event of the Ninth day of Devember. This is just a re-working of yesterday's code to make it more object oriented, but it does include the notion of a virus (three of them, in fact) as a segment type.
-
Day10
This is the project code as of the end of the Tenth day of Devember. This includes some object refactoring and engine changes. In particular the engine now supports polygon rendering by way of an array of array of numbers. The Point class can now return such an array instance of itself.
-
engine-v0.1.1
This is the Official engine version 0.1.1. o The Scene and Stage class now use KeyboardEvent and MouseEvent instead of Event o The mouse input handlers now return a boolean that indicates if default handling should be disabled or not o The Point class can return an array version of itself and set itself from such an array o The Renderer interface specifies an interface for more easily rendering an arbitrary polygon, and CanvasRenderer implements it.
-
engine-v0.1.2
This is the Official engine version 0.1.2 o Include key codes for number keys o Make all methods in all classes that don't return a value explicitely say that they return void.
-
Day11
This is the project code as of the end of the eleventh day of Devember. Here some small engine tweaks were made, and the Rx protoype now allows for pieces to drop and horizontal and vertical matches to be made, including cascades. More work is probably in order to tune this up a bit and make it less ugly.
-
Day12
This is the project code as of the end of the twelfth day of Devember This is just a simple change which more closely mimics how the game would actually operate in play; instead of a constant drop happening, instead a drop would only be triggered after a match was found, and a match would be found only after the player placed a capsule in the bottle. The current drop mechanic in the bottle is for the cascade action, because it always runs at a set speed. This is not the code that would be used to control the drop of the player capsule in the bottle.
-
engine-v0.1.3
This is the Official engine version 0.1.3 o Add properties to allow access to actor width and height
-
Day13
This is the project code as of the end of the thirteenth day of Devember. The level editing code is tweaked a little bit to allow segment selection via the mouse, and the start of virus population at the start of a level is in. It is currently crude and incorrect, but it generates the correct number of viruses in more or less the correct colors.
-
engine-v0.1.4
This is the Official engine version 0.1.4 o enhance the rendering API to allow for stroked shapes o enhance the polygon API to allow for more complex polygons
-
Day14
This is the project code as of the end of the fourteenth day of Devember. We now populate the virus bottle with a set of viruses that does not immediately cause matches to appear. This does not fully match how this was done on the NES, but probably good enough for now? I'll have to see how I feel about it.