Working on Map Instantiation

I’ve got a function up and running that returns a two dimensional array with space objects that can contain a unit. It can pass the unit to the renderUnitCard function and can be easily traversed. Very satisfying.


The Space class doesn’t need to be any more complicated, it’s really just a container though it’s one that should have a prototype output method that returns itself as a string, complete with any contained units. The game only allows one real token on the space at any given time which simplifes things. The Token class is going to need a prototype method that returns a string <div> version of itself so that the css can render the unit on top of the card.

I have to find some good backgrounds for the spaces too.

I’m thinking about the option of turning the game into a grid instead of having hexes, just for simplicity of rendering, but then you’d either have four facing with no diagonal movement/attack or you’d have eight facing, both of which just feel so different than having six facings which is of course the world’s most perfect number for faces of a polygon.

Oh yeah and it makes the map from sexy ASCII drawings like the one on the top.

Boring Status Update

Things have been going a bit slow because the whole family just got over being sick all at the same time. Haven’t had a lot of time to stay up late and work on stuff, plus I download Kerbal Space Program which is a fascinating and educational time sink. It’s amazing how many people are talking about rocket mechanics for no reason other than accomplishing goals in a make believe sandbox video game space program. So far I’ve killed a lot of kerbals and made some explosions, and had a couple of falling with style types of situations.

I’ve been thinking about how to handle map movement for my game. I think the first thing to do is to get a working demo where a virtual table top, with an array of objects representing the spaces, is shown on the screen, and a guy can move around on the map. Maybe with some terrain, maybe worry about the terrain later.

Nah, I should worry about the terrain now.

So it’s going to look something like this:

