Wednesday, April 16, 2014

Minimap and Jenkins Build

Well, after finally get the exporter in Tiled to do what I wanted, (and as a side note: my changes got accepted into the project today. Tiled has one of those maintainers that's actually pleasant to work with!), it was time to make my build scripts to actually generate my minimap. Which made me realize it was time to actually have proper build scripts.

When I started with libGdx (almost a year ago?), it didn't have a good build system prepared with it. You pretty much rolled your own build scripts, or just used the "build" button in your IDE (which embarrassingly, is what I've been doing).  The author has recently come out with a gradle build script, but that would require me going back and updating all of my libGdx stuff to use the newest version. Which I'm not ready to do at the moment.

Well, I found someone else's ant script (yuck!) for how my project is set up, so I figured I could start with that, to at least get a scriptable build started. I'd rather do it all in gradle, but I really don't know enough gradle yet to do it without investing a good bit of time, which is not what I want to focus on now.

Anyway, so today I got the build scripts working, and running on my Jenkins server, so whenever I push my commits to my Bitbucket repository, Jenkins will build the phone version of Robo-Ninja. So I finally don't feel quite as dirty. And when Aaron pesters me to get Robo-Ninja installed on one of our Android devices, I've got a build already put together, accessible via the web browser. (If anyone wants the link to the daily build version to play with, just send me a message.)

Now that I've been fully sidetracked just to make the minimap, it's now time to figure out how to actually display this thing in the game, and for the harder part, figure out the best mechanism for revealing just the parts that the player has seen. This might get tricky.

Wow, when I look at this dinky map of my levels so far, it looks like I really haven't done ANYTHING yet.

Monday, April 14, 2014

More contributing to Tiled

Well, after submitting my changes to Tiled, and discussing it with the maintainer, we decided that instead of working around their goofy hard-coded ommision of the collision layer, it might be worthwhile to completely rework the command-line flags for including or omitting layers. So instead of working on Robo-Ninja directly, I spent the evening working on Tiled.

Specifically, adding command-line flags to their export utility that let you specify layers by name to omit, and let you also tell it to just use the visibility settings of the map itself.

This code is all in C++. I haven't written anything in C++ in YEARS. 

Sunday, April 13, 2014

Hooray for Open Source

Today I started investigating how I want to handle the mini-map. I still haven't completely settled on a design that I like. Some of the questions or factors that I need to think about are:

  1. The minimap needs to be smart enough to (at least mostly) build itself from my level data, without me having to go back and build a big minimap by hand.
  2. I want to minimize the effort involved -- I neither want to have to add a bunch of meta-data to my maps to give them hints about displaying themselves on the minimap, neither do I want to have to write a ton of code for the build process to make it build the minimap.
  3. How much detail do I want to show on the minimap? In Anguna, the dungeons were just wireframes of the rooms (which is closer to a Super Metroid-style map), but the overworld was actually just the image of the overworld map scaled down to any extremely tiny size.
Super Metroid's wireframe map. Robo-Ninja's world is about as big as the "Brinstar" section of Super Metroid.
(bonus points for those of you that can point to Brinstar on this map without looking it up)


I'm leaning toward doing scaled down images (in answer to #3), so I started looking into a simple scriptable way to dump an image file from my map, using the Tiled editor. Turns out, they have a command-line utility for dumping them. The only problem: it omits any map layer with the name "collision" (why they hardcoded that is beyond me), which is the name I use for the primary layer in my maps!

