Some of you may wonder, why QetriX Apps are managed by "Apmin". What a weird word!
Well, not really. I like jamming words together, so what will be result of application administration, or app admin for short? Appmin. And "apmin" is just one "p" away, not mentioning that it looks like "admin", only with fallen "d".
I like a word "admin" for administration, but /admin/ may be too obvious for unwanted visitors. I don't expect QetriX to be hugely popular, so HTTP 404 on /admin/ may be a good thing :)
Monday, January 26, 2015
Sunday, January 18, 2015
Mravenci as QetriX WebApp
6 years ago I made a remake of quite popular Czech card game Mravenci (inspired by Arcomage) for Pocket PC, written in C# for .NET Compact Framework. Because CF is a subset of regular .NET Framework, it worked on PC as well.
I was recently contacted, if there's an Android version of the game. I replied there isn't, because I tried and failed - as my experience with Android is shallow. But it got me thinking and then it hit me.
As I mentioned earlier, I have some experience with IBMWorklight MobileFirst Platform Foundation. Mobile side in the platform is based on Apache Cordova, which basically is a fullscreen chrome-less WebView (mobile browser), displaying the single page app, written in HTML, CSS and JavaScript.
I really like the idea, so I tried to make the game this way. All platforms have support for such apps, so I created basic WebView app in Swift and Objective-C (iOS), Java (Android) and C# (WinPhone). It worked really well and the final app is so tiny!
Everything is based on QetriX structure, with DataStores, "content" dir and such. I took the liberty of developing the game in Firefox on my PC. The development was nice and smooth.
Of course I had to reengineer some major stuff. Because of different aspect ratios, I had to make the whole game fluid (all sizes are percentage based). It may get little bit distorted on 3:2 displays though, so I added media queries.
Also the original graphics was really low-res, which looks OK, but the blurring isn't that good so I decided to recreate everything possible in HTML (like cards). Besides I didn't want to make gray version of each card (when player doesn't have resources to play it) and grayscale filter doesn't work on Android 4.3 and older.
The sound is made by HTML5 Api, but causes some troubles, which I consider acceptable: it sometimes plays up to 1 sec later than it should and sometimes doesn't play at all.
You can download the game from Google Play and iTunes Store.
I was recently contacted, if there's an Android version of the game. I replied there isn't, because I tried and failed - as my experience with Android is shallow. But it got me thinking and then it hit me.
As I mentioned earlier, I have some experience with IBM
I really like the idea, so I tried to make the game this way. All platforms have support for such apps, so I created basic WebView app in Swift and Objective-C (iOS), Java (Android) and C# (WinPhone). It worked really well and the final app is so tiny!
Everything is based on QetriX structure, with DataStores, "content" dir and such. I took the liberty of developing the game in Firefox on my PC. The development was nice and smooth.
Of course I had to reengineer some major stuff. Because of different aspect ratios, I had to make the whole game fluid (all sizes are percentage based). It may get little bit distorted on 3:2 displays though, so I added media queries.
 |
| Mravenci. Build your castle to 100 or destroy opponent's castle. |
The sound is made by HTML5 Api, but causes some troubles, which I consider acceptable: it sometimes plays up to 1 sec later than it should and sometimes doesn't play at all.
You can download the game from Google Play and iTunes Store.
Thursday, November 27, 2014
Re-iterations
It's a quarter since last post? Wow, the time flies, when you're busy! :) I made a serious progress with QetriX PHP, but I spent a lot of time by "re-iterations".
In the past, when I had a little feeling something isn't right, I left it behind for when I have a time to think about it in the future and it somehow haunted me and ultimately I had to redo it, no matter how much time passed and how deeply the feature was integrated. Many times it was really painful and for this reason the core code have been rebuild from scratch a lot and I don't want to do it again any more.
So this time, whenever I have this feeling something isn't right, I start to take care of it immediately. And if it's a tough one, I start to build around it - hoping the idea will come when I see it in context.
As you might think, this really does take a lot of time. But IMO it's time well spent (and that's what I've been doing a lot since July).
Some of bigger decisions are still in front of me, like how to nicely handle QForm data or how to make (and name) opposite side of Renderer - a parser that accepts somehow encoded string (JSON, XML, picture, Word document...) and fill a component with the result.
It's a tough to find the fine line between automation and customizability. I made some quite ingenious solutions in the past, when the something adapted almost automatically with just a few lines of code, but it was a real pain, when customer needed (not wanted) it to behave or look differently.
There's no universal solution, so one of my current motos for QetriX is "just enough". If the way QetriX uses isn't suitable for you, write your own Renderer, or please use something else. It may sound harsh, but it's a way out of the feature loop, which leads to overblown code.
In the past, when I had a little feeling something isn't right, I left it behind for when I have a time to think about it in the future and it somehow haunted me and ultimately I had to redo it, no matter how much time passed and how deeply the feature was integrated. Many times it was really painful and for this reason the core code have been rebuild from scratch a lot and I don't want to do it again any more.
So this time, whenever I have this feeling something isn't right, I start to take care of it immediately. And if it's a tough one, I start to build around it - hoping the idea will come when I see it in context.
As you might think, this really does take a lot of time. But IMO it's time well spent (and that's what I've been doing a lot since July).
Some of bigger decisions are still in front of me, like how to nicely handle QForm data or how to make (and name) opposite side of Renderer - a parser that accepts somehow encoded string (JSON, XML, picture, Word document...) and fill a component with the result.
It's a tough to find the fine line between automation and customizability. I made some quite ingenious solutions in the past, when the something adapted almost automatically with just a few lines of code, but it was a real pain, when customer needed (not wanted) it to behave or look differently.
There's no universal solution, so one of my current motos for QetriX is "just enough". If the way QetriX uses isn't suitable for you, write your own Renderer, or please use something else. It may sound harsh, but it's a way out of the feature loop, which leads to overblown code.
Tuesday, July 29, 2014
GeoQetriX Map
I presented the idea of GeoQetriX more than a year ago, but finally I got the urge to make it done. I'm gonna to redo my website about "USA thru Czech Eyes", so I wanted some interactive maps. I found some JavaScript libraries, based on Raphaël, and using SVG paths for countries.
So I downloaded some countries. And some more countries. And this country, this one, and... but at least one of them was missing. So, as one might expect, it brought me to an idea to do it on my own (to have them all). I'm gonna to need them anyway at some point, so why not now?
Because Google Maps JavaScript API is truly extraordinary, I didn't think twice how I'm going to do the editor.
So. I put some geographical points (using markers) on the map and stored them in the database. It were basically major country border joints and major shore features. In the very first version, the editor generated SQL code, which I executed manually in HeidiSQL.
Then, of course, I had to stop being lazy about DB support and created a script to generate JSON for markers on the map, later for lines as well. Markers and lines both have a type, with semantic meaning (shore border, inland border, division border...).
Except for the Google Maps I created a secondary output, into generated PNG. For debug purposes I assigned different colors to each type (blue for shore, red for inland, green for divisions, gray for subdivisions). And started clicking. And clicking... But after a while I was quite excited about the (still work-in-progress) result:
Along the way, I adjusted something here and there. The editor has to be very easy to use, because I guess I'm gonna spend quite a time in it. I want to have major roads and railroads, along with water.
I also had to use a projection for the map output. I chose Miller (EPSG:54003 - World Miller Cylindrical), because personally I like it the most; for me it's a "classic" view.
Before the final alpha-stage map I did everything I planned to. Like placemark settings with a list of attached lines, with possibility to change type of the line, delete selected line or add a midpoint to a line.
The last thing is to define, what's on each side of a line. At first I thought it will be the smallest unit possible (like a county, neighborhood or even a plot), but I kept thinking that querying the whole country may consist of thousands of geo-units.
After a while I realized, that the other way around it would be much better, without losing much fidelity. So at this point I'll define a country (or sea/ocean) for each line, if it's a country border. Then state borders, county borders and so on. If I would like to draw a country, I simply ask for all lines with it's ID.
So I downloaded some countries. And some more countries. And this country, this one, and... but at least one of them was missing. So, as one might expect, it brought me to an idea to do it on my own (to have them all). I'm gonna to need them anyway at some point, so why not now?
Because Google Maps JavaScript API is truly extraordinary, I didn't think twice how I'm going to do the editor.
So. I put some geographical points (using markers) on the map and stored them in the database. It were basically major country border joints and major shore features. In the very first version, the editor generated SQL code, which I executed manually in HeidiSQL.
Then, of course, I had to stop being lazy about DB support and created a script to generate JSON for markers on the map, later for lines as well. Markers and lines both have a type, with semantic meaning (shore border, inland border, division border...).
Except for the Google Maps I created a secondary output, into generated PNG. For debug purposes I assigned different colors to each type (blue for shore, red for inland, green for divisions, gray for subdivisions). And started clicking. And clicking... But after a while I was quite excited about the (still work-in-progress) result:
 |
| World Map |
I also had to use a projection for the map output. I chose Miller (EPSG:54003 - World Miller Cylindrical), because personally I like it the most; for me it's a "classic" view.
 |
| 1:1 cut of Europe |
 |
| 1:1 cut of USA |
The last thing is to define, what's on each side of a line. At first I thought it will be the smallest unit possible (like a county, neighborhood or even a plot), but I kept thinking that querying the whole country may consist of thousands of geo-units.
After a while I realized, that the other way around it would be much better, without losing much fidelity. So at this point I'll define a country (or sea/ocean) for each line, if it's a country border. Then state borders, county borders and so on. If I would like to draw a country, I simply ask for all lines with it's ID.
Subscribe to:
Posts (Atom)