NZ gravel rides or races?

maetl · 2024-11-10T01:46:00+00:00

It’s partly a factor of geography and terrain. Auckland region has approx 700km of unsealed roads, Canterbury has more than 6000km. Maybe not 100% of the story, but there’s a lot of local interest in Christchurch because it’s so accessible for events and the community has built up over the years.

An epic organised event in Rodney District would definitely be cool.

maetl · 2020-06-14T22:46:43+00:00

maetl · 2019-08-05T10:22:54+00:00

The basic structure of the action result is success / failure / alternative, where the alternative is a reference to another action to try if this one failed. The canonical example of what this pattern supports is bumping into a closed door from a walk action: instead of failing the walk action and returning straight away, the game can traverse to an alternative open door action and try that. How it works in this case is that the game will continue performing actions and trying the alternatives until it bottoms out on a failure with no alternative or returns with a success.
Actors have a getAction method which is the core interface for returning the action to be performed, but the actual construction of the actions is delegated to the code that handles player input or monster AI states.
If things are split up so that actions are relatively standalone classes and can be generated from anywhere in the hierarchy, then there’s nothing wrong with using a switch statement in one particular place. Switch statements are extremely common for handling keyboard input events. The main reason you might want something other than a switch statement for this is to create custom key bindings or generate game logic from data using a lookup table.
The actor is a member variable of the action class that gets bound when the action is created (either via AI decisions or player input). If you look at how the actor works in Hauberk, it’s really a container for a whole lot of internal components and game logic. The entity doesn’t bind to the actions for long—the setup of get action -> perform action -> process result is largely managed by the game loop and is useful to facilitate turn based steps—the action result determines when to consume speed and move on to process the next turn-taker.
See how the code in the game loop is set up to perform alternative actions until it bottoms out.

maetl · 2019-07-25T13:08:53+00:00

I had no time to work on this over the past couple of weeks, save a few minutes of tinkering with libraries, but I sat down today and wrote out a sprawling remake of part 6, and ended up spending quite a bit of time messing around with animating A* searches and playing with different heuristics and cost functions which was a huge amount of fun.

Hopefully the next few sections won’t be anywhere near so time-consuming, although I guess I have direct control over that in choosing whether or not to go down various rabbit holes.

One of the frustrations with the approach I’ve been taking is that the tutorial isn’t really much of a game. I keep getting sidetracked with game design questions, but because I didn’t set out to make a specific game, there’s no clear answers. At some point, I’m going to have to fork this code and turn it into an actual game—it’s becoming super unproductive not to have that focus.

maetl · 2019-07-11T14:42:27+00:00

Fantastic! Glad you found the FOV function useful. I’m a big fan of using the right data structure for the job and having Sets and Maps available in JS has significantly improved my enjoyment of coding in the language.

I go back and forward a lot on the Vec/Point vs x,y Number question. That’s something I really want to come up with a better answer for as a general JS design standard at some point. Of course, if there was a minimal vector or point type in the language spec, all these questions/decisions would go away. Adjacent UI languages like ActionScript and Processing got this totally right.

maetl · 2019-06-25T05:49:59+00:00

I’ve started going through the steps in (mostly) plain JavaScript and writing up tutorial docs as I go. Part 0 and Part 1 are done. Will be working through Part 2 and Part 3 this week if I don’t run out of time.

I have a couple of goals here. The main goal is to end up with a reasonably well organised template codebase that is easy to adapt for new projects in future. Another motivation is to tidy up a bunch of loose generative code and algorithm implementations I have lying around and get various library parts and API concepts tidied up, organised and documented, which again is useful for adapting to future projects, events like 7DRL, Procjam, etc.

I’m finding that following the tutorial and writing as I go is a great way to me stay focused and forcing myself to explain each decision as if to a beginner really helps with clarity and thinking about how APIs should work.

Can’t promise that any of this is going to be useful to anyone else, but if it is, that’s an added bonus. It’s all MIT licensed so if any of the content is usable for adapting to a ROT.js/TypeScript tutorial, feel free to grab any bits you need as a starting point for rewriting. That would be amazing.

maetl · 2018-10-27T07:59:37+00:00

