A little news is better than nothing at all. A lack of news implies that a project is dead or dying and nothing is further from the truth with what we’re doing at Brick Mill Games.


Work on creating metadata from the three maps we currently have is progressing slowly, but surely. The Metadata Editor (Viewer, really) is helping Paul with the tedious task of eyeballing his maps and entering a shorthand code for what the map describes. A pleasant side effect of this is that this extra attention to detail has led to the discovery of a few map errors, which are being fixed. There weren’t many, but they were there.

In the future, we will have a Map Editor which will be able to handle both the graphical construction of maps as well as its associated metadata. The plans churn in my psyche, but they will have to wait until we get the base project off the ground.

A Change in Course

While working with and learning Swift to build a game client application was a decent exercise, we decided, after much discussion, to change course once again. The game client will be built to run within the browser and be built using HTML, CSS and Javascript. The primary reason for this is expediency. While Javascript may not be the best language to work with, it has gotten better syntactically and the underlying capabilities of the DOM engines have gained quite a few capabilities. For writing cross-platform, network-aware GUI software, it’s a very good platform. There are certainly worse ones. I can’t believe that we software developers still can’t just write in a common language to a common library and have our software just work on a multitude of platforms. It boggles the mind.

Anyway, the world of HTML/CSS/JS development has changed quite a bit in the last five years. The latest incarnation of Javascript has added quite a few new, useful language nuances that are making the jump easier. Web Component technology is also making development quite a bit easier as well. So, after jump starting my exposure to a veritable sea of new technologies, language features and new frameworks, I was able to tire-kick some technologies and make some solid architectural decisions.

One risky decision that I made, based on watching about a dozen YouTube videos and reading two dozen development websites, is that I’ve decided to write my own Web Components and code “to the metal”, relying on the standard built-in browser APIs. I investigated the AngularJS, ReactJS and Vue frameworks. I looked at StencilJS. I downloaded Google’s Polymer framework. I looked at LitElement and the PWA Starter Kit. While these kits and frameworks and jargon factories do have their uses, after all, quite a few of these projects were born at Google and Facebook, they primarily seem to give experts expert-level tools. The learning curve was steeper than the Eiger’s North Face. Documentation is thin, at best. Most require the installation of Node.JS to act as a local web server. Most require the loading of modules into the local server space. Most have a seemingly endless list of Javascript module dependencies that are required just to write a “Hello World” program. Well, admittedly, not quite. The PWA Starter Kit had a non-trivial example program, but required me, through an automated download process, to download 100+ Javascript modules of unknown, though probably vetted, origin. Nothing about that screams “beginner” or “tutorial”.

My solution is thin, but workable, and, yes, it will grow like the frameworks I just bitched about. My local web server is not Node.JS. It’s a 14-line Ruby script (8 if you ignore comments and blank lines). And I only discovered why you need a local server during my initial attempts at writing Javascript modules: Javascript modules won’t load if you open an HTML file into the browser using “File > Open File…” due to web security reasons (CORS concerns). So I wrote a mini server that works quite nicely w/o all the baggage that comes with Node.JS. So, instead of using “File > Open File…”, or a file:// protocol address, I type “http://localhost:8080/kgTest.html” into the browser’s address bar and refresh when necessary.

As for the Javascript code I’ve written so far, I’ve written 13 source files, 8 of which are components, in less than a two weeks. I’ve learned quite a bit through doing and my code system, apart from a Safari browser bug I found, seems to be working nicely. (I think it’s Safari’s bug. Maybe they’re sticklers to the spec than Google and Mozilla are.)

The TOCS Future: Next Steps

The ultimate goal, besides getting this idea into actual production, is to be able to get it working well enough to get play-testers on board, including the two of us. As deep into development as we are, we’re both itching to play the actual games; that’s how much fun we think they are.

Our first development goal is to have a working game client ready by the Nor’easter XXIV ASL tournament at the end of March. At that point, we’ll be in a position to determine if we go to ConsimWorld Expo 2020 in Tempe, AZ to showcase our ideas in front of a larger audience. These ambitious plans are the primary reason why we’ve both been “nose to the grindstone” and working like mad to ensure that we have a quality prototype to show people.

Steel & Steam

Due to this pressure, and given that TOCS is the primary reason why we embarked on our Brick Mill adventure, S&S and my other game designs are on hold. I still mull over and jot down design ideas from time to time, but those projects are on the back burner for now.

If Only…

Truth be told, in spite of the pressure, this project is probably the most fun, creative, stimulating and fulfilling experience of my professional life. I’ve had quite a few of these game development ideas in my head for two decades or more and it’s nice to see them come alive. Thankfully, Paul and I make a great team and that, more than anything, will allow us to be successful.

If only this was my day job…

3 Responses

  • Ken Guerin

    Hey Jim.

    Good to see you here. It’s nice to know that someone is reading my posts.

    In response to the use of JS libraries, I took a long look at ReactJS, but declined. In the past, I’ve been burned by relying on other people’s / vendor’s libraries so many times that I needed to see something strongly compelling to make the jump. I cannot tell you how many times I wanted to build an interesting, novel GUI widget, only to find out that the library not only doesn’t have support for it, but that the lower-level code infrastructure to support the development of a widget was either hidden or faulty or non-existent. And… when I tried to build my own anyway, it wouldn’t work with the other widgets in the library b/c of some underlying unseen communication mechanism.

    As for your offer of help, sure! While we have three west front WWII modules in various stages of development, the system has room to grow into other theaters and other time periods as well. When we get the infrastructure up, we will be looking for play testers, designers, what have you…

    Stay tuned. We’ll probably be expanding our player circle later this year.

  • laufetc

    Hey Ken,
    Exciting that you converted to JS. I might have recommended ReactJS, but it is even more interesting that you choosing to go really thin. As we discussed on the BoG trip, I would love to help because doing a double-blind game that will run in any browser has been my goal for a few years, especially in my coming-soon retirement. However, I won’t really have much time for one more year until I do retire…
    All the best, and let me know if there is something “little” I can do to help,

    • Paul Chicoine

      If you are retired and have the time and would like to help, we have both development tasks and module development that should be available. We have several modules that need to be completed, and a metric ton of core development work.

Comments are closed.