Luckily, it's open-source! It took about an hour to:
  • Find the place in their code where it omits "collision" (actually, I didn't realize that's why my collision layer wasn't getting exported until I searched through their code!)
  • Change the command-line utility to take an argument flag to tell it whether to omit that flag
  • Compile, test
  • Send a message and a pull request to the maintainer, in case they're interested in using the changes.
So now I can dump out my images of my maps in an easily scripted method. Hooray for open-source!

Now I just need to decide about #1 and #2 above. My map files theoretically can figure out how they're all connected to each other, based on the "exit" hotspots, that warp you from one map to another when you get to a certain edge. But the maps don't really know their absolute position in the overall world map (which was just poor design/planning on my part).  So I really need to decide between computing each map's position by tracing through all the connections between maps (from a known start point), vs going back and adding metadata to each map to tell it what its position is in the global map. I'll have to think on that some more, I guess.

Wednesday, April 9, 2014

Back to the Ninja

Well, the Dart coding was fun. I ended up spending a few weeks-worth of coding-with-one-hand-while-holding-a-baby-in-another playing with it. My verdict: I'm not sure I was any more efficient working in it (particularly with the combined pain of learning a new language/framework, lack of documentation, and lack of 3rd party libraries), it was definitely less painful than javascript or other traditional ways of doing web development. I'll be interested to see if it goes anywhere. Being a Google technology, I don't have my hopes up.

So this week, I'm back at Robo-Ninja. I think the trick to getting me to finish a development project is to have a fan. Having Aaron pester me about it is a good motivation!

So during approximately 10 minutes last night, and 15 tonight, I managed to get the consumable slow-motion powerup working. It was one of those happy times where everything fits smoothly into your design without bumping into any nasty corners.

I also realized from testing that my icons for cycling through your abilities were too small. It was fine on the computer with the mouse, but once I had my hands on the screen, blocking my view, it was really hard to tap the right spot quickly between manically tapping the screen to time my jumps and slides. So I've increased the size. Hopefully that will help, but I haven't had a chance to test on my actual phone again yet.
The icon on the left is after the size increase. The consumable items on the right are how big they were originally. 

Next steps: the wall cling ability, and the minimap.

Monday, March 17, 2014

Lack of UI libraries in Angular Dart

So I'm still slowly chugging along playing with Angular Dart.

The thing that's bothering me now is, because the it's such a new language/framework, is the lack of decent UI stuff. I needed a pretty date picker for my test project. I could either use the HTML5 date picker which isn't supported in half the browsers out there, or write my own.  I guess I could alternatively import all of jQuery and figure out how to get Angular Dart to talk to a jQuery widget. Ugh.  I finally found someone that had written one using WebUI, a deprecated system for making widgets in Dart, and managed to port it over to Angular. (if you are reading this and need one, email me!)

Tonight it was an autocompleter that I needed. Again, I ended up spending awhile converting a WebUI widget. Which is great practice for learning a language and framework, so I'm not complaining too much. But it certainly cuts down on the productivity.

The way components in Angular Dart are written, I can envision a world with a huge library of simple-to-use UI components. It's MUCH MUCH MUCH cleaner than trying to pull in javascript libraries for a widget. But I guess there's just not any real community or momentum behind the project yet.

Friday, March 14, 2014

Oops

Huh, that's what I get for not proofreading my last post. Didn't realize Blogger was incapable of escaping my HTML for me, so it mangled my code. It's corrected now.

And so after playing with Angular Dart for a while longer, I'm really annoyed at the Dart to Javascript conversion. Plenty of stuff works wonderfully in Dart proper, but then fails with cryptic error messages once converted to Javascript. I'm not sure if that's just immaturity in the environment, but if not, it's a pretty big show-stopper. This platform only works if the compilation to javascript is relatively seamless.

Tuesday, March 11, 2014

A week with Angular Dart

So I'm taking a (hopefully) short break from RoboNinja. With the baby, I have a couple hours in the evening where I hold her as she's winding down.  By that time, and with the one-and-a-half-hands that I have available, I just can't bring myself to try to do any serious work on it.

So instead, I decided to spend a little time fooling around learning a new web framework (Since with a new technology, you spend as much time reading as you do actually typing!) I think I've mentioned before on there that I'm always looking for new web frameworks that try to make web programming not suck. (And the vast majority fail miserably). So this time I decided it was time to try Angular Dart.

Dart is a new language from Google that attempts to replace Javascript. It's not perfect, but it's a whole lot more "normal" -- it uses class-based OO, reasonable scoping rules, etc.  Since basically no browsers support it, it can compile down to javascript. So theoretically it can run anywhere.

Angular is originally a clever javascript framework (one of the few that, when I looked at it, I said "Oh wow, neat!" instead of "huh, more ugly javascript"). So now the folks at Google have been working at porting the Angular framework to Dart. It's pretty new, and still in flux, but it sounded fun to play with.

The general idea of it is that, instead of writing a ton of event listeners, DOM-modifying code, etc, etc, you write a view with HTML plus a few magic attributes, and it takes care of automatically keeping your view and your model in sync. The simplest example is something like:

<span ng-if="person.name != null">{{person.name}}</span>
<input ng-model="person.name" />
In this case, it's all operating on the "person" model, which is an object that I'm assuming exists. As soon as you start typing in the input, the span will magically appear (since person.name is no longer null), and the span will contain the person's name. As you type. Without setting up listeners or registering callbacks or using CSS selectors to find the span's DOM object. It's neat.  You also have a controller object sitting behind the view that takes care of getting the model object, doing any business logic (ie "onSave"), etc.

Then, to make it better, you can build your own new HTML element tags, which let you easily make your own components on page. So you can do stuff like make a new date-picker element that you can use all over the place as easily as:

<date-picker ng-model="person.birthday"></date-picker>

Which, without additional wiring, will update the person's birthday field as you modify it.

So I've been fooling around for the last week with trying to put together a fairly simple webapp with it. So far, it's been really fun and interesting (as opposed to most webapp projects!), although it hasn't yet been fast. The biggest problem so far has been a lack of documentation. Angular Dart just isn't very mature yet, and there's very little in the way of documentation.  Learning a new framework and language is always a slightly time-consuming process, and it's even trickier with a lack of resources.

Debugging has also been challenging. Because all the magic data-binding and DOM manipulation happens magically by the framework stuff, it's almost impossible to tell what's going wrong when the problem is with your HTML view. Dart has decent debugging facilities, but they really just apply to your Dart code itself, and not all the Angular magic. (unless you want to slowly step through the all the Angular libraries).

That all being said, it's been really fun and interesting to work through. I can't yet judge how productive overall the framework is, but it's definitely more pleasant and interesting than slogging through javascript event listeners and DOM manipulation.


NES Anguna

Well, I had a little bit of time still, while Frankengraphics is finishing up her game Project Blue, to have a little downtime on Halcyon, s...