Qules, Unite!

I've always wanted to make a computer game. I got my two cents by Ants (Mravenci), but I had many other ideas.

In my early programmer years I had a bunch of games in my head and after some time some of them started to be quite thinked out. Unfortunately I didn't have the skills to bring it to life, I tried and failed many times in many programming languages.

When a decade passed by with no signs of completing any of them, I decided to take good parts from all of them and put them into a single game, which I will finish. I thought about a perfect main character and decided to go with a simple sphere. It will be easy to make, with lower polygon count than person or creature (although a nice sphere is often quite hi-poly) and it can roll really fast, which can alter as a car ride.

In 2013 I attended MS Fest in Prague and saw Tomáš Slavíček's lecture about MonoGame (follow-up of dead XNA), so I gave it a try. It was OK, but still... making 3D game was beyond my skills. I kept it in 2D, but wanted 3D inside. MonoGame was exactly what I wanted and I started to see how complicated making of a 3D game is. Keeping the code small is absolutely impossible. The same problem I had with WebGL, which was a hot topic at that time.

I didn't want to use some pre-made 3D engine or game makers, because I saw some of them and they felt overcomplicated, with many features I probably won't use or need and will run slowly on some machines.

During that time I thought about a name for the game. I somehow decided all stuff I do will start with "Q" and I many, many years ago I felt in love with a name of an old Czech game "Koules" (for UNIX, OS/2 and Linux). It's plural of "koule", which means "sphere" in Czech. I like the fusion of a Czech word with English grammar. After many variations I ended up with "Quly" (and "Qule" for the spheres).

About two years after my tries with XNA my younger brother showed Unity. It was quite funny, when I described my idea of the game to him and he put the RollerBall Character into the scene, which was pretty much it :-) My first tries were OK, but I was quite lost and didn't really know how to do stuff. I was otherwise engaged at that time, so I decided to continue when Unity 5 is out.

The release happened few months later. I really appreciated YouTube tutorials, especially those from Unity team itself. Unfortunately, some of them still used legacy features, which has been often replaced by newer approaches in Unity 5. Later I often followed the tutorial and spend few hours of fiddling and tweaking, but ultimately (and often accidentally) found out it's legacy and therefore not recommended for a new game. Damn!

My brother gave me a nice jump-start and I started to build a learning version of Quly. I always do it this way, so I'm not affraid to mess it up, because for the real thing I'll start again from scratch.

Thanks to great capabilities of Unity I was able to concentrate on gameplay and features only. Many things are already made, like collisions, physics, vector maths and tons and tons of other stuff, so I didn't need to bother with them (for example in XNA I had to deal with all of them).

I realized how foolish I was for rejecting pre-made 3D engines. I'll never be good enough to make an optimized game engine by myself! There's such vast amount of things it needs to be done and of course done properly.

In Unity I simply make a short script, attach it to a GameObject and test it. It's really fast, straight forward and I love it! Also, C# is my favorite programming language and the system of scripts and stuff in Unity really suits me. And cooperation with my favorite 3D software of all times, Trimble SketchUp Make, puts me on cloud nine! :-)

Converters

I suspect converters to be my second greatest idea for QetriX after Particles. In the past, QetriX used Renderers for output in desired format (HTML, JSON...). You simply handed over an object, like QList, to a Renderer of chosen kind and you got the output. It was simple as that.

But I faced the opposite situation - I have a string in some format and I need to convert it to an object. Imagine FileSystem DataStore, the data could be XML, JSON, flat file etc. I don't want to have FileSystemXml DataStore, not to mention Xml is for Soap DataStore as well. And I don't want to duplicate the code either.

I tried to create "coders", with encode and decode method. Therefore I was able to call a DataStore, the output process thru a coder.decode, then create an object and render it. Maybe it sounds complicated but in fact it was quite simple. Just few steps to make.

Well... no. It didn't work as well as I expected and I didn't like the name - coders. So back to a drawing board. I was working on a HTML coder, when the obvious came. I was dealing with conversion of a HTML code to an object and back, which in many aspects duplicates what Renderers are for. But Renderers are one-way only and I need two ways.

Even Renderers were in QetriX from the beginning, the new idea was beyond that. I renamed coders to converters (convs for short) and created few basic ones, like QForm to HTML (qform-html), Wiki to HTML (wiki-html). I was particularly happy about the second one, because before that it was as an add-on library. This way it makes much more sense.

