Solarus is an open source Zelda-like 2D game engine. How Zelda-like, you may be wondering ? Well...
I'd call that pretty convincing. :-)
For the curious, it has a C++ core, and uses Lua for scripting the actual games.
November 27, 2013
November 26, 2013
Styling
Not much to tell, but I wanted to show the latest progress:
I have tweaked the style a bit to match that of the phone app. Usability has also improved. You can now select the dataset to view by entering the user's name in the top left. You can also quickly jump to the previous or next day in the top right. And the selected day is also highlighted in the calendar.
November 18, 2013
Brain Graphs
I haven't been able to do much work on Brain Drain, but I did want to show you the current state of the web app, which I use for inspecting the collected data.
(Note: the screenshot is showing a ficticious data set. I sincerely hope no-one has this many headaches. The data is generated by another Javascript script, which you can also find in SVN.)
There are two parts to the visualization. The bottom part shows a calendar, focused on the current year. I based this off one of the many D3 examples. The main difference with the stock calendar sample is that you can select any date, and it will show the data for that date in the top part.
The top graph, then, shows the actual collected data. Each bar represents an individual data point. The height of the bar, and its color, represents the pain level. They are placed on the horizontal axis based on the time of day. When moving the mouse over a bar you also get a popup which shows the exact level and all tags which were added by the user at the time of registration.
The main missing feature right now is a way to choose the correct dataset. The database can store datasets for multiple users, but there is no way to select which one you want (other than hacking the URL, which I set up as a temporary solution). Apart from this limitation the interface works just fine, but would benefit from some usability and layout tweaks. Simple next/previous buttons for both the day and year would be nice, for instance. I'm also thinking of adding a tag-based search, or even graphs which group data by time-of-day, day-of-week, tag, etc.
From a developer point-of-view I can't stress the benefits of D3 enough. Once you understand its functional model, and with the help of some samples, you can easily do complex visualizations and interactive graphs with a limited amount of code. D3 has quickly made it on my list of favourite tools.
Well, that's it for now. Next posts on Brain Drain will likely just be showcasing further tweaks, though I do hope I can show you some more interesting stuff soon. As things stand, however, I'm using the application more than I'm developing it, and it has already reached most of the goals I set for it.
(Note: the screenshot is showing a ficticious data set. I sincerely hope no-one has this many headaches. The data is generated by another Javascript script, which you can also find in SVN.)
There are two parts to the visualization. The bottom part shows a calendar, focused on the current year. I based this off one of the many D3 examples. The main difference with the stock calendar sample is that you can select any date, and it will show the data for that date in the top part.
The top graph, then, shows the actual collected data. Each bar represents an individual data point. The height of the bar, and its color, represents the pain level. They are placed on the horizontal axis based on the time of day. When moving the mouse over a bar you also get a popup which shows the exact level and all tags which were added by the user at the time of registration.
The main missing feature right now is a way to choose the correct dataset. The database can store datasets for multiple users, but there is no way to select which one you want (other than hacking the URL, which I set up as a temporary solution). Apart from this limitation the interface works just fine, but would benefit from some usability and layout tweaks. Simple next/previous buttons for both the day and year would be nice, for instance. I'm also thinking of adding a tag-based search, or even graphs which group data by time-of-day, day-of-week, tag, etc.
From a developer point-of-view I can't stress the benefits of D3 enough. Once you understand its functional model, and with the help of some samples, you can easily do complex visualizations and interactive graphs with a limited amount of code. D3 has quickly made it on my list of favourite tools.
Well, that's it for now. Next posts on Brain Drain will likely just be showcasing further tweaks, though I do hope I can show you some more interesting stuff soon. As things stand, however, I'm using the application more than I'm developing it, and it has already reached most of the goals I set for it.
November 10, 2013
CanHasTagsNow
The phone app has reached a point where it has the minimum required functionality. A user can now take measurements, add custom defined tags to them, and upload everything to the server for storage.
It also has an entirely new look and feel. If you compare the following screenshot with the version from last week you should notice some differences:
The app now has three pages, which can be navigated by swiping left and right. The first page allows you to take a measurement: simply drag the slider to the desired level, then hit the log button. The second page lets you select tags and define new ones. And the final page is used for uploading everything to the server.
As you know I'm building this with Phonegap, which means all of the above is nothing more than HTML, CSS and Javascript. You might expect —at least I did— that setting up such a layout would require quite a bit of scripting, but actually it is mostly based on CSS3's multi-column layouts.
Here's the trick: set the column-count to 'auto' and define the height of your element to be 100%. This will create columns which take up the height of the viewport. Then use a small bit of Javascript to set the column width to the width of the viewport (ideally you'd use viewport relative lengths instead, but this does not work on the phone) and now you have split up your content into screen-sized pages. With a little help of Hammer (the Javascript library, not the artist) you can then capture swipe actions and offset the element to show the right page.
(Figuring out the offset was a bit tricky. Given that visually you're getting a horizontal layout of elements you might think that you can just query the width of each element, divide that by the width of the viewport, and you'd end up with the correct number of pages. You'd be wrong. What I found was that the width actually stays constant and it's the height of the elements which changes. So you have to divide the element's height by the height of the viewport to deduce the right page count. Weird.)
The bigger struggle was the taglist. As the number of tags can grow over time so can the length of this section. My initial thought was to just let it grow in length. The pagination trick would just split up the content accordingly and I could still swipe through pages of tags. I gave this a try, and it worked as advertised, but it didn't look right and it didn't feel right. The reason it didn't look right is that browsers still are very bad at dealing with breaks in content. The reason it didn't feel right is that the distance to the upload functionality was now variable, which makes for a bad user experience. So instead I opted to limit the tag list to one visible page with its own vertically scrolling element inside.
And that was about it. The rest was figuring out the more detailed CSS stylings and getting the interactions in place. I'm still going to be playing around with the overall style, as I'm not sold on it yet. And I need to clean up and sanitize the scripting. But all in all it's in a usable state, and I'm pretty happy with what I've got.
It also has an entirely new look and feel. If you compare the following screenshot with the version from last week you should notice some differences:
The app now has three pages, which can be navigated by swiping left and right. The first page allows you to take a measurement: simply drag the slider to the desired level, then hit the log button. The second page lets you select tags and define new ones. And the final page is used for uploading everything to the server.
As you know I'm building this with Phonegap, which means all of the above is nothing more than HTML, CSS and Javascript. You might expect —at least I did— that setting up such a layout would require quite a bit of scripting, but actually it is mostly based on CSS3's multi-column layouts.
Here's the trick: set the column-count to 'auto' and define the height of your element to be 100%. This will create columns which take up the height of the viewport. Then use a small bit of Javascript to set the column width to the width of the viewport (ideally you'd use viewport relative lengths instead, but this does not work on the phone) and now you have split up your content into screen-sized pages. With a little help of Hammer (the Javascript library, not the artist) you can then capture swipe actions and offset the element to show the right page.
(Figuring out the offset was a bit tricky. Given that visually you're getting a horizontal layout of elements you might think that you can just query the width of each element, divide that by the width of the viewport, and you'd end up with the correct number of pages. You'd be wrong. What I found was that the width actually stays constant and it's the height of the elements which changes. So you have to divide the element's height by the height of the viewport to deduce the right page count. Weird.)
The bigger struggle was the taglist. As the number of tags can grow over time so can the length of this section. My initial thought was to just let it grow in length. The pagination trick would just split up the content accordingly and I could still swipe through pages of tags. I gave this a try, and it worked as advertised, but it didn't look right and it didn't feel right. The reason it didn't look right is that browsers still are very bad at dealing with breaks in content. The reason it didn't feel right is that the distance to the upload functionality was now variable, which makes for a bad user experience. So instead I opted to limit the tag list to one visible page with its own vertically scrolling element inside.
And that was about it. The rest was figuring out the more detailed CSS stylings and getting the interactions in place. I'm still going to be playing around with the overall style, as I'm not sold on it yet. And I need to clean up and sanitize the scripting. But all in all it's in a usable state, and I'm pretty happy with what I've got.
November 07, 2013
0 FPS
Only a brief update on the Brain Drain project for now: I have managed to get the new layout for the phone app working in Android. I now have room for defining and selecting tags to go along with the measurements. What I still have to do is actually enable this functionality in full.
The main lesson learned today: test sooner and more often on an actual device. I have so far been using the Chrome browser as a bit of a substitute testing environment. This works really well, but the webkit engine on Android does not yet enjoy all the same features. Case in point: viewport relative lengths, which I was using to do device-independent layouts without Javascript. The solution ? Well,... yeah,... use Javascript. :-)
Anyway, to keep you entertained waiting for the next more sizeable update, here is an interesting blog I found: 0 FPS. It covers graphics programming, geometry and algorithms. Has some pretty nice articles. Enjoy!
The main lesson learned today: test sooner and more often on an actual device. I have so far been using the Chrome browser as a bit of a substitute testing environment. This works really well, but the webkit engine on Android does not yet enjoy all the same features. Case in point: viewport relative lengths, which I was using to do device-independent layouts without Javascript. The solution ? Well,... yeah,... use Javascript. :-)
Anyway, to keep you entertained waiting for the next more sizeable update, here is an interesting blog I found: 0 FPS. It covers graphics programming, geometry and algorithms. Has some pretty nice articles. Enjoy!
November 04, 2013
In design modus
I have only done small updates to the code. For instance, I made the server address and port configurable on server startup. Nothing earth shattering.
What I'm spending time on is designing a usable interface for the phone app. I want the user to be able to easily add tags when making entries, but it should all 'flow' quite easily. Extra dialogs are a no-go, for instance. It should stay as close as possible to "select level, select tags, log". From beginning to end it shouldn't take more than a few seconds.
After looking around a bit and trying some things I think I now have a good idea of where to go. If I don't get it functional over the next few days, I'll try to share a mockup of what I'm going for instead.
What I'm spending time on is designing a usable interface for the phone app. I want the user to be able to easily add tags when making entries, but it should all 'flow' quite easily. Extra dialogs are a no-go, for instance. It should stay as close as possible to "select level, select tags, log". From beginning to end it shouldn't take more than a few seconds.
After looking around a bit and trying some things I think I now have a good idea of where to go. If I don't get it functional over the next few days, I'll try to share a mockup of what I'm going for instead.
November 01, 2013
Brain Drain Tech
In order for upcoming posts to make more sense I'm going to have to give some background on the technology I'm using for the Brain Drain app. Let's jump straight into it:
I'm using Phonegap for the phone app, Node.js (with Restify) for the server, MongoDB as database, and D3.js for the webapp.
Let's get a bit into the reasoning. First the phone app itself. My first idea was to make use of Appcelerator, which lets you build phone apps in a platform independent way by means of Javascript. Unfortunately Appcelerator's licensing is a bit unclear, and I have seen some reports on aggresive fee extractions. Luckily there is the alternative of Phonegap, which works in a similar way and is licensed quite clearly as ApacheV2.
On to the server. Here I wanted to define a REST API, and so I was looking for something which lets you implement this in as easy a way as possible. This led me to Restify which, with the help of Node.js, let's you write such a service with just a few lines of Javascript. Very little overhead, cross-platform, and easy to set up.
The database is MongoDB, and the main reason for that is that I'm trying to build some more proficiency with it for professional reasons. In addition there exists a Javascript driver which integrates into Node.js and which lets you interact with the database in a very straightforward way (the Mongo shell is also Javascript, and the driver is pretty much a one-to-one mapping of everything you can do in the shell).
Then the webapp for visualizing the data. Here I'm using D3.js. D3 takes some getting used to, but once you get into the flow it can actually do pretty much anything you want. It has become my first choice for doing graphs in web applications. Of course I'm also using jQuery for setting up the main interactions, both with the user and with the server.
If you've been paying attention you probably noticed that the whole technology stack consists of Javascript. I actually think this is a great selling point for this combination. Whichever part you're working on there is no switching of languages required. Any proficiency you get while working on one part can be transferred to all other parts. This is even true of the phone app and the web app: both are basically nothing more than websites; only the packaging is different.
So that's about it. More details in future posts when I will try to tackle some of the internals.
I'm using Phonegap for the phone app, Node.js (with Restify) for the server, MongoDB as database, and D3.js for the webapp.
Let's get a bit into the reasoning. First the phone app itself. My first idea was to make use of Appcelerator, which lets you build phone apps in a platform independent way by means of Javascript. Unfortunately Appcelerator's licensing is a bit unclear, and I have seen some reports on aggresive fee extractions. Luckily there is the alternative of Phonegap, which works in a similar way and is licensed quite clearly as ApacheV2.
On to the server. Here I wanted to define a REST API, and so I was looking for something which lets you implement this in as easy a way as possible. This led me to Restify which, with the help of Node.js, let's you write such a service with just a few lines of Javascript. Very little overhead, cross-platform, and easy to set up.
The database is MongoDB, and the main reason for that is that I'm trying to build some more proficiency with it for professional reasons. In addition there exists a Javascript driver which integrates into Node.js and which lets you interact with the database in a very straightforward way (the Mongo shell is also Javascript, and the driver is pretty much a one-to-one mapping of everything you can do in the shell).
Then the webapp for visualizing the data. Here I'm using D3.js. D3 takes some getting used to, but once you get into the flow it can actually do pretty much anything you want. It has become my first choice for doing graphs in web applications. Of course I'm also using jQuery for setting up the main interactions, both with the user and with the server.
If you've been paying attention you probably noticed that the whole technology stack consists of Javascript. I actually think this is a great selling point for this combination. Whichever part you're working on there is no switching of languages required. Any proficiency you get while working on one part can be transferred to all other parts. This is even true of the phone app and the web app: both are basically nothing more than websites; only the packaging is different.
So that's about it. More details in future posts when I will try to tackle some of the internals.
Subscribe to:
Posts (Atom)