🛠️ App Improvements​

• 🏠 Pushed the new games tab to be the landing home page, boosting your games to the forefront for new gamers.
• Upgraded the change game UI inside rooms to show curations just like on the home page 🖼️
• Added the ability for gamers to favorite your games so they can easily keep coming back for more 💗
• Finally brought the whole app into the beautiful new Rune redesign with updated settings and onboarding pop-ups visuals! 🎨
• Unveiled mutual friend suggestions—a simple addition that dramatically improved friend request rates 👥✨
• 🎮 Added all your games directly onto your public dev profile screens, making it easy for everyone to see your catalog of games.
• Upgraded all list scrolling animations on Android, making the app feel more polished!
• Allowed reporting other users for toxic comments or other public actions to maintain our positive gaming community 🚫💬
• 👁️ Slight visual tweaks to the total plays display on your games to clearly showcase their popularity!
• Added more channels for gamers to share your games directly, like Instagram and Snapchat 📣
• Upgraded our over-the-air update logic, making it easier than ever for gamers to update the app—sometimes seamlessly without even noticing 🚀
• Added new logging to track exactly how and where gamers launch your games, enhancing our homepage improvements 📊

🪲Bug Fixes​

• Resolved a tricky crash on Android 14 during background calls caused by stricter microphone permissions on Android’s end 📱
• Addressed more Android 14 issues where push notifications weren't opening rooms as intended 🔔
• 🤝 Fixed a bug where the match feedback screen reappeared if the app was closed and reopened during its display.
• Improved typing in Rune rooms on Android—no more letter skipping or input delays ✍️
• To prevent the keyboard from blocking games, it now dismisses automatically whenever any pop-up or modal screen opens ⌨️
• Fixed a few issues on the new home page, improving its robustness and preventing crashes when changing orientation from landscape to portrait 🔄
• Updated our chat logic to prevent the app from crashing when no sticker apps are available for sending GIFs!
• Adjusted our emoji picker for perfect visual alignment, eliminating jumping when selecting or deselecting on Android 😊
• Made visual fixes to landscape games to accommodate all different screen sizes and phone types 📐
• Improved the display count on game details—now all your friends who recently played fit neatly in the box 👯
• 🌍 Caught and fixed some translation errors in all the updated app copy.
• Fixed the occasional white flashing on the room join & made it less jarring.
• Improved friend suggestions by fixing an animation glitch optimized querying for mutual friends to improve performance 👥
• 🎧 Prevented exceptions that were being thrown when accessing room sound audio files, enhancing stability.

💻 SDK Improvements​

• Introduced the Dev Dashboards 🥳 https://dash.rune.ai/
• Refactored game error logging in preparation for sharing all this info with you all 🖥️
• 🌐🛡️ Correctly ignores blob requests if they are to the same domain as currently allowed ones, ensuring streamlined data handling.
• Bumped rune-eslint to the latest version (2.0.1 to 2.0.2) to fix the "Rune is not defined" issue that @Pixel Pincher was experiencing!
• Unveiled the latest dev UI with improved visuals and enhancements to prevent flashing!

There are a growing number of great games on Rune being played by millions of players every day. It's time to take a look at one of them of them - Duck Wars, that was part of the Rune Open Source Grants program. This incredible game was created by the talented developer, Ethan.

Play Duck Wars Now

What’s the Game?​

A classic implementation of BattleShip with a fun twist using rubber duckies as your targets. It's light hearted fun but fits the platform perfectly as a game that you can enjoy while still chatting with your friends. The art style and sound effects are just perfectly matched to the game play.

For those who don't know battleships in Duck Wars you place your ducks in the bath in any arrangement you like. The opponent does the same. You then take turns in taking pot shots and each other's ducks. The first one to blast all those pesky ducks wins.

What’s Great About It?​

Things that seem to work about Duck Wars on Rune (good tips for other devs):

• Well known classic game
• Bright and obvious graphical style
• New twist and style on the old classic
• Easy controls for mobile

Developer Interview​

Ethan kindly agreed to answer a few questions for us on his experience making games on Rune.

How long have you been building games?

Before developing Duck Wars, I had only built a few very small games in Unity occasionally over the years, so my game development experience is quite limited.

What gave you the idea for the game?

The idea for Duck Wars came from my girlfriend, who really loves ducks! Initially, I wanted to create a 1v1 multiplayer game, and combining that with a duck theme ultimately led to the concept of a duck-themed battleship game.

How long did the game take to build?

It took about two months to complete the game, though I worked on it off and on during that time. Progress was steady but varied depending on my schedule with school.

What was the most fun bit of the game to develop?

The most enjoyable part of the development was definitely implementing multiplayer using the Rune SDK. Having never worked with multiplayer before, it felt almost like magic to see how seamlessly it integrated with React. After laying the groundwork for the game, adding multiplayer functionality and seeing it come to life was incredibly satisfying.

Did you expect the game to be successful?