I'm even able to make converters like PNG to JPEG, XML to QList, Image to Thumbnail or Integer to String.

To be honest, I can see the concept (or architecture, if you will) of Converters may be fundamentally wrong, because most functions are in fact converters, like "Math.add" converts two numbers into one number (sum total), and input/output types are not consistent, which is difficult to manage and impossible to unite into e.g. Interface. I may think of some boundaries in the future though.

Qarate

I like watching TV series, my list of favorites is quite long. I also like to re-watch them, from time to time, but sometimes only good episodes. I had a list of good ones on my personal wiki, but it was boring to note them each time (and when I watch multiple episodes in a row, I simply forget to note it and then I forget which one was the good one). So I discovered Trakt and was happy about it. Rating was quick and easy enough for me to actually do it.

One day Trakt creators upgraded the website and rating system was still in "to-do", so now I had nowhere to rate. I tried to google some replacement, but without any success. So, out of frustration, I added a new table "rating" to my personal wiki. It allowed me to rate not only episodes, but anything else - movies, songs, cars, vacations, etc. I was so pleased I thought this might be a nice service for others to use as well.

The biggest drawback was, that I had to enter the thing I was rating, mostly episode identification. I don't want my users to add anything. First of all, it's not quick and easy. Second of all, it will get wrong and duplicate (sorry, users...). It would require something, where all such data already is. Oh, wait!

I'm building qb for several years now and it will be the perfect marriage: a big database with "everything", plus a website, that allows you to rate anything. Sounds great.

I looked for a fitting name, which starts with "Q" and contains "rate" and in the shower (which is a common place for ideas for many people, according to one article I read) I thought of "Qarate". You can pronounce it as "Karate" (martial art) or "Carat" (unit of mass for gems and pearls). Therefore users may form dojos and level as gem rarity and belt colors (like blue diamond is more, than black sapphire).

Rating system will consist of 5 grades with matching score for that entity: +2 (excellent), +1 (good), 0 (meh), -1 (bad) and -2 (terrible). User may have limited +3 grades (the best), which can be used to mark notable things of it's kind, like one episode in a TV series season.

And I can imagine that rating of episodes may be relative to a rating of the whole series - +2 episode in +2 series is better, than +2 episode in +1 series. But user won't need to know that, it's a technicality for internal statistics and leaderboards.

box-sizing: border-box;

One of the biggest pains in a web development, apart from vertical centering (except for inside a table cell), is a W3C box model, which doesn't include padding and borders into the width. You can't use "padding: 10px; width: 100%;", because the element will be 20px wider, than the parent element.

Fortunately, in CSS3 there's box-sizing property. Default value is "content-box", which behaves as the W3C model, but if you set the property to "border-box", it solves the problem with padding/border and the width. I noticed almost all major CSS frameworks adds this property to every element, like this:

* {
    box-sizing: border-box;
}

In the past (in terms of internet it was more like an ancient history), comparable pain was an old Internet Explorer's own box model concept, which included border and padding into the width (so  basically like "box-sizing: border-box"), whilst Netscape Navigator (ancestor of Firefox) followed W3C standards.

Side note: I don't like Microsoft doing stuff his own way, but this was actually better, than standards.

Anyway, when designing a web page you had to hack this differences, usually by using two divs instead of one. Outer div had the 100% width, inner div had the padding and border. Width of the inner div has been calculated automatically. And this wasn't the worst hack at the time, webdesign was often close to a witchcraft :-)

Microsoft added "standard mode" (now we call it "almost standard") into IE6, but kept so called "quirks mode" default and switching of those modes has been guided by DOCTYPE. This changed with IE7, where W3C mode became default (according to my test in IE11 dev tools).

Now, if you use HTML5 doctype <!DOCTYPE html>, you will get the best results - so use it always!

And about the vertical centering, you can use display property with CSS2.1 value "table-cell", so even div can behave like a table cell, with working vertical-align: middle, like this:

.verticenter {
    display: table-cell;
    vertical-align: middle;
}

But don't forget you should to make it a proper table! So parent div will have "display: table-row;" and it's parent div will have "display: table;". Happy styling!