Month: March 2015

Maps and Coordinates

~ Enno ~ Leave a comment

The classic Eressea game has an unusual coordinate system for hex maps. For the future, I’m going to go with the system that Tiled uses, and all my work on the hexmap already uses it. Speaking of the map, I owe an image of the work I did on the selection:

Now with new tileset, ripped from Magellan.

The map you see here is from Eressea, because while I was not updating this Tumblr, I worked on a new report format for the old game that would write JSON maps for Tiled. It’s incomplete, but my game can read it, and I already learned something important: There are several ways to draw the same data, and it is important to know whether the first or second line of hexes is staggered (indented half a hex to the right). My game now reads this information and displays the map accordingly.

So even though that export is not on my roadmap to an MVP, it was still useful because it showed me a bug in my thinking before fixing it became too expensive (in this case, only rendering the tiles and the selection needed to change, as well as mouse-picking).

Map selection

~ Enno ~ Leave a comment

I made a simple selection marker, controlled by keyboard or mouse clicks. It is visually a square, the mouse click boxes are not hexagonal, but it works. Good enough for today.
Starting to get a bit antsy about making things other than UI. Watched two episodes of B5 today, and have Kingsman with Colin Firth lined up for an evening movie. Easter soon.

Menus

~ Enno ~ Leave a comment

I mentioned menus in my last post. Here’s how the main menu looks right now. It does not mark disabled entries in a different color yet (that’s on my TODO list), but it works.

image

What does not seem to work, however, are inline images in tumblr. Maybe it is a combination of privacy addons in my chrome going wild, but the images I insert into my posts do not seem to get uploaded. I had to link them from imgur in my last post. Trying this one more time…

Works when I’m posting from an incognito window (all addons disabled), so I guess that’s my own fault in some way. This is the kind of shit that keeps me from getting work done, because I just cannot let it rest…

Update: That’s it! Looks like HTTPS Everywhere doesn’t play nice with tumblr.com – I guess I can selectively disable it on this site? Mystery solved!

Building UI Elements

~ Enno ~ Leave a comment

I’m a day late with this update, even though I worked through the weekend. A week into this project, and I have already got problems with focus, but I have been able to get some UI elements to work.

The game is going to have a large map view with hex tiles, so the first thing I built was that. I will be using a modified version of the Tiles JSON format as my report format, and step one was loading that map from disk. I also prototyped that I could load it from a web server, but it’s a ways before that protoype will make it into my actual code. Here’s what the map looks like:

The map can be scrolled with the mouse, but needs an active selection and detail view before I can call it done.

I am going to need a menu that opens up when pressing escape from the main view, so I prototypes that as well, with a bitmap font that my friend Andy posted a while ago. So I can count the bitmap font class among the things I built, too. Then I prototypes a login screen. My current rough idea is that I will give players a hexadecimal code to connect to their position in the game, and combine that with a code generated by the app. Since I’m still a bit sketchy on the details and not quite there yet, I didn’t finish the dialog until I’m actually going to need it. For now, it is the first UI element I have that supports all the interesting inputs: keyboard, mouse and game controllers.

Last but not least, I tested the Android version of LÖVE with the hex map, and made sure that I could get the game running on my phone. Overall, I’m still pleased with the technology choice, even though I seem to be building very much from scratch. I hope to finish the hex map for my next update, and then move on to communicating with a web server for map data by the end of the week.

Client Technology

~ Enno ~ Leave a comment

With the decision to start writing the client first came the question of client technology. The existing Eressea client, Magellan, is written in Java, and even if I wanted to use some code from it, I would not be able to run it on a mobile device. I also do not know the code base, since it is mostly written by player volunteers.

So unlike the server situation, there is no reason to stick to the language used in the past, and I am free to choose whatever I want. The real constraint here is mobile, and the options that I know of are Cordova/Phonegap (HTML5 and Javascript), Unity and LÖVE.

Cordova is the only one of these that I have practical experience with, and while it’s a great choice for an app with a lot of UI, it is not what I would choose for a game in which I want to render a lot of bitmaps. I am also not a huge fan of Javascript. Unity is hot with other indies, but it is a 3D engine first, and there is a learning curve that I do not feel like scaling right now. I would also have to brush up on my rusty 3D math, just to make 2D projections. That seems like a waste. On the other hand, Unity skills are very marketable in the game industry right now.

Finally, there is LÖVE. I had only briefly looked at it before, but it looks exactly like the engine that I had always wanted to write myself: Built on solid, industry-proven, portable C libraries (SDL, PhysicsFS, Box2D), with Lua as the programming language, and Android and iOS ports in addition to the desktop releases. There is an active developer community, and an IRC channel where people answer questions. I think it’s charming, so I wrote a few prototypes for key technology (networking, UI, controller input), got a simple map viewer for Tiled to run on my phone, and decided that my search for technology was over.

Legacy Code

~ Enno ~ Leave a comment

The first days on a new project are always exciting. I initially spent a lot of time thinking about how the rules of the game will have to change, and my instinct was to write the server code first, because that is what I already know and feel comfortable with.

The first obvious question is what language I want to write this in. I have gotten a lot of complaints from people that Eressea is written in C, but I am very happy with that choice, especially since I have gotten to a point where everything high-level is now written in Lua. I am very comfortable with that language mix (C plus Lua), it is very portable, and I already have great tools to work with it that I know inside out. In short, I see no good reason to throw 18 years of experience by the wayside, just to try another language. Especially since I’m not likely to collaborate on this project, but plan to write all of it myself.

I have two code bases that I can work from. On the one hand, there is Eressea, which is a super complex game with a lot of rules that I am not going to need. The code quality is really great, it has tests, but stripping away all the layers of rules that won’t make it into a “mobile” game is going to be a lot of work.

On the other hand, there is my incarnation of Atlantis 1.0, which is super simple, and free of cruft, but the code is not as great, does not have a lot of tests, and I would miss a lot of the conveniences I built into Eressea over the years, like the order structure that replaces the crazy string parsing in Atlantis. It has a slightly better build system, and the Lua code is in a shared library, while Eressea just embeds Lua in the main executable.

My conclusion at the end of the day was that I will probably start from scratch, and import the good bits that I need from either game. That means the Atlantis build system, new types for objects, regions, etc. that reflect the reduced complexity of the rules, and any useful utilities that I built into Eressea. I guess that also means that I will have a third code base to maintain, and I should be looking out for the second system effect.

Most of all though, my conclusion is that all of this server code needs to wait until I know the rules of the game. To find out what those are, I am looking at other games for inspiration, and have come up with a few basic traits that I want the game to have, but the real constraints will come from the client UI. I have never worked much on the client side of my games, so this time, I am going to start there. My next post is going to be about the technology decisions for that.

Modernizing Eressea

~ Enno ~ Leave a comment

Due to circumstances beyond my control, I’m finding myself “between jobs” again. This sucks, because I really liked the most recent product I was working on, and was finally enjoying work again. Job hunting sucks.

Instead of sitting on the couch, watching Ghibli films and feeling sorry for myself, I have decided to use my time off to finally put Eressea on some more solid feet, making it more accessible.

What that means for me is:

  1. I want future games to fall more on the strategic end of the scale. There are already three active games that cater to the role players, and the hard-core strategy players are problematic, so I want to give them a separate game to play.
  2. The game will have a friendlier client. No more textual orders, no more dependency on the JRE, no more email.
  3. I am going to approach this with the goal of creating a commercial product.
  4. There will be a mobile version as well as a desktop version of the client. 

To keep myself honest, and make sure I don’t get distracted along the way, I am going to try and update this development blog three times a week, whether I feel that there was progress or not.