Honestly, I didn’t expect the game to be particularly successful. It started as a small, fun project I worked on the side without anticipating much. However, being able to see thousands of players engage with and enjoy the game has been a great surprise and incredibly rewarding!

What would you do different next time?

One thing I'd do differently next time is to incorporate regular user testing throughout the development process. Being able to get continuous feedback from players would have helped identify and address many of the issues I faced during development early on, improving both the development experience and the final product.

How did you find Rune to work with?

The experience of working with Rune has been really great! The documentation was clear and easy to follow. Whenever I had questions or encountered issues with the SDK, I could reach out to the developers on Discord and they would promptly address them. The developers also sought feedback on my experience with the SDK and asked for suggestions on how they could improve the development experience, which I really appreciated!

Anything else you'd like to say?

Be sure to check out my other game on Rune, called Tap Party!

What Do the Players Think?​

Here's some of the thousands of player's comments on the game

My favorite game by far!

such a fun game with nice background music! I love this

Best game ever!

It's clear that Duck Wars is well loved! Ethan has built a great game and entertained a huge number of players worldwide!

If you’d like to talk about the game, learn how it was built, or build your own, drop by our Discord.

At Rune, we want you to be able to use game development tools that you love with our platform. With this in mind, we’ve adapted the tutorial game from the popular framework Phaser to be multiplayer on Rune.

Approach​

Phaser is wonderfully powerful as a game library, and one of its key concepts is putting everything into the scene graph. This is fantastic for a single player game since the physics/collision can happen on the client side where the scene graph lives. However, when you approach multiplayer (with any framework) the game needs to be able to run its physics both on clients and validating server. With this in mind in this tech demo we’ll move the physics into the logic of the game and use a separate library to manage it.

Outside of this the Phaser framework can be used as normal.

Client Side​

To anyone who's used Phaser before this will look pretty familiar. For those who haven't this is setting up a Phaser runtime and renderer and loading the assets that will be used to render the game:

export default class TutorialGame extends Phaser.Scene {
  preload() {
    // preload our assets with phaser
    this.load.image("sky", "assets/sky.png")
    this.load.image("ground", "assets/platform.png")
    this.load.image("star", "assets/star.png")
    this.load.image("bomb", "assets/bomb.png")
    this.load.spritesheet("dude", "assets/dude.png", {
      frameWidth: 32,
      frameHeight: 48,
    })
  }
}

const config = {
  type: Phaser.AUTO,
  width: window.innerWidth,
  height: window.innerHeight,
  scene: TutorialGame,
  scale: {
    mode: Phaser.Scale.ScaleModes.FIT,
  },
}

new Phaser.Game(config)

Here's the first difference to a normal Phaser application. Since we're going to be using Phaser for the rendering only (the physics will be happening in the game logic) we're going to add a mapping table that will convert physics object on the server to the client side scene graph elements:

  physicsToPhaser: Record<number, Phaser.GameObjects.Sprite> = {}
  lastSentControls: Controls = {
    left: false,
    right: false,
    up: false,
  }

You can also see lastSentControls above. Since Phaser is providing the input from the player and we need to send that to the logic, we'll record the controls we sent last time. We want to avoid sending the controls more often than needed to avoid wasted networking communications by making sure we only send the inputs when they change.

Next up we have the Rune integration. We initialize the Rune SDK with a call back function that tells us when game state is changing. In this case this means when our physics objects have been created, updated or deleted. When we get this notification, we're going to scan through the state and update the Phaser rendering to match. First, we locate each physics body in the phaser world:

 // for all the bodies in the game, make sure the visual representation