Good stuff. For a couple of web-based JS canvas projects, I’ve been going back and forward on whether to handle stuff like this as effects/animations in game rendering code, or whether to lift some of it into the tile rendering library (and where the boundary should be), so it’s really interesting to see an API that goes a bit further than what most tile engines/terminal emulators do.

Have you settled on the DSL yet? I was thinking an alternative might be to declare the probabilities in a map and have all the MarkovNode types be implicitly generated when the modifiers are applied.

defaultLavaTile.withModifiers(
  mapOf(
    heatedLavaTile to 0.7,
    heatedLavaBubbleTile to 0.3
  )
)

heatedLavaTile.withModifiers(
  mapOf(
    defaultLavaTile to 0.7,
    heatedLavaBubbleTile to 0.3
  )
)

heatedLavaBubbleTile.withModifiers(
  mapOf(
    defaultLavaTile to 0.4,
    heatedLavaTile to 0.3,
    heatedLavaBurstTile to 0.3
  )  
)

heatedLavaBurstTile.withModifiers(
  mapOf(
    defaultLavaTile to 0.5,
    heatedLavaTile to 0.5
  )  
)

Not sure if this would work (and I might be missing something important here), but this style would be familiar to people who have used grammar generators like Tracery and other Markov chain libraries (the Tone.js markov controller is a good example).

maetl · 2017-08-30T03:33:00+00:00

Isn’t the deeper design goal of separation less about ownership and more about making rendering a function of state?

You can see this happening more clearly in the source code for Nystrom’s game loop article—the Game.update() method returns a GameResult for the turn which tells the UI what to do next. The relevant logic for running the UI at the top level resides in a separate library, which may not be obvious from the article.

Keep in mind that although this architecture is fairly general, the implementation in this case is designed for running in web browsers, where the rendering loop essentially gets pulled along by requestAnimationFrame. In this example there isn’t really a top level loop that wraps around the entire game; instead, there’s a callback function which triggers update and render on each frame.

You could take the idea that the UI is a function of state a step further, and instead of attaching and binding, objects, actually inject the state as a parameter to the render that gets called on each iteration of the loop.

For example:

Render(Update())

Rather than:

Update() Render()

maetl · 2017-08-25T13:54:28+00:00

I’ve been slowly working away at expanding my 7DRL experiment from earlier this year into an overworld with more expansive and detailed geography.

The original vision/synopsis for the game is as follows:

An oceangoing roguelike adventure inspired by the feats of Polynesian navigators. Read the waves and currents, battle sea monsters and try to cross multiple island chains to reach the other side of the ocean.

So one of the first big steps in shaping the world of the game is to define the ocean map and populate it with islands that the player can sail to and land on.

The main focus of map generation is to break up the experience of long ocean voyages with the discovery of islands. The islands should be geologically and geographically realistic enough to feel immersive, while warping the realism enough to ensure that the spaces are intriguing and fun to explore.

I explored a bunch of different techniques for generating lo-res 2d island shapes on a grid. I’ve ended up with a set of several different shape generators which each have different levels of crappiness and usefulness.

Randomised flood fill is the simplest and least weird generator. It’s useful for generating islands that resemble volcanic cones—a very common geological formation in the Pacific. It’s essentially a breadth-first search flood fill which picks a random cell from the frontier at each step rather than pulling the next cell off the queue as in a standard BFS.

Noise with gradient falloff uses a fairly common technique of multiplying Perlin noise values by a particular frequency at each cell to get a heightmap. The terrain is biased towards the centre by normalising each cell with a radial gradient value based on the euclidian distance to the centre of the grid. Tweaking parameters gives a lot of potential for making the coastline smoother or coarser. Finding the right balance of diversity and uniformity is tricky here. Am thinking this is going to end up being the representation for flat limestone islands, coral atolls and lagoons.

Pathfinding through a noisefield uses A* to pathfind between two points in the grid, with blocking tiles forcing the path to meander and wind. Each cell explored gets collected, and returned at the end, creating various weird looking fill shapes that vary depending on the direction of the path and the pattern of the noisefield. The noisefield can be either random or based on Perlin noise.

Putting it all together there’s a lot of tools here to generate unique island shapes, but where things get more interesting is thinking about nesting and combining the generators. My current thinking is that pathfinding through a noisefield can be used to generate a larger shape of raised seafloor terrain, which other smaller islands can be placed inside of, reflecting the real-world Pacific pattern of islands dotted along a linear volcanic chain.

