In truth, I should separate tile shape from the modifiers. The editor now re-applies these modifiers if the new layout allows it. Initially the bit mask destroyed this data - in practice intersections reverted to their default control and one-way roads were reverted to two-way roads. Tiles have more data than just their shape. Go ahead and try the live demo! It works best on a desktop, or on a tablet in landscape orientation. It works great! Smart construction and other tools in action I could then add a "smart construction" tool, which selects an ideal tile based on the surroundings. fromId has : Coords -> Board -> Bool has coords board = case get coords board of Just _ -> True Nothing -> False They linked an article that explains the approach.ĬhooseTile : Board -> Coords -> Maybe Tile chooseTile board origin = let parallelTiles = in parallelTiles |> BitMask. When I posted the video above to gamedevscreens subreddit, a helpful redditor suggested that I could use bit masking to choose tiles based on their surroundings. I admit: the first iteration is clumsy and cumbersome. Behold the end result! The initial map editor Map editor, take 0010: the smart solution You can toggle between different types of intersection control using the "intersection designer" tool.
The whole board can be wiped out with the "dynamite" tool to start over. I also added a "bulldoze" tool that makes it easy to destroy tiles. The rather obvious downside is that one often has to change the tile type while building a map. The tiles can be selected and drawn on the 'matto canvas like a stamp. I simply laid out all possible tiles on the toolbar. The actual editing part was easy to implement. I am planning to try a WebGL-based rendered at some point, so it made sense to decouple input from the render. The overlay accepts user input and highlights the selected tile, indicating whether an action is allowed or not. I added an overlay that's stacked on top of the render. The render is embedded inside the UI and sandwiched between the "toolbar" and "menu" components. I chose a horizontal UI layout that leaves maximum vertical space for the rendered simulation on target devices (desktops, tablets in landscape orientation). The existing UI components for debugging and simulation control were quickly replaced with the elm-ui counterparts. All of the UI, editor and otherwise, is built with it. Things can be easily stacked (in terms of depth) and placed right next to each other. Most of the primitive building blocks - such as buttons and typography - can be laid out in horizontal and vertical layouts. It's a popular Elm library that allows the developer to build (complex) user interfaces without directly dealing with HTML and CSS.
#Townscaper best builds how to#
I started off with learning how to use elm-ui.
With the editor I could try out different road configurations and find out if they work. Liikennematto direly needed a map editor.
#Townscaper best builds code#
Laying out maps in code got cumbersome pretty fast. Map editor, take 1: what you see is what you get I've also implemented rudimentary one-way traffic and refactored the simulation. Headline feature of this post is the map editor. I've certainly spent a lot of time thinking about the roadmap for this project e.g. Major life changes can also be a great source of inspiration. These four months have been eventful to say the least: I became a father and got married 🥰 Though these changes have made me super busy (and happy), I found some time to work on Liikennematto. This post sums up the development progress of the last four months. I've implemented basic traffic rules with board game -like logic using the Elm programming language and SVG output. Welcome back to the Liikennematto devlog!Ī quick recap of the previous post: Liikennematto is a traffic simulation prototype.
0 kommentar(er)
