Have you tried Vaadin? It's like writing a Swing application that compiles to the web. Or at least it was when I used it last, about 7 years ago.
62 karma · joined July 20, 2007
It would be interesting to know what the unsubsidized price is and if it ever comes to the west.
The e.Go Life has a similar concept but does not seem to be able to compete on price or battery capacity.
What I'm interested in mostly is if I at least got a significant performance gain from chosing SpriteKit over Unity.
As a customer I very much prefer the pay once model, too, but we really seem to be a minority these days.
We sold about 45 copies of the game so far in almost half a year, but when we made it free for a weekend we immediately got 200 downloads without even advertising.
So let's see what happens with free2play. We are going to make all levels but the first one an in-app purchase and maybe a few characters. There will be no consumable IAPs because I hate them with a passion.
All previous buyers are going to keep the full game btw. Apple makes it surprisingly difficult to implement that, but anything else would just not be right.
I spent most of my free time the last 1.5 years to make this 4-player iPad game together with my brother (developer) and two cousins (graphics).
Considering that it was our first Swift and SpriteKit project (my dayjob is programming business applications in Java), I am pretty proud of the outcome. It even got some reviews (one with a 92% rating!).
The only problem is, we completely underestimated how hard it is these days to get downloads for an old-fashioned "pay once for the whole thing" game. Currently we are in the process of converting it to a free to play model, hoping that more people try it. Wish us luck!
And do you have a source for your claim that only 1/4 of recent asylum seekers were refugees?
Apple really screwed up SpriteKit badly in the new version. I'm experiencing almost all of the problems mentioned in the forum.
A Java web application however needs very little additional memory per request-handling thread, which makes its memory footprint much smaller when many parallel requests are involved.
100 ms for the home page in my Java app might not be great but, considering that 7 separate queries to the database are involved and that it runs on a very weak server, I think it is quite decent. And because of the use of concurrency (threading) there is a good chance that 100 ms for a single request translates into more than 10 requests per second. But I still wouldn't call my webapp lightning fast. I was calling java lighning fast because in my case I still get decent response times on bad hardware and with an inefficiently programmed application (7 db requests that could as well be cached and only refreshed every hour or so).
You are absolutely right about the rails app however. The 1 second response time is not normal. I just measured again and suddenly I get similar response times as for the java app. The server must have been under heavy load before (maybe the automatic backup). I admit that my quick measurements are not very representative and apparently not reproducible reliably, but still: about the same response time as the Tomcat with no database activity and on a faster server. I also checked a different rails project of mine running on an equivalent VPS. Pages where two simple database request are involved, which, when directly invoked in psql, take 15 ms, take 300-400 ms to load if not cached.