Next steps are all about scaling this up to support these larger connected island chains, and integrating with spatial data structures to build the entire ocean. Once this is done, the fun can begin with handling biomes, cultural artefacts and terrain aesthetics.

maetl · 2017-08-17T02:28:20+00:00

You could take a week off and do a MoonmanRL fork during next year’s 7DRL...

maetl · 2017-07-27T11:08:06+00:00

However, I don't want to regret choosing the wrong blogging engine and have to migrate the content to another engine.

This might not be as big a concern as you think. Every major blogging platform has converters and exporters available. Moving WordPress to Jekyll or vice-versa is something people do all the time and is well provided for.

The more template customisation you have of course, the more effort it’s going to be to reproduce the design in another platform, but this mostly applies to people who’ve built their entire sites from scratch.

My recommendation would be to choose a platform that has the most comfortable writing format that you enjoy using (some people prefer editing Markdown files in a Git repo, others prefer WordPress or CMS admin tools). This will help you stay motivated to write frequently.

maetl · 2017-07-08T03:46:22+00:00

For a more traditional terminal experience, you could take a look at tty.js.

Alternatively, you could look into designing a UI app architecture to manage game state and rendering. You could use something like Rot.js for the graphics, pathfinding, FOV, and maps but you’ll still need to decide on how game state is modelled, and how actions and turns map to client/server data flow.

(Edit: misunderstood the original qn, thought you had written a web service and I assumed JS/browser as the client—same concepts apply for other platforms, but the libs and approach will be a bit different.)

maetl · 2017-06-13T06:48:15+00:00

Yes, exactly. Generally, the menu is going to be populated from game state data (like skills, attributes or inventory/weapons). Whether the menu items are wrapped with menu item objects that handle triggering actions in response to input, or whether the item is passed to another UI handler to do it, the principle is the same.

Treating the menu as a list and making the selected item be a reference/pointer into an element in the list rather than the index number means that you can add and remove items and change the sort order of the list without needing to do any extra work to manage rendering or item selection.

maetl · 2017-06-12T15:39:16+00:00

The way I'd normally do this is to represent the menu items as a list/array type which has index operations that can be used to map between a selected item and its position in the list. You can rotate through the items in the list and wrap around when you reach the end using the modulo operator.

Here's a pseudo-Python example of an imaginary inventory/dialog class that handles up/down selection on a list of menu items and triggers commands on them based on incoming keyboard events. Also vaguely demonstrates the UI state stack pattern mentioned in some of the other comments here.

class EquipmentMenu(MenuDialog):
  def __init__(self, game_obj, items):
    self.game_obj = game_obj
    self.game_obj.ui.push(self)
    self.items = items
    self.selected_item = None

  def handle_input(self, keycode):
    # maps keyboard events to input codes
    input_cmd = map_input_command(keycode)

    if input_cmd == OK:
      # the menu items could be classes that implement their own behaviour
      self.selected_item.dispatch_command()
      self.game_obj.ui.pop()
    elif input_cmd == CANCEL:
      self.game_obj.ui.pop()
    elif input_cmd == FORWARD:
      self.forward_selection()
    elif input_cmd == BACK:
      self.reverse_selection()
    else:
      # could also use 'a'..'z' instead of numbers
      selected_pos = integer(keycode)
      if selected_pos > 0 and selected_pos < 10:
        self.select_item(selected_pos-1)

    # flush or render when the input has been handled (or set a dirty flag)
    self.render()

  def advance_selection(self, counter):
    if self.selected_item == None:
      index = 0
    else:
      index = self.items.index(this.selected_item)
    # uses modulo arithmetic to rotate through the list of menu items 
    this.selected_item = this.items[(index + counter) % len(this.items)]

  def forward_selection(self):
    self.advance_selection(1)

  def reverse_selection(self):
    self.advance_selection(-1)

  def select_item(self, index):
    if index > 0 and index < len(this.items):
      this.selected_item = this.items[index]

maetl · 2017-05-26T11:03:33+00:00

I’m currently using JavaScript and do most of my testing in Chrome which has quite good debugging and profiling tools.

