I switched from PHP to Java after few months to add new features to Jetrix (Java QetriX :-) Those switches always hurt: different environment, different editor, different coding habit requirements, different debugging. But this time it was... different.
Even after quite a long time with PHP I didn't have much struggle, because core parts of QetriX has been already made and my current task was mostly to update converters, datastores and modules. And the only difference between QetriX in Java and PHP were in variable types - hints and "arrays".
This was my main goal with QetriX, to unify programming. I know QetriX isn't optimal and it even may take worse parts of each language, but ultimately it saves me time otherwise spend on Stack Overflow and it works quite well actually.
I know I mostly make rather simple CRUD stuff nowadays, but even than it's wonderful to see, that QetriX is capable to make it work smoothly only with general QView, QList and QForm components.
I've always tried to do the most optimal solution, but sometimes it's obviously pointless. On the other hand, QetriX is for me a nice way how to teach myself new languages in the futures. Perl? Python? Ruby? Well, probably all of them, one at a time.
Wednesday, July 29, 2015
Monday, May 25, 2015
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! :-)
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! :-)
Tuesday, April 21, 2015
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.
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.
Tuesday, April 14, 2015
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.
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.
Subscribe to:
Posts (Atom)