CGE Tech Stack

CGE Tech Stack

In todays post, I would like to share some insights about the technology behind the CGE engine and the various assets that are used to build it. Please excuse my rusted english writing skills, being located in europe Im not used to written english that much anymore. It should be noted at this point that no codebase, engine or construction set is used. Although I worked with Unity, Unreal, Game Maker and Construct 2 in the past, my enthusiasm for these engines is limited. Maybe thats the main reason why I never finish a project, as the amount of extra effort is enormous and the results are often not better in comparison. But with 40, I count myself to the old-timers of game programming and software development in general – and we never used “engines” back in the C64 or DOS days.

While Im on it: If my life had gone a different route about 15 years ago and I would write games for money today, I would switch to any of these engines immediately (well, any but Construct 2 – sorry Scirra folks!). That’s mostly because using one of the modern engines saves you so much hassle and time, and delivering a finished product within time is so important when you try to make a living from it.

But, Im really about to let my mind wander, so lets get back on topic:

Backend
So, the CGE backend is written entirely in plain PHP with a traditional mySQL database for data storage – nothing else. Im using a lot of custom classes and functions accumulated in the past years. Code that has been written and tested partly while developing games and partly for my main business – I might shed some light on that later on, for now it’s enough to note that it’s related to software development and the internet.

I also have a little bit of experience with “backend frameworks” like Phalcon and the Fat Free Framework, but I always come to the same conclusion: If I would work for a company like Upjers and had to manage thens of thousands of players, I would insist on using such a framework. But for a part-time indie developer thats several numbers too big in terms of complexity and project management. Together with two friends of mine (a diploma engineer and a master of science – if that means anything), we also did a few tests in a technical related area: We tested several professional online-shop systems (like Magento) against a inhouse solution. And although the shop systems beat any homebrew code in regards of features and convenience, a hand-written solution tailored to a specific task will always be faster and more performant (in fact you don’t need a diploma to realize that, a bit of common sense is enough).

In additon to several utility classes, CGE makes use of a really simple database abstraction layer and a tiny template and caching system. Both are short (just a few lines), quick and easy to maintain/update. That summarizes the backend of the CGE project:

  • pure PHP
  • pure mySQL
  • simple database abstraction layer
  • simple template & caching system
  • a collection of inhouse utility, security and helper classes
  • my personal interpretation of the MVC pattern to separate code, design and data

There are a few open-source plugins that Im using for the backend like PHPMailer and a few others. Not worth mentioning here.

Frontend
The frontend is your typical HTML output flavored with a bit of CSS and Javascript. I make little use of modern HTML5 or CSS3 besides some minor features, but one of the later iterations of the combat system found in CGE games might rely entirely on HTML5. There is one single luxury that I grant myself in regards of the frontend – and no, it’s not jQuery.

Im using a lesser known “frontend-framework” referred to as Framework7 , available as open-source and maintained by Vladimir Kharlampidi. Im following it’s development since more than a year and Im very happy how things turned out so far: F7 is a framework that allows you to build iOS and Android Apps, so it’s concipied “mobile first”. But a developer can use it for a traditional web-app as well (that’s what Im doing with CGE). As I am a Mac user myself, I fell in love the with the GUI immediately as F7 mimics the iOS GUI 1:1. Im also tempted to create a true web-app (using web sockets and Node JS) at a later stage. But for now, it’s perfectly fine to use it as “client” for the traditional browser game engine that CGE is. This framework also saves me from using jQuery (which is good, I just don’t like it) as F7 provides all the cross-browser / cross-platform functionality right out of the box. It also features all GUI components, a custom DOM model as well as a simple styles cache and a template engine to take things even further.

  • Framework7 – mobile first framework (iOS/Android)
  • SwiperSlider (included in F7)
  • Template7 (included in F7)
  • Dom7 (included in F7)
  • Caching / Preloading (included in F7)
  • Cross-Browser / Cross-Platform iOS/Android look and feel
  • Mobile first controls

There is more to the frontend besides F7, but thats mostly open-source code snippets and plugins like “animate” and a few others. Not worth mentioning here.

Conclusion
Writing your own engine is hard – very hard – and it might not be worth the effort. I have decided for this route and it might not be your opinion, which is totally OK. There are several reasons for this decision though and those reasons define exactly what I like so much about browser-games:

  • Cross platform compatibility
  • Cross device compatibility
  • No downloads (instant availability)
  • No patches or updates (always up to date)
  • Not dependent on AppStores
Comments are closed.