This week I published my second article in a series on developing games in elm. I introduce using signals to make your game reactive and compare them to the more traditional event pattern.
Read it on gelatindesign.co.uk - "Developing Games in Elm: Signals"
So I finally sorted out the problem I've been working on for a few days.
Now when you select a unit it highlights all tiles that are within a set distance of the unit (currently hardcoded to 3). I'll add in a cost based on the tile type over the next few days. Also need to make the highlight list remove duplicates as you may notice some of the tiles are double highlighted in the screenshot.
I had given up on this earlier today after several hours but had another quick look at it for 10 mins and had one of those great "oh yeah!" moments and fixed it. Programming can be massively frustrating at times :p
I wrote a summary of my second sprint about the world editor and a technical article as the first in a series on developing games in elm about functional programming. This one has proven quite popular and got quite a bit of activity on twitter which was nice!
Sprint Two - World Editor : http://gelatindesign.co.uk/project-iso/sprint-two-...
Developing Games in Elm - Functional Programming : http://gelatindesign.co.uk/developing-games-in-elm...
Still trying to solve the same issue; getting the cost of movement to each tile on the map from the unit's current tile. Immediate neighbours would be a cost of 1 for grass tiles, 2 for the neighbours of neighbours etc. Some tiles would have increased cost, say forests might have a base cost of 2, so going through two forest tiles would cost 4.
Then gotta represent that as a highlighted area of possible moves.
I'll get that working eventually but for now I've just added a river to my demo map. (The highlighted area here is just for immediate neighbours, getting it to iterate correctly is proving difficult in a functional language :p)
I'll keep trying on this tomorrow...
Today I worked on the initial unit movement, no transitions just pick up and drop. You can quick cycle through the units with the "." key. I did add a possible movements highlight but as you can see below this is entirely ignored. Also the world's bounds aren't adhered to...
Tomorrow I'll look into actually calculating tile type cost and distance cost. I'll need to calculate the cost to every tile on the map from the unit's current position. I think that would involve some dijkstra? Not sure, never done path finding.
Today was my first of a full week devoted to game dev. I worked on adding units, keyboard controlled pointer and selecting.
It went pretty well but I've got some difficult bits to solve tomorrow.
Placeholder art as always.
It's what can be described as a bit buggy, but I've got the painting working in the map editor.
The brush position is wrong but it kinda sort works.
So I've been a bit crap at keeping the streaks going this past week. However! That should massively improve this next week since I have 5 days of holiday to do nothing but make my game :D
But for this evening I continued working on the map editor. I've been adding the interface, you can click the different brushes which changes the tool and paint the first tile. Just gotta make it so you can paint the rest of the tiles as well.
Hopefully will have this functional by the end of the weekend as I need to get cracking on units, movement and combat to have an MVP ready for Rezzed in case anyone happens to ask to see it...
(please forgive the weird layout of the "interface" so far :p)
I've decided to split my devblog into non-technical and technical articles. I want to discuss some of the challenges and lessons I learn as I work with a new language, Elm, whilst not alienating non-programmers.
I've completed the first non-technical blog, and I reckon I'll be able to squeeze in a technical one this week as well.
Today I worked on replacing the hardcoded "click tile to make it grass" functionality with proper editor tools. Along with this I started laying the foundations for the editor UI with brush switching.
No screenshot today.
I've been having difficulty getting past a problem which caused me to not commit any code the past few days as I simply read and learned instead.
But I've conquered it! Wahey!
Essentially, I was trying to figure out how to tie my Main -> State -> Editor -> World -> TileList -> Tile structure together such that the children had no knowledge of the parent and the parents blindly passed signal context (events) to the child. This allowed Tile to listen for a click and update itself within TileList.
This is due to Elm being a functional language which doesn't have state on objects, simply functions and data. It makes everything a lot easier, once you've got your head around a couple of concepts. It is a language in early and rapid development so I'm sure this will improve.
Anyhoo, here's a gif of the initial editing a world (along with a mouse position bug due to image overlays).
I've been struggling with a concept for a few days now and haven't managed any to get any commitable code done, but thinking time counts right? :p
To compensate I worked on a draft for my next couple of blog posts about this sprints developments and why I'm developing my game in Elm.
Today I worked on adding signals between the various models for the world map. This ensures the models only know about their child and not their parent.
Editor -> World -> TileList -> [Tile]
In Elm signals are kinda equivalent to events, but described as "a value that changes over time". I don't quite fully grok them at the moment, so I suggest reading the info here if you're interested - http://elm-lang.org/learn/What-is-FRP.elm
No exciting screenshot for this though today.
Today I finished off a refactor of the initial smattering of ideas I've played with over the last couple of months. This brings my code into line with the architecture guidelines for the language I'm using (http://elm-lang.org).
Further to this I fixed up the issues rendering the basic isometric tiled map and began on building the map editor.