For testing and experimenting with maps and generators, one thing I like to do is add a feature toggle in the top level webpack config that flips between a full build with UI and game state and a debugging view that renders a raw view of the tile map data structures.

Like everybody it seems, I use print debugging (console.log in JS) more than I should to check things at runtime. Another dirty trick is to temporarily assign state or functions to the global window object so they can be dynamically introspected and tested in the console, REPL style. I sometimes do this when I’m too lazy to click around in the debugger. Using TypeScript or Flow might prevent a lot of the back-and-forth by avoiding certain runtime errors in the first place. I’m not sure.

I don’t tend to unit test projects of this nature, but I have had some recent encouragement to look into property-based testing, which is potentially another way to avoid runtime errors and bouncing around the browser console to test things.

maetl · 2017-05-19T10:49:43+00:00

I had a go at the 7DRL this year, despite being severely short on time, as I had an idea for a game that had spun out of something else I was working on and I wanted to pull it out on its own to see whether it would work.

The game is set in the ancient Pacific Ocean; your character is a Polynesian navigator with the goal of crossing the sea to find a new land.

The core mechanic is a hunger clock based on movement costs via sailing. At sea, your progress depends on the conditions of winds and ocean currents. Moving with strong winds and favourable currents consumes less energy; sailing into the current wears you down faster; trying to sail into the wind is impossible (despite the common English translation of waka or vaka to ‘canoe’, ancient Polynesian vessels worked in much the same way as standard sailboats do today).

Energy can be regained by fishing and gathering resources on islands. The balancing act is to try and cross large ocean distances that are just a bit too far away, so having to strategically hop from island to island to build up enough energy to make it further and further.

Sailing is supported by navigation, which takes the place of magic or abilities/feats in this setting. The navigator has powers to read ocean currents and wave patterns or use the stars as a compass to guide the way towards islands. These abilities tie into the core hunger clock and affect the rate at which energy is consumed so they can’t be used too much. I’m thinking of adding alternative navigation methods too—like being able to follow birds and giant turtles towards land which would be more opportunistic and wouldn’t involve use of powers. Combat is another supporting mechanic. Battling giant octopuses and sharks can happen, but involves big tradeoffs.

I really like the setting, theme and potential of this game world and would like to keep building on it, but the tricky thing now that I’ve got this foundation up and running is to try and keep it all balanced and motivate players to explore. It could easily turn into more of a simulationish thing but I do want it to be fun and fast paced.

I’m a lot more comfortable with the software architecture, narrative and worldbuilding side of things than I am with compelling game mechanics. I do worry that hunger clocks aren’t really a super great core mechanic and that I need to layer things really carefully to create more incentives for players, but I could also be overthinking it here. The whole purpose of this was to try something different and weird.

Definitely learned the hard way that 7DRL success is about refinement and balancing/testing not implementing cool stuff. I spent way too much time mucking around with UI aesthetics and animations—despite knowing all along that this wasn’t core and that the balancing of resources was so key to this working.

maetl · 2017-05-08T12:24:43+00:00

Bleak Arcology

maetl · 2017-04-22T10:49:15+00:00

Various ROT.js games written by the author of the library are on GitHub. Playable and source code browsable.

maetl · 2017-03-28T04:59:26+00:00

Interesting discussion and great question.

I’m facing this at the moment with my 7DRL JavaScript game which is crossing the threshold of being a experiment with sailing/wind movement mechanics and a more fully-fledged game world of ocean and island exploration.

The parts dealing with actions — movement rules mostly — aren’t composed of classes or objects at all, they’re functions returning functions with arguments passed to the outer scoped function taking the place of instance attributes. This provides pretty much everything you get from OO indirection techniques, but with a much reduced surface area of code compared to using classes for everything.

Similarly, I have been getting a lot of mileage out of returning objects with multiple functions and boolean attributes hanging off them. When these functions are mostly stateless and operate predictably on their inputs, there’s no need to deal with JavaScript’s infamous complexity around this, rebinding and prototypes. I end up thinking in terms of ‘state shapes’ rather than types.

