I couldn't find a nice all-in-one article about getting HammerJS to work with Angular 9 so I thought I would put one together.

The idea is that the Angular 9 @angular/platform-browser package comes with HammerJS event bindings prepackaged in HammerModule. However, as indicated in a footnote in the angular documentation page for the HammerModule, you still have to install hammerjs and include it in your project yourself or else the event bindings simply do nothing.

First, install HammerJS by running npm install --save hammerjs to install the hammerjs package in your project.

Then we need to properly require the hammerjs library in our app.module.ts and import the HammerModule from @angular/platform-browser:

//app.module.ts

import { NgModule, Component, InjectionToken, Inject, PLATFORM_ID} from "@angular/core";
import { BrowserModule, HammerModule } from "@angular/platform-browser";

// ... (other imports)

@NgModule({
  imports: [
    // ... (other modules)
    HammerModule
  ],
  // ... (other NgModule options)
})
export class AppModule {
  constructor(@Inject(PLATFORM_ID) private platformId: Object){
    if(isPlatformBrowser(this.platformId)){
      
      // here we require the hammerjs dependency in a block that will 
      // only run if we're actually in the browser. Otherwise the 
      // hammerjs code will cause failures in server (SSR) mode.

      require('hammerjs');
      
      // ... (other browser-only code)
    }
  } 
};

Now you can get started using touch-device gestures in your web applications such as swipe, tap, and pinch. The complete list of events cam be found on the official HammerJS documentation page.

// ...in my.component.html
<div (swipeRight)="onSwipeRight($event)">
  SWIPE RIGHT
</div>

// ...in my.component.ts
public onSwipeRight(event: Event){
  // ... react to right swipe here ...
  this.router.navigateByUrl('/my_page');
}

I hope this saves some people's time! I found a bunch of articles about transitioning HammerJS from other Angular versions, but none about getting started with HammerJS in Angular 9+.

If you were helped by this article please consider following us on twitter, facebook, youtube, or instagram.

So a lot of people ask me why we're not using Unity, and there are so many reasons that I realized I should just put it all into a blog post.

The License Terms

The most obvious reason is of course the Unity license terms. We much prefer to stick to 100% free and open source (FOSS) software, which of course means that we're fully free to use the software commercially without having to worry about paying license fees to anybody. As well, here at WindFish we tend to make our own contributions to open-source projects; not just to give back to the community but also to ensure that the FOSS software we use meets our needs while also allowing the general public to enjoy those improvements which we've made.

Best Practices

The much more important reason we've stayed away from Unity is that as a framework, it doesn't really adhere to any software engineering "Best Practices".

Lack of Formalized package/dependency System

In most other languages (for example Ruby, Javascript, Python, Elixir and Go) there's a defined structure for package dependencies. This means that your project (and indeed, what ends up in your VCS) contains only your source code. The rest of your dependencies are downloaded and installed automatically via commands that come bundled with the language itself, for example: npm install in Javascript, gem install in Ruby, pip install in Python, mix deps.get in Elixir, or go get in Go. This is so common that it's become a nearly-universal part of software development.

In Unity instead of having the typical package-dependency structure, you get "Assets" which are bought from the Unity Assets Store. These "Assets" adhere to no formalized structure; they typically consist of a mix between game assets (like textures, meshes, materials) and also raw source-code, with itself adheres no particular predefined structure. Instead of enforcing a strict separation between your code and its dependencies, in Unity when you download an asset it all just ends up in your project folder, intermixed with your own code.

Version Control Hell

Firstly, This creates for an ugly situation when it comes to using version control systems like git where ideally you would only want to version the code itself, which is what git was designed to do. A much better practice for versioning large assets (textures, meshes, materials and the like) would be to use a 3rd party storage service like S3, where one can also version the binary assets themselves. All the while, keeping the binary assets and the actual source code separate.

Modularity (or lack thereof)

Secondly, the lack of separation between your project's code and the code of its dependencies is a violation of the "separation of interests" principle of software development. It's widely recognized in the field that maintaining a high degree of modularity is always the ideal way to construct a project of any size. In Unity a developer is faced with the proposition of having to modify the source code and structure of the dependencies they choose to use in an attempt to make all of the projects source code conform to some consistent pattern. This wouldn't happen in any other language.

