timetocode

A blog about game development and procedural content generation.

First time here? Try the graphical archive of all posts.

Feel free to email me or Tumblr ask | FAQ | Also on Twitter @bennettor

...querying twitch.tv... http://www.twitch.tv/timetocode

Space game demo

It’s just a very quick tech demo. You appear as a little ship and can shoot asteroids (that’s all there is to do). It happens to be multiplayer, in the unlikely event that someone else connects at the same time. 

Play it here: http://spacegame.timetocode.com/

Hopefully it works in your browser. I’ve only tested chrome, ff, and the latest ie on win7.

Move with WASD and left click to shoot. Reload the page (CTRL-R?) to respawn if you die or somehow get lost.

There isn’t much in the way of feedback for taking damage or dying. Damage will just reduce shields or hull, and grant a temporary half second of invulnerability.  Dying… well… the ship just disappears. It can no longer move, but it can still shoot (this is when its time to reload the page).

If you’re looking for a little bit of extra trouble, make your way to the top left and aim for the the largest of the asteroids. The asteroid spawner will go a bit crazy. All the asteroids divide into smaller and smaller rocks and decay away eventually. One large asteroid will always spawn in the top left, seeding the map with rocks — if you keep destroying it, it’ll keep respawning and spamming rocks.

Now that I’ve solved most of the logistical issues, I get to work on the actual game! I’ll repost the link and updates as I add to the project.

30 seconds vid of the space game (no sound, sorry), mixture of placeholder art and the nifty procedural cosmic background generator

It’s all very raw/early, but the movement is about how I imagined it. Visually, probably only the movement and background will live on. In a future iteration the ship is going to grow a pivoting cannon and some sort of animated engine+afterburner stuff. I’m also going to experiment with making multiple gaseous background and star layers, with some parallaxing.

Here’s the overall game idea: players engage in a ~20-45 minute (if they’re good) roguelike space-themed arcade game culminating in a boss fight. The game requires a group of players to beat, and probably quite a few deaths to even figure out how to play. Nearby players will be marked on the HUD, encouraging grouping.

The destruction of the player’s ship is permanent, but the player may respawn in a new level one ship indefinitely. There will be roughly ~10 exp levels to gain for the player’s ship, each increases the strength of the ship. If I’m feeling ambitious there will be a few types of ships. The early levels are best spent destroying asteroids (which is simply practical, given that they will destroy your ship). Middle levels are spent fighting hostile ships, and well, more asteroids.

The main boss lives in the center of each map. The map is procedurally generated w/ nifty space backgrounds, asteroids, and hopefully some hostile AI ships. Difficulty increases as players fly towards the center of the map, so it makes sense to gain a level or two periodically before travelling further inwards.

(maybe) The boss produces large asteroids which travel outwards from the center and periodically split into smaller asteroids. Each time the asteroids split, they’re reduced in size and gain a bit of a random direction. The very same asteroids that populate the newbie zone are in fact descendants of the asteroids spawned by the boss  (we’ll see if this is really feasible, I’ve only done a few small tests of this model). While asteroid movement may seem mostly random, players can deduce where the boss is by noting the general source direction of the majority of the asteroids.

I’ll try and put some sort of playable version up soon.  It’ll probably just be infinite lives + infinite asteroids initially. I’ve got a few server-crashing bugs to find first. I also have yet to make whatever types of lag compensation are appropriate for this type of game. I’m guessing it’ll be mostly similar to prior work, but there may be some complexity to do w/ how fast the ships are vs all the potential asteroid collisions. We’ll see.

woo developer art (testing pixi.js + netengine)

woo developer art (testing pixi.js + netengine)

procedurally generated outerspace background for a new game idea (I’m just gonna test out my net engine w/ an arcade-style space shooter)

procedurally generated outerspace background for a new game idea (I’m just gonna test out my net engine w/ an arcade-style space shooter)

NetEngine source code

I hit a reasonable stopping point as I rewrote the core of my game’s network code, so I bundled it up and put it on github. This was about as much as I could share without publishing a full engine or game (neither of which yet exist).

https://github.com/timetocode/net-engine-demo

