We are glad to be able to finally show you the video preview of our app for iPhone. Work keeps going on and we hope to be able to release the app soon. In the meanwhile stay tuned, more updates will come soon!
We are glad to announce that the big of the app is done. We are now working on some special content (which will still require some work both server side and in the app), but we will be able soon to show you a preview of the finished product. We are working on a little preview video that we will post soon, so stay tuned!
In the meanwhile, let’s scratch a little the surface of the story, with an short introduction to it. More on this will come soon too!
Have you ever felt inside of you that you are just destined to nothing? That you are not special, that you have a mediocre, inexorable and oppressing fate in front of you?
Liam is a boy that feels all of this, he knows that fate cannot be changed and that every effort is useless and doomed to fail. When the king of Centaurs will unleash a war between the seven tribes of Dagradia to control the Essences of Creation, Liam will be involved against his will in the saving of the sacred sword Animah-Argenti, the only hope for the realm. He will be dragged in events of which he didn’t want to know, that will let him soon meet Abadir, a boy which, unlike him, believes that fate does not exist and that each of us is the master of his own destiny.
Since the bulk of the server side for The Path of the Seven Millennia has just been completed, we would like to spend a couple of words on the technological stack of our choice and our experience with it so far.
Our project involves quite some work on the technological part as well as on the artistic one, since we do not only have to build the final product, but we also need an infrastructure to deliver the content and some tools to create such content. We do not have many resources though, since we are only two: the artistic guy, which is the creator of the comic and handles everything involved with it, and the technical guy, which handles all development (and which is the author of this post). We both are working full time on other jobs and dedicating to this project our spare time, so time is a really scarce asset for us and we have to use in the most efficient way.
Our stack of for the project is as follows:
Let’s see why we made such decisions and what the benefits are.
It can’t be denied that one of the main point who influenced our decision to deliver our product to iOS devices is proficiency in the platform. I am mainly an iOS and Mac OS developer with quite some experience it both platforms now. But this is not all, of course. If we felt that another platform offered more opportunities, we would have invested in that one instead that iOS.
Speaking marketwise, iOS is the platform that offers more opportunities to monetize our product. Even if Android is catching up regarding the raw number of users, it looks like iOS users are more willing to spend money on apps and content. I have no first hand experience in Android, but this is definitely what I keep reading around: Google set a different mindset in the Android market, which tends toward “free apps”.
Another issue Android developers have been complaining lately is that the Android market is sub-par in respect of the App Store and search in it does not even work that well (ironically, being built by Google this should be one of its core feature). There wasn’t even a way to browse it from a computer until recently Google fixed this.
Technically speaking, we believe iOS is better fitted to our vision too. Through Core Graphics the OS offers a lot of handy capabilities for image manipulation, which are crucial in our app. Even though Android could have similar capabilities (again, I’m sorry but I don’t have experience in it), what I’m pretty sure is better on iOS is animation support. In the company where I work daily, we develop both iOS and Android apps and often we build versions of the same app for both platform. I’m confident that we have very good Android developers, but what I see is that iOS versions of the apps we build tend to be better from this point of view, because what I do (animation-wise) in a couple of lines of code on iOS is not easily doable on Android (again, I don’t think to be a better developer than my colleagues working on Android and I believe them to genuinely be good developers, but usually when they see some animations we put on iOS their main reply is “we can’t do that in Android, or at least not easily”).
Another issue Android has is fragmentation, even though a lot of Android developers are arguing that it’s not a problem. Well, from our point of view it is. The first type of fragmentation comes from different hardware. Of course Android offers facilities to handle all these differences, but still it’s much easier to design the app for a fixed aspect ratio of the screen than to design it to be adaptable to different ones, and as a developer I’m happy I don’t have to take them into account during development.
Then there is also fragmentation in the OS version, caused by (some) carriers that refuse to provide updates even for devices that have been released recently (or worse, there are some devices that are released with an old version of the OS). We are too small and we already have a lot of work to do to make our project possible, we can’t afford to spend time on these issues, even if they are really as small as the Android community claims them to be.
So, given all these considerations, we think that iOS is the best bet for us. If our project will be successful as we hope it to be, of course we will take the Android platform into consideration.
Another advantage that iOS brings is that it is derived from Mac OS X and shares with it a lot of technologies.
Unfortunately our content does not spring out from a magical source, but it must be created as well: after all it’s the content that is our real product, while the apps are the medium to present it. The comic is produced in the “old-fashioned” way: it’s drawn on paper by hand and then it’s digitalized and colored. What comes out of this process is not directly usable in our apps, unfortunately (also because the comic was initially intended for the print market). We need tools to specify the format of the content and to define how transitions and effect happen. We must then be able to preview the result during the creation for the necessary adjustments.
Here is where the similarities between Mac OS X and iOS come to the rescue. The two platforms not only share the same language (Objective-C) but share a lot of core frameworks. There is some code I wrote that works on both platforms without changes, and this speeds a lot our development cycle.
To be a little more specific, our Mac app uses Core Graphics to do some image slicing and manipulation, and this code is used on iOS as well without modifications. Moreover the Mac app uses Core Data to save the documents containing the final versions of comic chapters. We have a small preview app that runs on iPhone which uses the same Core Data model and almost the same code as the Mac app, so we can preview the final product without having to load the content to the server (which uses a different data format).We just connect a device to our Mac, load the saved document on it, and we can immediately preview the final product. Very handy.
After the content of an issue has been finalized, we upload it to the server using another tool which again shares some code and the Core Data model with the content creation app. The tight integration between the two platforms really makes a difference for us, cutting a lot of development time and giving us some tools that probably we would not have had on other platforms due to the time required to develop them. This increases the overall quality of the final product, too.
A little final bonus: if we decide in the future to release something for the Mac App Store (we are already thinking about it), we will be able again to reuse a lot of our codebase.
The apps, the content and the tools are still not enough: we need an infrastructure to deliver the content to users, since through the App Store we can only deliver the iOS apps. On the server side the considerations are different: we need something that will be able to scale in case the demand for the content will be high (we really hope so!). At the same time of course, the cheapest and easier to use it is, the better.
Putting together these requirements with my recent interest in functional programming and Lisp, I decided to go for Clojure on Google App Engine. The latter provides a scalable infrastructure which is, for one, free to experiment with and for which we will have to pay only if the demand will be high enough to go over the quotas (in which case we will be happy to pay, since it will mean we will be doing very well!). In that case the price is still cheap compared to other solutions I saw around the web. The deployment on GAE is also very easy and you don’t need to have any experience in managing a server infrastructure.
Clojure is a wonderful language, even though I must confess that my skills in it are still not good at all. Lisp has always been a very powerful and expressive language and Clojure takes the best out of it, with some more nice added features. I’m really impressed by how easy was to build our server side part. Functional programming seems really suited for web development (our server is mainly a REST api called by our apps). After using Clojure for a while, I’m starting to look at OOP with different eyes.
To ease development I’m of course using some Clojure libraries. For the REST implementation I use Compojure (which is built on Ring). To interface with GAE I use Appengine Magic. This library still has not reached the 1.0 release, but it does already a very good job to interface with GAE without using directly Java from Clojure.
The only rough edge I found is that, in the current version of Appengine Magic, most of the GAE functionality does not work in the interactive Repl. Every time I change some code I have to compile the code and run it on the development server, which requires some time and means you lose one of the main benefits of Clojure (which is fast interactive development).
Apart of this flaw, which probably will be solved when it will be more mature, I think this library does a really good job overall (I’m using it to interface with the GAE Datastore and with the Blob Store).
This are the reason why we chose this stack for our project. We hope that our experience with it will help others in their decisions.
Now we will go back on the development of the apps. We hope we will have some preview of our product soon. Stay tuned.
As first post in our blog, we would like to spend a couple of words to give you a better idea about The Path of the Seven Millennia project.
The introduction of new mobile devices like the iPhone and the iPad gives new opportunities to deliver content in new and exciting ways. Comic books are not an exception. Unfortunately, for now, we see producers that just digitalize their existing products and deliver them on these devices as they were on paper.
This, in our opinion, is a flawed approach. These new devices are different from paper, where there are some rules to be followed. These rules completely change when changing the medium.
Take the design of a comic book page, for example. The placement of the panels on the page is not casual. It might follow different styles, but the main point in laying out a page is directing the flow of the story like in a movie. People are usually not aware of this, but the dimension of the panels on a page, as well as the details in the drawings, dictate the speed these panels are consumed by the reader: if you want a scene to go fast, like a fight scene for example, you design smaller panels and draw inside of them less details. This makes the reader’s eye stop on them for a shorter time span. Conversely, if you need a slower paced flow, as when you display a big landscape that conveys a sense of majesty, you use bigger and more detailed panels, to the point of using a “splash page”, which is a page completely occupied by a single big panel with lots of details, or even a “double splash page”.
This, in a small device as the iPhone, is of course not possible. On that small screen you can only display one panel at a time, so you somewhat lose the chance to give pace to your story. You can work on details, but the panel will always fit the screen, so you lose the ability to change it’s size, which is really important. Even on a bigger device as the IPad, the bigger screen might not be enough to fit a whole page in a readable way.
On the other hand, you also gain something. Your comic book is not statically printed on a piece of paper anymore, so you gain new tools like transitions, animations, visual effects, sounds and music.
This is what we want to do with The Path of the Seven Millennia: explore these new tools to change the way comic books are experienced on these new media. This first project is just a first step in this direction and we believe that this could be the starting point to explore this new and exciting way to tell a story. We hope you will find it exciting as we do.