Since most developers understandably choose not to do this, as their application grows they end up with very un-modular code, where much of the logic in the game becomes inextricably tied together, forming what has come to be known "spaghetti code". As an application grows large, spaghetti code actively impedes development, which is an effect which grows worse over time.

Truly modular applications which adhere to the "separation of interests" principle are agile, meaning that because the modules aren't logically tied together one is able to change and/or replace them easily. Spaghetti code tends to mean the opposite: a change in one module can cause problems in a number of other modules because they are all logically tied together in ways they shouldn't be. This leads to development taking much longer than it should have to.

This is not only due to the fact that Unity lacks a truly modular and formalized package dependency system, but also because it doensn't really enforce (or even suggest) an over-arching structure for the source-code in a game. As such, lacking any formalized framework or guidelines to follow, it's an extremely commmon problem in Unity that as a game grows large it becomes increasingly harder to develop.

One great example is this job-posting from Finji games in which they're struggling so much with their Unity-based spaghetti code problem that they're looking to hire a new team-member just to "come fix it". This loss in productivity ends up costing real game studios real money.

The UI Problem

Really the reasons listed above represent the most important reasons why we've chosen not to use Unity, but there's still more.

At WindFish Studio, we're writing a game which is extremely heavy in UI (User Interface). In simulation/strategy games we have to communicate a lot of data to the user, which can easily get out of control and become overwhelming unless we have a sophisticated UI engine with which to do it. At present, the most used virtual machine on earth is the web browser (or "navigator"), which specializes in presenting highly-customizable "rich" user interface to the user, while also providing a truly agile framework to the developer. These are sophisticated front-end UI development technologies which themselves have been in development for over twenty years.

As well, in recent years it's not uncommon for a multiplatform games to run on extremely variable screen sizes. A single game might need to run on a screen as small as a smartphone, scaling all the way up to an 8K television screen. The UI in the game has to be responsive to those changes in screen-size. Leveraging traditional "web" technologies ends up being a fantastically simple way to overcome these issues without having to re-write lots of code or many versions of the same UI.

While there are tools that exist in the Unity ecosystem to overcome these problems such as NoesisGUI, they are specialist tools as compared to what can be acheived with more common "web front-end" technologies. They lack the ample development community which has grown unbounded during 20+ years of front-end web tech proliferation.

Attack of the Clones

Finally, using a tool like Unity can really improve development time if your game mechanics fit into a predefined "template" of previously-seen games. For example: if you're making a platformer game or an FPS game, Unity might be a great choice for you to save time in development and avoid writing a lot of code, although the previously-listed problems in this article continue to be very real.

These games are mainly "content-focused". Meaning the mechanics and basic concept of the game is already well understood having been seen many times in the industry, and the real focus on the game is it's art and level design. The main challenge in development of a "content-focused" game is mostly about the development of the assets themselves and the integration of the final product into a single cohesive package. The actual code in the project is usually reduced to a minimum.

For this reason it's become increasingly common for game studios to purposefully choose to pursue ideas that don't actually contain any unique mechanics or play-concepts, specifically so that they can use an engine like Unity and reduce the entire game development to "content development". Writing code is difficult, and hiring a large software engineering staff is expensive.

However, the final result is that we're seeing a flood of games in the industry which lack any real originality in terms of game concept. It's almost like there's thousands of games where the basic idea is the same or perhaps minimally tweaked, but then it's been "re-skinned" over and over with different art and sound. To me, this represents a decline in the overall creativity of the industry.

Too many game studios are choosing which projects to develop based on financial motives, instead of creative motives. At WindFish Studio we're trying to buck the trend.

Final Thoughts

Since our game concept doesn't really fit into any pre-defined game "template", using Unity wouldn't really have gained us much savings in development time. Rather, we would've often found ourselves fighting against the framework to try and express the mechanics that we wanted to express at the scale which we wanted to acheive. For this reason coupled with the many reasons listed above, it just wasn't the right choice for our studio.

What’s up world! Thomas here, proudly announcing that I am the newest member of the WindFish programming team. I’ll be relocating from Barcelona to Tenerife on March 21st to start working with Alex on the wireframes and mockups for Hannover!