To summarize, this NetEngine allows game entities to be defined and it will automagically handle the netcode itself. In a way it’s a prototyping aid for multiplayer game programming. It also demonstrates running the same code on client and server, as well as a mixin pattern for separating special pieces of code to run on only the server or client. This separation scenario is important for keeping some implementation secrets. The whole thing is a bit of a mess imo, but I’ve had several requests for code samples, so here, have an entire functional demo!!

In the demo, the player is a red circle and a black box attached to the mouse cursor. Move the cursor around to move the player. You’ll see other circles (NPCs) moving and bouncing around. The black square represents the view of your character — think of it as being an analogy for your entire screen which only sees a small section of a much larger map. The NPCs are living out their lives, and exist regardless of whether they can be seen or not. As the player moves around new NPCs will enter the player’s field of vision, and other NPCs will drop out. The NPCs also have some strange behavior: in addition to moving, they undulate in size, and have a 1% chance of changing color every game tick. The goal of the netcode is to track all of the above changes, which are divided into 3 main categories:

  1. a full update: player encounters an NPC and needs to know everything
  2. a partial update: an NPC already in view continues to move (or undulate, or change color) and the player needs to know only about these changes
  3. an subscribe: an NPC leaves the player’s view, and the player is told to forget about it

Multiple players can connect and will be able to see each other as well as all the NPCs.

see: http://timetocode.tumblr.com/post/93970694121/volcanic-map-generation-step-by-step for images and descriptions that closely follow the code

Volcanic Map Generation Step by Step

Here’s an illustrated summary of the volcanic island generation process. I’m going to move on to another step in development, and wanted to make a better record while its still fresh. These steps should also be helpful to anyone who wants to peruse the source code.

The end result will be this island:

image

Creating the overall land shape

Step 1: First we begin with a radial gradient:

Read More

The generator is done for now! Any impetus for future additions will come from the needs of the game itself.

Here’s all the biome + flora stuff put together and used to generate five different islands. The only change in the creation of one island or another was that they were passed a different number as a seed — and from that, each grew up a little different. The approximate total land area, circular nature of the island, and elevation change from sea level to the center of the island are all controlled to within a small range. The single most widely varying factor is the prevailing wind. The prevailing wind can come from any direction, and is followed by an allocation of rain via a crude rainshadow model, thus making one side of the island wet and the other dry.

I’ll clean up the code and post it somewhere with some notes in the near future.

Here’s a biome map with distinct colors for each biome. It may look like there’s a lot going on, but it follows a few simple rules.
The world has a temperature scale that goes from -1.0 to 1.0. I’m not super consistent with this scale, but in Earth measurements it might be roughly -15 to 55 Celsius or 0 to 130 Fahrenheit.
Going back to my scale, I treat greater than 0.25 as hot,  less than -0.25 as cold, and between 0.25 and -0.25 as temperate. Zero is right in the middle of my scale, and isn’t cold at all — it is temperate. Each of these three temperature regions (hot, temperate, and cold) is then divided into biomes depending on rain.  From driest to wettest the biomes are: desert, grassland, frontier grassland, forest, and rain forest. This gives me 15 biomes in the end, most of which have names like ‘temperate-grassland’ or ‘tropical-forest.’ A few get slightly cooler names like taiga and tundra.

Here’s a biome map with distinct colors for each biome. It may look like there’s a lot going on, but it follows a few simple rules.

The world has a temperature scale that goes from -1.0 to 1.0. I’m not super consistent with this scale, but in Earth measurements it might be roughly -15 to 55 Celsius or 0 to 130 Fahrenheit.

Going back to my scale, I treat greater than 0.25 as hot,  less than -0.25 as cold, and between 0.25 and -0.25 as temperate. Zero is right in the middle of my scale, and isn’t cold at all — it is temperate. Each of these three temperature regions (hot, temperate, and cold) is then divided into biomes depending on rain.  From driest to wettest the biomes are: desert, grassland, frontier grassland, forest, and rain forest. This gives me 15 biomes in the end, most of which have names like ‘temperate-grassland’ or ‘tropical-forest.’ A few get slightly cooler names like taiga and tundra.