I make games and web things!
I've been doing bits here and there but haven't delved into my primary project for most of that time. I had a week off from work where I hammered out some good code, but going back to the office really killed my momentum. And momentum is hard to build back up.
I'm off to Rezzed tomorrow for 3 days, then have a small project to get out the door in the days after that. THEN hopefully I will be able to get back to smashing out my game and on the road to becoming a legit indie dev.
In the meantime I have done some work on a demo game for an article I am writing, the next in a series on developing games in Elm. It's a simple space invaders game but it's still something I guess.
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)
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.
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.
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.