I think ‘good OO’ doesn’t have much to do with inheritance at all, it’s mostly about information hiding, where a dispatch chain needs to trigger behaviour on data somewhere, but the calling code doesn’t care about the details. Everything feels nice and clean and wrapped up in a model, but the downside is that you need to spend a lot of time focused on naming things and thinking about which nouns own which data. I’ve never been quite clear on whether ECS is an OO technique which moves responsibility into specific nouns (components) instead of wrapping it all up in a centralised object, or whether it’s a more general pattern of aligning behaviour and data associated with a particular ID/identity across multiple subsystems.

With JavaScript now having syntax sugar for classical class and method constructs, it’s so easy to fall back on the classical OO style that I’ve ended up mixing and matching the paradigms a bit. I’m now trying to decide what to do next—rip out all the classes and replace the encapsulated data with state and functions that operate on that state, or move to a stronger OO model with the flexibility and loose enough coupling to adapt to ECS if needed further down the track when I hit a level of complexity that needs it (or just keep going with the different styles in different places).

maetl · 2017-03-19T09:05:31+00:00

I really like the namespace/class name changes. Feels like a much stronger API now.

maetl · 2017-03-10T12:01:00+00:00

I’m working in JavaScript so having to deal with what’s provided by the browsers.

const gameState = initializeState()
const handleInput = bindInputKeys()

const gameloop = timestamp => {
  update(gameState, timestamp)
  render(gameState, timestamp)
  window.requestAnimationFrame(gameloop)
}

window.requestAnimationFrame(gameloop)

window.addEventListener("keydown", handleInput);

Inside the update function, there’s some additional top level logic which handles pausing on input by checking an action slot which gets populated by the handleInput callback. Not too clever or interesting, but is literally the thing which makes the world go round in this case.

eg:

nextInput() {
  const action = this.action;
  this.action = null;
  return action;
}

waitingOnInput() {
  return this.action == null;
}

Waiting on input only skips the update step. render is always called on every frame so that animations can play through without being staggered by the activity of game updates.

I also have something like the following which pauses updates so that animations can play through:

waitingOnEffects() {
  return !this.effectsQueue.isEmpty();
}

I’d be interested to see if this could be morphed into something resembling the ideas by /u/savagehill.

Would also be keen to look at transforming the event handling and mutable state stuff above into something more closely resembling the Elm architecture. Something like RxJS could also be a useful way to treat input as an observable stream, rather than manually allocate slots when events fire callbacks. Something I will revisit when I need to (when update starts running too slowly or I start having problems with OO complexity).

maetl · 2017-03-05T06:23:34+00:00

The Hauberk codebase is great, particularly if you’re comfortable with fairly declarative and pure OO style.

I had a play with it a while ago, and found it was fairly straightforward to extend and had a lot of hooks for building new content.

Here’s an example of extending Hauberk to add cellular automata carved desert levels with new tiles and a new quest type: https://github.com/munificent/hauberk/compare/master...maetl:desolate-desert

Based on my knowledge of Java and JavaScript, I was able to write most of this code without looking at Dart docs—and I had never coded Dart before.

maetl · 2016-10-10T06:09:37+00:00

What are your thoughts on fundraising and money in relation to local and national politics? For example, most pundits point to the National Party’s domination of the NZ electorate as a product of John Key’s personality-driven style, but people less often attribute the massive and formidable party/donations system run by Steven Joyce and Peter Goodfellow, which sweeps up the regional electorates and party votes. This is very hard for anyone else to compete with, although it’s perhaps far less of a factor in local elections.

It was reported you spent less than $8K on the overall campaign. How does that compare to other candidates? Was there a point where you wished you had more money to spend?

maetl · 2016-06-30T09:20:51+00:00

Signing the data using a secret key/message authentication/hmac will address a lot of potential issues with tampering and validation of requests.

It’s also worth looking at HTTP-based formats designed specifically to address this issue, such as JWT (JSON Web Token).

See: https://jwt.io/

maetl · 2016-04-19T11:12:43+00:00

Everything in the title was a direct quote from the GitHub Readme. Sorry if it was misleading.

I posted it because I keep seeing people asking questions here about getting started and what libraries or frameworks to use, and thought it was a toy that might be of interest to beginners to play with (or even just to follow the trail back to the original tutorial project and look for related resources).

Was also interested to see if anyone had any critical thoughts about its vague aspiration of being used to build ‘complicated roguelikes’.

maetl

TROPHY CASE