The interview process was tough but quite enjoyable. I love a good challenge! The code problems Alex hit me with were definitely not easy. I’m glad that I took some time to study and brush up on my algorithms beforehand. The problems are designed to test one’s understanding of the fundamentals of programming. An in depth knowledge of algorithms, data structures, and asymptotic analysis are a must!

Upon my hiring, Alex gave me access to the specs for Hannover. I can tell you all right now that thisgame is going to be epic in scope. We are talking about a level of detail and immersive gameplay that has never been seen before. It is truly going to be a grand strategy experience!

We are still looking for team members! If your interested in interviewing fill out the contact form on the website. More to come soon...

I've waited a long time to really go public with details about Hannover. Now that I have the website up I want to begin to use it to show the public just what it is that I've been working on, and allow you guys to track my progress. I've been asked many times to show screenshots, mockups, and demo videos, and I've been paying attention! This dev-blog will serve that precise purpose. I hope to use it to show not just the current state of development but also to provide a window into the future; to let you guys see where this is going.

Hannover is purposefully a quite ambitious project. The videogame industry of today tends to focus on simple ideas with simple gameplay mechanics. I'm part of a large demographic of gamers that crave for something more. I want complexity; I want a game that allows me to be really creative in my play-style. I want a game that forces me to really think, and refine my strategy.

Between August of 2016 and July of 2018, with some major hiccups and breaks in development, I've been working on the visual part of the game. Hannover is a game in which the fundamental play-pieces are map regions (see video below). Thus, the graphic part of the game consists of a map which functions in a similar way to Google Maps, insofar that it's a map which one can use to reveal more levels of complexity at higher zoom-levels. Unlike Google Maps, which focuses heavily on road maps, the Hannover map only displays regions.

In the game you control a nation, and as in-game time marches on, the simulated nations will be attempting to grow larger and stronger via an endless series of wars, annexations, coalitions, consolidations, and administrative changes. On the map, this behavior would be reflected by nations swapping territories between themselves. Indeed, if we look at a world map throughout history, this behavior is exactly what we would see.

In the interest of not making this first post too long, I won't go too deeply into the game mechanics yet. However, I did want to share some of the core ideas surrounding one important part of the game: the in-game macroeconomic simulation. In Hannover I'm trying to build a realistic world-scale geopolitical simulation, and it simply wouldn't be possible without also simulating a realistic version of the world economy.

At any given moment in the real world, €X euros is worth $Y dolars. How does the market determine that number? The answer is shockingly complex, and requires a non-superficial knowledge of how the global economy actually works. I had to spend weeks studying macroeconomics to begin to make sense of the wider picture of it all. The game specification is 30 pages long; 3 of those pages are bibliography. It was a shockingly complex task to attempt to lay out these concepts in such a way that the game could still be fun to play.

I had the amazing luck to discover an amazing Ph.D paper from the Univsity of Münster, in Germany. "A Multi-Agent Non-Stochastic Economic Simulator" by Ulrich Wolffgang lays out the idea behind creating a virtual macroeconomy that ends up behaving in a very similar way to the real world. In the video below, we see these ideas in action. The project computational-economy accompanies the paper, putting its ideas into a working simulation. My intention is to adapt and port a lot of these core ideas to integrate them into the game.

This will allow a sophisticated level of play never before seen in the strategy genre. Players will be able to wage economic warfare with the same level of detail as military warfare. Not to mention, these two core systems will be inextricably linked in the game, just as they are in real life! Elevated military spending will have consequences that reverberate throughout the domestic economy of a given nation. Maintaining a large military will be expensive, possibly causing you to enter into deficit spending, which would naturally lead to inflation and elevated taxes. Then the player will have new problems; namely, a population which is unhappy about having to pay high taxes, and a currency which is worth less on the international market.

That's all for now. I'm currently in the process of hiring my programming team, and so I hope that the updates to the game (and consequently, to this blog) will become exponentially more frequent. Now that the website is finished, we'll be working exclusively on finishing the first wireframes and mockups, which I'll be sharing here when they are finished. This should give you a better idea of how this will all look when it's finished, and the overall direction this project will take. Stay tuned!