// exists and is synchornized with the physics running in the game logic
for (const body of physics.allBodies(game.world)) {
  const rect = body.shapes[0] as physics.Rectangle

  const x = Math.ceil(
    (body.center.x / PHYSICS_WIDTH) * window.innerWidth
  )
  const y = Math.ceil(
    (body.center.y / PHYSICS_HEIGHT) * window.innerHeight
  )
  const width = Math.ceil(
    (rect.width / PHYSICS_WIDTH) * window.innerWidth
  )
  const height = Math.ceil(
    (rect.height / PHYSICS_HEIGHT) * window.innerHeight
  )

  let sprite = this.physicsToPhaser[body.id]

If we don't have a sprite for the body yet, we create the right one based on the type of body we've been given:

// if a sprite isn't already created, create one based on the type
// of body
if (!sprite) {
  if (body.data && body.data.star) {
    const size = Math.ceil(
      (rect.bounds / PHYSICS_WIDTH) * window.innerWidth
    )
    sprite = this.physicsToPhaser[body.id] = this.add
      .sprite(x, y, "star")
      .setDisplaySize(size * 2, size * 2)
  } else if (body.data && body.data.player) {
    // create the player and associated animations
    sprite = this.physicsToPhaser[body.id] = this.add
      .sprite(x, y, "dude")
      .setDisplaySize(width, height)

    this.anims.create({
      key: "left",
      frames: this.anims.generateFrameNumbers("dude", {
        start: 0,
        end: 3,
      }),
      frameRate: 10,
      repeat: -1,
    })

    this.anims.create({
      key: "turn",
      frames: [{ key: "dude", frame: 4 }],
      frameRate: 20,
    })

    this.anims.create({
      key: "right",
      frames: this.anims.generateFrameNumbers("dude", {
        start: 5,
        end: 8,
      }),
      frameRate: 10,
      repeat: -1,
    })
  } else {
    sprite = this.physicsToPhaser[body.id] = this.add
      .sprite(x, y, "ground")
      .setDisplaySize(width, height)
  }
}

Finally, once the sprite is definitely in the world we update it to match the body position based on what the logic has given us:

// update the sprites position and if its a player the animation
sprite.x = x
sprite.y = y
if (body.data?.player) {
  const controls = game.controls[body.data?.playerId ?? ""]
  if (controls) {
    if (controls.left) {
      sprite.anims.play("left", true)
    } else if (controls.right) {
      sprite.anims.play("right", true)
    } else {
      sprite.anims.play("turn", true)
    }
  }
}

The final step is pass the input from the phaser side into the logic so we can update the physics model. First we record the input, we have on screen controls which we can listen to:

const left = document.getElementById("left") as HTMLImageElement
const right = document.getElementById("right") as HTMLImageElement
const jump = document.getElementById("jump") as HTMLImageElement

left.addEventListener("touchstart", () => {
  gameInputs.left = true
})
right.addEventListener("touchstart", () => {
  gameInputs.right = true
})
left.addEventListener("touchend", () => {
  gameInputs.left = false
})
right.addEventListener("touchend", () => {
  gameInputs.right = false
})
jump.addEventListener("touchstart", () => {
  gameInputs.up = true
})
jump.addEventListener("touchend", () => {
  gameInputs.up = false
})

Then in the Phaser update if the inputs have changed, we pass them to our logic through a Rune action:

update() {
  // As with the physics we don't want the controls to be processed directly in the
  // the client code. Instead we want to schedule an action immediately that will update
  // the game logic (and in turn the physics engine) with the new state of the player's
  // controls.
  const stateLeft = gameInputs.left
  const stateRight = gameInputs.right
  const stateUp = gameInputs.up

  if (
    this.lastSentControls.left !== stateLeft ||
    this.lastSentControls.right !== stateRight ||
    this.lastSentControls.up !== stateUp
  ) {
    this.lastSentControls = {
      left: stateLeft,
      right: stateRight,
      up: stateUp,
    }
    Rune.actions.controls(this.lastSentControls)
  }
}

And that's our client done!

Logic Side​

On the logic side, we're going to maintain a propel-js physics models that represents our world in the game state. We'll update this each loop and that state will be passed back to the Phaser client to render.

First, we'll setup some game state containing the physical world and state of each players controls, essentially what we need to update the world.

export const PHYSICS_WIDTH = 480
export const PHYSICS_HEIGHT = 800

export interface GameState {
  world: physics.World
  controls: Record<PlayerId, Controls>
}

export type Controls = {
  left: boolean
  right: boolean
  up: boolean
}

type GameActions = {
  controls: (controls: Controls) => void
}

declare global {
  const Rune: RuneClient<GameState, GameActions>
}

Next we'll initialize the Rune SDK and configure the world to have our players, platforms and stars:

Rune.initLogic({
  minPlayers: 1,
  maxPlayers: 4,
  setup: (allPlayerIds) => {
    const initialState: GameState = {
      world: physics.createWorld({ x: 0, y: 800 }),
      controls: {},
    }

    // phasers setup world but in propel-js physics
    physics.addBody(
      initialState.world,
      physics.createRectangle(
        initialState.world,
        { x: 0 * PHYSICS_WIDTH, y: 0.2 * PHYSICS_HEIGHT },
        0.5 * PHYSICS_WIDTH,
        0.05 * PHYSICS_HEIGHT,
        0,
        1,
        1
      )
    )
    physics.addBody(
      initialState.world,
      physics.createRectangle(
        initialState.world,
        { x: 0.75 * PHYSICS_WIDTH, y: 0.4 * PHYSICS_HEIGHT },
        0.5 * PHYSICS_WIDTH,
        0.05 * PHYSICS_HEIGHT,
        0,
        1,
        1
      )
    )
    physics.addBody(
      initialState.world,
      physics.createRectangle(
        initialState.world,
        { x: 0.5 * PHYSICS_WIDTH, y: 0.6 * PHYSICS_HEIGHT },
        0.5 * PHYSICS_WIDTH,
        0.05 * PHYSICS_HEIGHT,
        0,
        1,
        1
      )
    )
    physics.addBody(
      initialState.world,
      physics.createRectangle(
        initialState.world,
        { x: 0.5 * PHYSICS_WIDTH, y: 0.9 * PHYSICS_HEIGHT },
        1 * PHYSICS_WIDTH,
        0.3 * PHYSICS_HEIGHT,
        0,
        1,
        1
      )
    )

    // create a player body for each player in the game
    for (const playerId of allPlayerIds) {
      const rect = physics.createRectangleShape(
        initialState.world,
        { x: 0.5 * PHYSICS_WIDTH, y: 0.5 * PHYSICS_HEIGHT },
        0.1 * PHYSICS_WIDTH,
        0.1 * PHYSICS_HEIGHT
      )
      const footSensor = physics.createRectangleShape(
        initialState.world,
        { x: 0.5 * PHYSICS_WIDTH, y: 0.55 * PHYSICS_HEIGHT },
        0.05 * PHYSICS_WIDTH,
        0.005 * PHYSICS_HEIGHT,
        0,
        true
      )
      const player = physics.createRigidBody(
        initialState.world,
        { x: 0.5 * PHYSICS_WIDTH, y: 0.5 * PHYSICS_HEIGHT },
        1,
        0,
        0,
        [rect, footSensor]
      ) as physics.DynamicRigidBody
      player.fixedRotation = true
      player.data = { player: true, playerId }
      physics.addBody(initialState.world, player)

      initialState.controls[playerId] = {
        left: false,
        right: false,
        up: false,
      }
    }

    // create a few stars to play with
    for (let i = 0; i < 5; i++) {
      const rect = physics.createCircleShape(
        initialState.world,
        { x: i * 0.2 * PHYSICS_WIDTH, y: 0.15 * PHYSICS_HEIGHT },
        0.04 * PHYSICS_WIDTH
      )
      const star = physics.createRigidBody(
        initialState.world,
        { x: i * 0.2 * PHYSICS_WIDTH, y: 0.15 * PHYSICS_HEIGHT },
        10,
        1,
        1,
        [rect],
        { star: true }
      ) as physics.DynamicRigidBody
      physics.addBody(initialState.world, star)
    }

    return initialState
  }

As seen above, for each body, we set user data indicating the type of body it should be rendered as. This game state will immediately be sent back to our client, which will create sprites in the Phaser scene graph and position them accordingly..

Next, we need to process the input action we provided from the client. This is as simple updating our game state to know which controls a player is pressing:

actions: {
  controls: (controls, { game, playerId }) => {
    game.controls[playerId] = controls
  },
},

The final step of our update loop is update the physics model based on the controls provided from the player clients:

update: ({ game, allPlayerIds }) => {
  // each loop process the player inputs and adjust velocities of bodies accordingly
  for (const playerId of allPlayerIds) {
    const body = game.world.dynamicBodies.find(
      (b) => b.data?.playerId === playerId
    )
    if (body) {
      if (game.controls[playerId].left && !game.controls[playerId].right) {
        body.velocity.x = -100
      } else if (
        game.controls[playerId].right &&
        !game.controls[playerId].left
      ) {
        body.velocity.x = 100
      } else {
        body.velocity.x = 0
      }

      // check if we're on the ground
      if (body.shapes[1].sensorColliding) {
        if (game.controls[playerId].up) {
          body.velocity.y = -600
        }
      }
    } else {
      console.log("Body not found")
    }
  }

  // propel-js likes a 60fps game loop since it keeps the iterations high so run it
  // twice since the game logic is configured to run at 30fps
  physics.worldStep(60, game.world)
  physics.worldStep(60, game.world)
}

Above we can see that we apply velocities directly to the bodies in propel-js based on the controls the player have provided. We're also using a foot sensor to determine if the player is on the ground and hence if they can jump. One other note here is a nuance of propel-js, our game logic is running at 30fps but the physics model works best at 60fps so we simply run two updates.

There you have it, a multiplayer version of the Phaser sample with the Rune SDK. It takes a little bit of rethinking of the model but we can make use of a lot of power of Phaser!

Want to know more? Why not drop by the Discord and have a chat?

🛠️ App Improvements​

• Unveiled the new home (games 🎮) tab, now featuring game carousels with expandable curation lists like "Puzzle" or "Action" games!
• Revamped our game details page with updated visuals, new play and matching buttons, social proof of how many people love your game, and many more improvements! 🤝
• Added in fun room sounds that pop 💥 so you can easily know when someone leaves, enters, or is reconnecting even without looking at your phone!
• Shuffled avatar features around in the editor to look better and make more sense 🎨
• 🖼️ Now clicking an avatar anywhere in the app shows the user's profile — quick and easy!
• Upgraded our main page logic: now it auto-scrolls back to the top when you re-tap the tab’s button on the loaded screen 👆

🪲Bug Fixes​

• 👥 Updated the friend suggestion logic to recognize when you've added someone as a friend elsewhere in the app.
• Fixed a crash that was happening when auto scrolling to the top on the friends tab if you're already there and have no friends.
• Busted a small bug where the "friends" label occasionally wasn't showing on friend profiles 🐛
• 🎤Fixed some voice chat start errors by fixing the feedback screen logic!
• Updated our TikTok social link in the app so everyone can stay up to date on all things Rune 🔗

💻 SDK Improvements​

• Built out our behind-the-scenes game tracking to prep for some exciting new developer features coming soon! 🌟
• Fixed the dev UI mobile layout to account for bottom toolbars on some devices & adjusted the minimum dimensions on landscape 📱
• Added Vue game template built by oats 🚀
• Updated example user avatars to ensure you’re inspired by the newest content!
• Vite plugin now includes logic that allows importing not only external package but also files from external package (somePackage vs somePackage/innerFile). This was done by Pixel Pincher! 🥳

When you’re building any client software, it’s useful to know what types of hardware your end users have – doubly so with experience-centric software like games. For the types of games I like to build, even the lowest-end desktop hardware has been more than enough for many years. However, for mobile game platforms like Rune, the types and power of devices that end users have can dramatically affect the player experience.

In this article, we’ll look at the types of devices and their capabilities found in the Rune user base. We’ve taken the top 30 most popular mobile devices on Rune (accounting for about 2 million users) and broken the data down by processor, GPU, screen size, memory, and release date.. As you can see below, in mobile game development, there’s still a huge range of capabilities to account for.

Screen Size​

The graph above shows the screen resolutions in device-independent pixels. There’s a huge variety of screen sizes in use, going all the way down to significant numbers (40k) of users with screens as low as 375x667. Likewise, the top end has over 50k users with 2399x4973 screens. Responsive design is key.

Memory​

The spread of onboard memory is also wide, going as low as a single GB. The top end is quite low compared to very modern devices, maxing out at 8 GB. This, of course, is only in the top 30 devices in a much bigger user base, but it gives you an idea of what the games need to run on.

Processor and Graphics​

The following charts show the spread of CPUs and GPUs on the devices playing your games today.

Processor​

Graphics​

Analyzing the graphs above, we can see there are essentially two types of devices being used:

• Octa-core CPU, Mali/PowerVR GPU class devices. These are reasonably powerful and will cope with most Rune games very well.
• Quad-core CPU, Adreno GPU class devices. These are the budget devices that we see so many in Gen Z having due to the lower cost. These are the ones that you need to target to get maximum playtime for your games.

Release Year​

One final piece of information: the release year of the devices in the top 30.

This explains the other data: the majority of devices in the top 30 are 4–5 years old.

Hopefully, the data here will help focus and tailor your game development efforts to get the maximum playtime from our player base.

Does this align with what you’ve seen? Want to know more? Why not drop by the Discord and have a chat?

At Rune, the majority of the games on the platform are multiplayer. This is largely because we provide an SDK that enables JavaScript developers to build multiplayer experiences very easily, and our player base has come to expect it. Of course, as mentioned in Modern Game Networking Models, this means we focus on making the backend networking something special.

There are a lot of ways of making games multiplayer, from hot seat to shared screen and of course networking itself. Even in networking, there are multiple models to choose from each of which is suitable for a different type of game or programming complexity.

If you’re building a network layer for a single game or a bunch of very similar games then choosing the network model that’s the easiest and satisfies those game constraints is the best move.

However, at Rune, we’re pretty opinionated about a single model that works for all cases, predict-rollback. We need to provide a single common framework for all the games on Rune and so we focus on one networking model that supports the massive variety of games on the platform.

Predict-Rollback​

In Modern Game Networking Models we talked in a bit of detail about how predict-rollback works. In summary, we essentially let all clients continue moving forward predicting the current game state based on the inputs they know about. If another client provides a new input (via the authoritative server) that occurs before the game time the current client is at, we roll-back the game state, apply the input, and then re-predict the current state.

So why do we think predict-rollback is the future of networking games and the best fit for a generic networking framework?

• Some great games have used it to provide excellent multiplayer experiences, like Rocket League and Street Fighter. They also do an amazing job of hiding the rollback/changes when they occur.
• It works for all cases, whether it's turn-based, RTS, or faster-paced twitch games; predict-rollback provides a stable, consistent approach. Even in turn-based games, where there should be no rollbacks, the simple simulation modified by inputs approach still fits the bill.
• There’s growing library and platform support. Unity, Godot, and even Valve’s Source engines all have plugins that support this model.

What’s so great about the model then?

• Low bandwidth—you only need to send the initial state and changes to that state. That’s pretty powerful right there. The variance in networks especially with the emerging nations becoming a huge consumer of games means this is super important.
• Best player experience—in many cases, it means that clients can run forward without latency between player input and response. Of course, you need to deal with conflicts when they occur, but this seems to be much easier than the alternatives.
• Most consistent implementation—once you’ve got determinism handled, it’s the most consistent approach across platforms and devices.. Every device acts the same and gets the same results.

What are the downsides? The process of rolling back and re-calculating the game state can be CPU heavy. Depending on your approach you may have to calculate many frames of change quickly based on the new input. However, this is why it’s now the right choice. Devices have reached a point where CPUs are extremely overpowered for what they’re trying to achieve in games - so there’s room to have a smart and utility based network model.

Of course, if you’re building a network model for a specific game, there are many tricks and game-specific approaches you could take.

If, however, you're building a library/framework that supports many types of games in many different environments and on different devices, predict-rollback is the right choice for now and the future.

Want to learn more about our approach or simply want to discuss the content of this article? Stop by our Discord and let’s chat!

Hey everyone! 🎉

The energy around our very first Rune Jam has been so incredibly positive, welcoming and and uplifting, and we’re thrilled to finally announce the winners of this creative extravaganza!

For 10 whole days, you devs crafted away, the theme of "Creativity," and the results were nothing short of spectacular. Now, let's celebrate the winners who captivated gamers the most:

🥇 First Place: Tonai with Scribble - 14,630 minutes

• Our top game is writing home with a Rune merch bundle featuring a stylish t-shirt, a cool hat, and a handy water bottle.

🥈 Second Place: PixelPincher with Chillville - 10,372 minutes

• A fantastic hangout game deserving of a Rune t-shirt and hat.

🥉 Third Place: JumpArtifact with Triangle Artistry - 1,730 minutes

• Rounding out our top three 📐 with a well-earned Rune t-shirt.

We cannot thank everyone enough for making Rune's 1st Jam an unforgettable event. Any game that didn't make the top 3 leader board still will receive some awesome Rune stickers as a token of our appreciate for your efforts and creativity.

While we celebrate the winning games, we truly believe that the Rune gamers were the real winners here. Every single one of these games were a ton of fun and the playtime hours are definitely a testament to that!

Stay tuned for more events like this, and keep pushing the boundaries of creativity! Happy developing, everyone! 🌟

Want to find out more? Why not stop by our Discord and let’s chat!

At Rune, we’ve got a platform that lets developers get their games out to millions of players on mobile devices across the world. With that number of players, you can imagine the device range is also wide. While Rune abstracts a lot of this complexity away, there are still a few things developers need to consider.

Cross-Platform Design​

The most obvious area is the design of the visuals and fitting it to the various screen sizes out there. The range of screen sizes is shown below along with the different approaches you can take to deal with them.

Tiny UI​

Probably the easiest approach is to simply make your UI tiny or limited in such a way that it’ll fit on any screen. This is often the most effective game visual design approach since it also encourages you to limit what's going on in terms of user interface - which leads to less reading, which is something the audience wants.

If you design for 360x600, you’re likely to be fine in 99% of cases. However, this does limit your creativity to this reasonably confined space. It also means players with larger screens won’t feel the benefit.

Responsive​

With responsive design, the developer creates a UI that responds to the screen size available. This is very common in web and app design, but not so much in game design. A responsive design takes some thinking about; elements of the UI and game interface are described in terms of their proportion to each other. So, maybe the logo is 25% of the height of the screen and the start button is 10% – no matter the size of the screen, those elements will fill 30% of it.

For games, this can be hard since the elements of a game UI are often extremely richly styled – themed to fit the game. Unlike traditional web and mobile applications where the UI is reasonably simple, in an RPG the UI might be built out of intricate gold edging with scrolls filling in the background with complex textures. Making this scale up and down for different screen sizes automatically can be difficult.

Custom​

For those developers with the time and inclination, we have the custom approach, and surprisingly, where many commercial games end up. The developer creates a code base that has different layouts and assets for different scenarios. Most common is the tablet/mobile split, where depending on the device, the UI is significantly different. However, this same approach can be applied to pure phone sizes by categorizing them:

• nHD - around 640x360 pixels,
• qHD - around 960x540 pixels
• HD - around 1280x720 pixels
• HD+ - around 1600x900 pixels

This gives us fixed targets for the custom code to work against. Pick the lowest one that’s less than or equal to the actual resolution and use that layout code.

Performance Characteristics​

Here are some of the top devices and their specifications taken from over 10 million recorded devices on the Rune platform.

Even just looking at the top 10 or so, we can see a reasonably wide range of available hardware.

CPU​

Mobile CPUs are getting faster all the time, but there are still plenty of low-specification devices out there. You also have to consider that the device will be running other applications at the same time as your game and if you’re using Rune, it’ll be used for a voice call as well.

It’s best to avoid CPU intensive loops making, sure your code does this in small sections over multiple rendering frames rather than attempting to process a lot of data in one go.

The pauses caused by CPU operations being locked up with a tight loop are the number one cause of player abandonment. That crazy button mashing when your phone seems to have stopped responding, resulting in the app/game eventually coming back but immediately closing. Users don’t like the feeling of their phone not working and so rarely open the application a second time to give it another chance.

GPU​

Graphics chip usage is one of the most common causes of a very good game failing to spread across the mobile universe. Mobile graphics performance varies a great deal even from devices over the last 5 years. Your beautiful 3D game isn’t going to be so interesting for a player who is seeing it at one frame every three seconds while holding a phone that’s melting in their hand.

Keep it simple, especially 3D. Low-poly models don’t have to mean ugly. Multi-pass rendering should be used sparingly – a shadow pass is normally enough to make it feel real.

Also, it’s worth keeping in mind that the final game is going to be played on a 6.5-inch device; what you see on your monitor where it’s scaled up isn’t what will be visible to someone looking down at a tiny device. Avoid obsessing over the tiny detail you can see that no player ever will.

Physical Properties​

One aspect that’s often overlooked with cross device games design is the physical aspects of the different devices.

First, we have the physical size of the design, especially when you’re thinking of two-handed controls on portrait games. What feels nice proportionally on a large device (8 inches or more) will often be uncomfortable to hold on a smaller device (around 6 inches). It’s worth finding items of the right size to test the feel of the controls (I use cardboard, cut and measured).

Second, “notches” – oh, how we hate them! Ever since the iPhone introduced the camera notch, web and game designers have despaired. Different devices now have different notches and notch sizes, meaning developers need to consider what’s called the “safe area.” As a game designer, of course, you want to fill the screen with the assets, so you both have to account for the notches but also avoid putting anything important there.

Luckily, if you’re writing games on Rune, it handles the safe area/notches for you leaving you with a clean rectangular area in which to put your game!

Making your game work well cross-platform and cross-device increases the number of potential players you have access to. In multiplayer games, it’s also key to make sure the experience is as similar as possible across devices to keep the game feeling “fair”.

If you have any questions or have anything to add, come join us on Discord.

At the core of Rune, we have games being enjoyed by millions of players. I’m glad to take the time to celebrate one of them, Melancia, that has been doing very well on the platform. This wonderful game was made by jallen.

Play Melancia Now

What’s the Game?​

Deceptively simple, the game features a Tetris-style well in which the player drops brightly colored fruits. When two fruits of the same type collide, they combine to make the next bigger fruit. The aim, as the name of the game may give away, is to make melons by combining all the other fruits. Other players are also playing in their own wells, trying to get to the melons before you.

It’s a clean concept implemented with especially satisfying physics and sounds that evidently keep players coming back for more. There’s something very delightful about the pop as you make your next fruit combinations.

What’s Great About It?​

Things that seem to work about Melancia on Rune (good tips for other devs):

• Simple, understandable mechanics with no text to read
• Bright and obvious graphical style
• Physics—especially shared physics—make for a pleasing experience
• Easy controls for mobile

How Does It Work on Rune?​

The game was implemented on the Rune SDK without having to change anything or take any special measures. If you’d like to see for yourself, the source is open:

https://github.com/jallen-dev/dusk-games/tree/main/games/melancia-game

The game was built over the course of a week, which, while short for game development, is pretty common amongst Rune games. It doesn’t take months of work to put out something to millions of players!

Developer Interview​

Jallen was kind enough to answer a few questions for us on the game and the development process.

How long have you building games?

About a year. I'm originally a web dev who has been easing into gamedev by making games in React, pixi.js and three.js.

What gave you the idea for the game?

It's heavily inspired by the game "Suika Game" which went viral last year. The main way Melancia Game differs is it's multiplayer and a race against the clock. It also puts less emphasis on the puzzle aspect, since there is no penalty for your fruit spilling out of the top of the container.

How long did the game take to build?

1 week. I started it on March 12 and it went live on March 19.

What was the most fun bit of the game to develop?

Figuring out how to get the physics library to play nicely with Rune. It was a fun challenge to solve, and I tested a few different solutions. What I ended up going with is having the client send the position/rotation/velocity of every fruit each time it drops a new fruit, so that the other clients can sync. Since each player has their own separate container of fruit, it's not really a problem to let each client be the source of truth for that player's fruit state.

Did you expect the game to be successful?

I had a feeling it would do well, since it's based on a hit game. I think my changes to the gameplay also helped it be a better fit for Rune's audience. It's faster-paced and requires less deliberation, which is ideal for a casual game over voice chat. Still, I was surprised by just how well it has done.

What would you different next time?

Use propel-js to do the physics logic side. My solution with syncing state is a bit of a hack. Plus having the physics in logic would enable new features, like players sharing the same container (i.e. a co-op mode).

How did you find Rune to work with?

It's fantastic. Small API surface, not opinionated about what you use to build your game's client. I think it's great for most types of web games.

Anything else you'd like to say?

If you liked this game you might like another one of my games that shared the same inspiration: https://coinjargame.com/

What Do the Players Think?​

One player comments:

The game is just cool

Another player says:

The game is simply top

I think they like it! Thanks so much to jallen for building the game and giving joy to so many players around the world.

If you’d like to talk about the game, learn how it was built, or build your own, drop in at the Discord.

I’ve built a few game servers over my career, including session-based mini games and an MMORPG. At Rune, that experience comes in handy as we’re building a game architecture that needs to support 10 million players. Getting the architecture right is key to having something scale in the long term.

There are lots of resources around the web on game server architecture, but it’s also worth noting that the requirements for gaming are very similar to voice/video conferencing (maybe that’s why WebRTC fits so well?) - so it’s worth checking out the architectural approaches there too.

The following are some of the issues and requirements to consider when building your own scalable multiplayer game architecture.

Matchmaker vs. Real-Time​

Most games have some form of matchmaking, or working out the best pairing of players. Some games also have social and configuration type activities that don’t require player-to-player interaction. These are normally categorized as “matchmaking.” The requirements on latency in these scenarios are reasonably low. If a player is choosing a map or finding another set of players to compete with, a second or more response time is acceptable.

Once the players actually start playing the game, they immediately have a different set of requirements. In the “real-time” phase, player latency changes the game experience dramatically. It’s important that we’re optimizing for low latency on the network and high throughput on the server activities.

Since there are two different sets of requirements, it’s good practice to split these two scenarios into different components in the architecture. In the diagram above, we have the split between the central server - responsible for our matching type activities, and the real-time regional servers used for relaying in-game messages.

Regional Servers​

As mentioned in Modern Game Networking Models, one of the first things to think about in any networked game is making sure that the connection between client and server is the best it can be.

Even if you assume everyone is on a great connection (something that isn’t true!), in the best case, network packets travel at the speed of light. If players are connecting from anywhere in the world, then the distances between a central server and the clients add up to significant latency.

To solve this, it’s ideal to introduce regional servers, that is, servers that are closer to clients. This limits the distance the packets have to travel and hence lowers the latency.

The downsides here are that running lots of servers is costly, and of course, if players want to play together from very distant locations, you have to choose one region for them to play on that might not be optimal for them.

Where players are a long distance from each other you have essentially two options:

1. Pick a regional server that’s equally distant from both. This ensures they both get a similar network experience - although not optimal for either.
2. Rely on backbone trunking. Connecting across the public internet can be slow for lots of reasons (e.g., poor cell/wifi, lots of network hops). The backbone fabric that your servers run on is often much faster. We can choose to have the players access a local regional server as an access point and then connect these regions via the faster backbone.

Load Balancing​

Any scalable system needs to be able to add capacity through adding servers and this means load balancing. The split between matchmaking and real-time also changes how we do load balancing.

On the central server, the load balancing can act largely like a web application, that is, load balancing can be stateless and we rely on the database as the synchronization layer. If a player applies a change to their skin, the application can make a change, store it in the database and on the next invocation read it back from the database. There’s no running state that needs to be maintained between invocations.

However, on the real-time server, there will be several pieces of state:

• The connections from the players themselves. As mentioned in WebRTC vs WebSocket, for high performance we want to establish and maintain a connection between clients and the real-time server. The connection must not be dropped between interactions with the server.
• The server is running the authoritative part of the game, making sure that the players see the same state and don’t cheat. The server may also be running part of the game logic such as computer-controlled actors and in-game events. This needs to continue to run whether players are taking actions or not.

Since the real-time server is stateful, the load balancing needs to connect to the same server for all players in the same session. In an MMORPG this means the zones the players are allocated to a server and all players in those zones connect to that server. In Rune, this means that the room/game combination is allocated to a server in the same way.

More generically in load balancing, this is known as “sticky sessions.” When a connection is made to the load balancer an attribute/parameter of the connection is used to determine where the connection needs to go. This of course makes the load balancer that bit more complicated and often leads to custom load balancing solutions.

Database​

For most online games, databases are key to maintaining the long running state and storing player profiles, levels etc. The central server uses the database to maintain state between invocations so it’s heavily used and operations often rely on results from the database. This behavior is common in web application architectures too and means being very careful with your database performance.

On the other hand, the real-time server use of a database cannot block operations. Real-time exchanges are measured in millisecond latency and any blocking based on a database is likely to degrade player experience. On the real-time server it’s generally preferred to avoid any database read access in the core network flows - instead pulling the data required at the start of the session and holding it in memory.

There are of course cases where actions in the real-time server where the database needs to be updated to reflect changes the player has made. Whenever possible keeping these interactions asynchronous is the best approach.

The matchmaking and real-time servers should have a separate database (or at least a different set of tables/schema) that they act on. This allows us to have different rules of engagement to the database in each case and to be able to tune the database in each scenario for its specific expected use.

The final point of database interaction is where the updates on the real-time server need to be passed back to the central server, or vice versa. Again, whenever possible this needs to be an asynchronous process so that it doesn’t interfere with the real-time server run-time operations.

Metrics​

Final, but important, point: don’t forget metrics/observability. When scaling any system it’s key to be able to understand how the system is operating and even more how any change that you make affects the performance and stability.

Applying metrics after the fact is actually pretty hard, trying to instrument or interpret database everything once it’s all in place and the implementation has passed is time consuming and error prone.

When building a scalable system design and add the metrics to the features as they’re implemented. Having well-thought-out and intentional metrics is the only way to really tune and improve an architecture.

If you found this article interesting or have questions, drop by the Discord.