var map = [
	[ {
		x: 0,
		y: 0,
		terrain: "Plains",
		contains: {
			"spearmen 1": {
				"name": "spearmen",
				"tokens": [
					hit, hit, entrenched

Or something like that. And then it goes through it and renders it on the screen. And then you can click on the guy and it shows you where he can move and then you can click on one of those spaces and he moves there. And you can’t click on spaces where he can’t move.

Attacking is more complicated because of range. I also have to decide if I want the player to be able to course out a whole turn’s worth of movement or if I want everyone to pop around one space at a time. Rivers require a coin flip to cross so you wouldn’t be able to plan a route across a river because you don’t know if the ford will be successful or not.

Progress with Doomball

Kind of an excellent bit of prograss on the Doomball engine. I’ve got the unit renderer working, I made a way to work with the grid, and I’ve been putting some solid thought into the way to handle gameplay mechanics. Found a cool little game that does some similar things to what I’m thinking about, though it handles them in different ways. I think a big part of it is that I’ve been working with front end stuff so the simple way to handle things for me seems to be with jQuery and lots of div classes and I think it could be handled more smoothly with pure JS and some canvas elements, but I don’t know how to use canvas elements honestly.

There’s a gallery of units up right now though that’s on the index.html file so if it changes that link will go to something different, and I think they’re all looking pretty good. I have art done for a few more races but I’ve gotten better at pixel art since I started so I kind of want to go back and revisit these old units. One benefit to this project, even if I don’t actually get it working as a video game, is that this is a way easier way to customize and revise these pieces than trying to keep up with the dramatic system of layers I was using before.

The grid system is a bit messy but the spacing is basically right. There was something weird that happened where the inline-block div elements that hold the units were dipping on the last line when it wrapped around the window, so I switched the display to regular block and just floated the things and that cleared it up. Didn’t really have to be inline-block anyway, there was nothing inline about the design.

I also wrote a kind of sloppy little function that checks for adjacency.

Space.prototype.isAdjacentTo = function(space){
	if (this.x == space.x || this.x == space.x-1 || this.x == space.x+1) {
		if (this.x % 2 == 0) {
			if (this.y == space.y-1 || this.y == space.y) {
				return true}
		} else {
			if (this.y == space.y || this.y == space.y+1) {
				return true
	return false

I wrote some grids down longhand and tried to figure out a good test to see if spaces were adjacent when you were dealing with hexagons and this is basically what I came up with. I thought it was too rough and I figured, since I didn’t really have any tests to run on it yet, I’d shelve it and see how it worked when I got to it but when I went looking for a good way to generate hex maps in html, I found this game and jumped into the source code. It basically uses the same algorithm to check adjacency, but it uses arrays of values to add or subtract from the values of the hex in question instead of a simple test like this. I’m not sure if it’s better or not. I guess you could use those values in more than one place, with the other guy’s example.

GridMath.neighbors = {
    'even': [[-1, 0],[+1, 0],[0, -1],[0, +1],[-1, +1],[-1, -1]],
    'odd': [[-1, 0],[+1, 0],[0, -1],[0, +1],[+1, +1],[+1, -1]]
GridMath.isNeighbor = function(x, y, x2, y2) {
    var neighbors = y % 2 == 0 ? GridMath.neighbors.even : GridMath.neighbors.odd;
    for (var i = 0; i < neighbors.length; i++) {
        if (x + neighbors[i][0] == x2 && y + neighbors[i][1] == y2) {
            return true
    return false

See? Basically the same thing.

Unit generator progress notes

Unit Generator

var Unit = function(unit) {
	this.race = unit.race; =;
	if (unit.level) {this.level = unit.level} 
	else {this.level = 1}
	this.range = setStat(unit, "range");
	this.attack = setStat(unit, "attack");
	this.defense = setStat(unit, "defense");
	this.move = setStat(unit, "move");
	if (unit.special) {this.special = unit.special}
	this.tokens = [];
	this.graphic = unit.graphic;

This is what I’m working with so far. setStat() is a simple utility function that sets a default stat and handles the availability of special characteristics. I think there’s a little bit more logic in here I could rip out but I can roll with this so far. Having defaults values (1 range, 2 attack, 1 defense, and 1 move) means that I can create unit definitions that simply state how they differ from the default instead of typing out each characteristic every time. That feels programmatic. It feels like a good solution.

Human Units

var humanUnits = {
	"spearmen": {
		"race": "human",
		"name": "Spearmen",
		"special": "Steadfast",
		"graphic": "./images/spearmen.png"	
	"archers": {
		"race": "human",
		"name": "Archers",
		"special": "Pinning",
		"graphic": "./images/archers.png",
		"range": {
			"value": 2
		"move": {
			"special": true
	"horsemen": {
		"race": "human",
		"name": "Horsemen",
		"special": "Overrun",
		"graphic": "./images/horsemen.png",
		"defense": {
			"special": true
		"move": {
			"value": 2

There’s four more like this, some more or less complicated, works out fine. I have another function that makes HTML strings that display these as the blocks I previewed in the last post, feels good. Have to throw together some transparent unit graphics and then get started on the next army I think - having functions that can display each faction with nothing more than a change in JSON archive is central to the design concept I’m working with here.

What’s next

  • I need to make sure that it changes the background image based on the faction. In the original design for the game each faction had a specific and different background image. I don’t know if it’s something I’m going to stick with but it’s something I want to at least work into the spec. I’m thinking each will have a specific class to throw onto the divs with a different background image - .unit-human, .unit-orc, .unit-hive, that sort of thing.

  • I’m still thinking about how to display these suckers responsively and how to give them a nice hex grid to get thrown onto. I think I can set up the actual display on the board with some judicious div use and a .staggered class that pops everything over 100 pixels. Getting the hexes to lock into each other will be tough, though. Have to figure out the right size to make them so that they can have the pieces on top and you can still see what the space is underneath. Each is going to have to be identifiable from its margins.

  • Haven’t even started on the game logic yet.

  • The tokens could be part of the tile generation. Throw some conditional .divs into the package and make sure they display on different places on the tile - the whole of the inside is claimable territory for tokens, but you wouldn’t want them to overlap by any means.

Pure HTML Unit Cards for Doomball

I whipped this up


Frankly, it’s ugly as sin. The colors are HTML generic, the styling is all done in-line for testing purposes, the graphics could be a little better - should I code in multiple instances of individual soldier graphics and plug them in? They’re all based on a universal sizing template per size so it should theoretically be a thing, but I don’t know if it’d be better than using these basic png transparencies for it. Need to make sure the text can display dynamically so it’s visible on whatever size screen is looking at it, too. Do I want to set this up to be responsive from the get go or would I be better off keeping it simple at first and revising it later? Or never, and just making it for desktop? Everyone’s on phones these days, probably best to make it responsive, but it’s going to be awfule finicky to position in the first place.

As a proof of concept this is an ugly success.