Hexes and Squares, Oh My!

January 11th, 2011
In which I ask for feedback on some very fundamental game mechanics.

I need your help. So far, this little game project has been running on a square grid. This wasn’t an intentional decision; it was just an artifact of the tileset I had, to put it politely, “borrowed“. Now the time has come to move to my own assets, and before doing so I want to make that a more conscious decision. I have my own thoughts, but I don’t want my preconceived ideas to color the the essential question: What feels right?

So, squares or hexes? And while you’re trying it out, diagonal moves or not? Diagonal attacks or not? Please try out some of the possibilities and let me know in the comments what feels better to you. I really do value your feedback.

Grid type

The biggest choice is between the two grid types. They both evoke a certain kind of nostalgia. The square tiles are all about classic gaming, whether on the Apple II in the form of Ultima and Deathlord and others, or on the console in the form of Zelda. The hexes point towards tactical board games and tabletop gaming, which has its own warm memories attached. Hexes have been less-used in the computer gaming world (outside of Civilization V), which might be good or bad — fewer people have an attachment to them, but the uniqueness might be a draw.

A square grid is much more naturally suited to human architecture, at least as it’s practiced in our society. The hexes seem to give me much more organic looking terrain, because there are no grid lines that continue infinitely. But do I necessarily need to reproduce our world’s architecture and/or terrain?

I think hexes have an advantage for projecting tiles up into a pseudo-3D look. On a square grid, a door in a north-south wall can’t be seen unless you tilt the entire map 45 degrees, and I’ve always felt that just made the world feel askew. (Sorry, Fallout and Baldur’s Gate.) With hexes, as long as they’re aligned east-west rather than north-south, I can literally sidestep that problem.

Diagonal movement

For the diagonal movement, I’ve set it up so that you can move diagonally if both of the cells you could potentially walk through as intermediates are empty. If not, you’ll have to take two grid-aligned steps. Visually, that means that to move from the green cell to the red cell, both yellow cells must be empty:

Timing-wise, I’ve made diagonal moves take proportionally longer depending on the length (i.e. after such a move, your character can’t move again for a longer time). That’s 41% longer for the square grid and a whopping 73% longer for the hex grid. It seems a fair choice but it tweakable.

For the square grid, diagonals feel like a win all around. For the hexes it’s less clear-cut. Being able to move along 12 different directions definitely smooths out movement, and it makes up for the grid not supporting a true north/south axis. Try moving due north the length of the screen on the hex grid, with and without diagonals and you’ll see what a difference it makes. On the other hand, on the hexes it’s a very long distance. With diagonal hex moves, does it feel like monsters can “jump” into attack position from too far away?

Diagonal attacks

On the square grid, I also experimented with adding diagonal attacks. Do they feel right to you? Does the potential for being mobbed from eight directions at once (rather than just four) outweigh the benefit in flexibility? I’ve skipped left them off the hex grid because it felt too much like a reach attack (the “diagonals” don’t directly abut), but on the subject of getting mobbed from too many directions at once, are the six possible attack directions on the hex grid a balance issue for you, as opposed to the four or eight in the square grid?

Closing

I have my own answers to all of these questions, but they were the same answers I had before I wrote a single line of code, so I don’t completely trust that I’m letting go of my preconceptions and going with what plays right. Design is an iterative process, and nobody can iterate in a vacuum. So what plays right to you? Let me know below!

The Coming Hex

December 28th, 2010
In which a hex grid and art are revealed, problems are mooted, and a promise is made of interactive demos to come.

Just a minor update: I’ve been playing around on my Christmas vacation, and converted the game over to run on a hex grid. This meant actually making some of my own art! Please be kind to it…

First screenshot of the new hex tiles

I’m not completely convinced that hexes are the right way to go. Once I finish up some things, I’m going to put up a four-way comparison, squares versus hexes, with and without diagonal moves, and solicit the crowdsourced wisdom of the Internet on what feels better in actual play.

One unexpected holdup turned out to be pathfinding scalability. With a hex grid and diagonal movement, there are twelve possible moves from any tile, whereas axis-aligned moves on a square grid only allows four possibilities. When planning a series of moves, the search tree quickly can become very, very large. It’s nothing that can’t be fixed with a bit of memoization, though.

The planned-for holdup has been bringing the game server in-house — literally. After getting linked on Reddit, it became apparent that my cheap hosting plan wasn’t going to cut it. Rather than getting into the expensive plans, I’ve got a nice shiny fiber-optic line and an old laptop, and I’ll finally be running “real” .NET 4.0 instead of Mono. The webserver will continue to be hosted externally; only the AJAX game port will come move. The challenging part is that in my house, the old Fark.com cliche of “someone spilled beer on the servers” is going to be a very legitimate concern — not to mention the 1.2 kW Christmas tree tripping circuit breakers:

1.21 kilowatts of holiday cheer!

The Day Job

December 13th, 2010
Skyrim In which your author goes on the record about what else he’s been working on for the last year.

The Elder Scrolls V: Skyrim. Is. Finally. Announced!

In the 99% of my time that doesn’t go into this blog, this is what I’ve been working on for the last year. Specifically, I’ve been helping make this happen:

It's brand new... and it's spectacular!

The high point of the announcement was definitely the fan reaction. Over on the official Bethesda forums, there was an ongoing thread of people watching the Spike Video Game Awards. Eight pages into the thread, when we come out of nowhere with the announcement, everything immediately goes all “Double Todd Howard, all the way across the sky!“.

It was a thing of beauty, but it’s also humbling and overwhelming to realize you’re part of something so loved by so many people, especially when you had no hand in making the original. Must deliver on expectations…

Today, I Created Death

December 3rd, 2010
In which a peaceful world, lacking even the concept of “death”, is transformed into a brutish place of strife, suffering, and mortality — and we learn about changing the states of entities from functional code.

And now, some progress. I’ve added combat and killing and hit points and experience and all the other necessaries to the previous code. On reflection, I feel a bit of unease about this. In my last decade of professional work I’ve never had a blank sheet. There was always some body of code to begin with, a prequel to be sequelized or an engine with someone else’s game attached, and as part of that there came an existing concept of combat and conflict. Here was a world with none of those things. Not only could nobody die, but the very idea of “die” didn’t even exist within this tiny pocket universe. I changed that:

let CanAct c now =
    TimeUntilAct c now = TimeDelta.Zero && c.health > 0.0f<hp>

With that simple addition, it became possible for the inhabitants of this world to lose whatever abstracted vitality they might have possessed, and somehow things became fun. With something to lose, there was a challenge to overcome. Try it yourself:

Or better yet, try it with a friend. Point two web browsers at this page, and kill things together!

My main goal in all of this is to explore how functional programming can be used in a problem domain that’s traditionally very procedural — game development. I’ve found that without a game design driving things, it’s much too tempting to only solve the “easy” problems and hand-wave away the messy corners. By making an actual game, rather than little practice problems, I find I’m doing a great job of forcing myself to be honest about confronting the real challenges here… Read the rest of this entry »

It Lives!

November 3rd, 2010

In which paths are found, Mono 2.8 fixes a myriad of problems, and the server rediscovers its original threaded nature.

The rumors of the death of this project were greatly exaggerated. The rumors of that my server process was twitching in a corner, alternately chittering at itself about sockets and misplacing pieces of its own address space, however, were entirely well-founded. Mono 2.8, however, seems to have included the magic special sauce that makes everything right. And so, a long-delayed post of something I’d wanted to put up back in January:

What you have here are two different “players” running (via the server) in the same game world. In contrast to the earlier version where movement was one square at a time via keypress, now you can click in either window to move the central character to a destination. You’ll simultaneously see him move within his own view and across the other character’s view. They’ll find their way around obstacles, and even around each other while in motion. For fancier four-player action, try opening a second window with an extra copy of this post.

Performance of the server should be a lot better as the number of connections increases, too. Not only does the new Mono (when used with the new garbage collector) let me keep a .NET process alive under load on a Linux box for more than 4 hours, threading and Async blocks now work properly from within F# programs. My original code back in Windows land ran the game logic asynchronously from the networking, and handled each connection as a separate Async task within the networking layer. In fact, most of my interest in functional programming stemmed from the desire to do things like that much, much more easily. Now I can.

For a while that all had to be stripped out in the name of getting the original demo online at all, so it had been running in a single thread, accepting and handling and closing a single blocking socket at a time in alternation with updating the game world. Now that I can actually get the things I’ve been making onto a public server, there’s much more to come.

Getting Connected

January 25th, 2010

This looks very much like the earlier demos, but there’s one very important difference. It’s online! In the past, you were just playing with a graphic in your own browser window. I had some monster tiles placed in the world, but they were purely decorative. Now, your movements in the game world are sent back over the network, and you can see other people moving around as well.

(There’s a compatibility issue between this old build and the current version (2.8.1) of Mono, which wasn’t present under 2.8.0. You may not see anything below. I do want to keep old version online for archival purposes, so I’ll probably have this ironed out by next week.)

If you’re the only person on the website right now, you’ll only see yourself. But don’t worry, you can open another browser window by clicking here.

As before, to move around just click on the game area and then move around with the W/A/S/D keys or using the arrow keys. Each window has its own character, and when you move the character in one window you’ll see him move in all the others.

The server code is a custom HTTP server written entirely in F#. It’s running well below optimal because I’m still having some difficulties with threading and Mono that I didn’t see on Windows. For now I’ve turned it into an ugly single-threaded thing to get it online. Once I get that resolved I’ll post an article on how it actually works, rather than how it’s limping along for now.

And don’t forget to read about where I’m going with all of this.

A Design Sketch

January 24th, 2010

I’ve been having some issues getting my server code running on this hosted virtualized Linux system as opposed to my real Windows machines. In the meantime, I wanted to get down some notes on where I’m going with this project. Make sure you check out this quick demo to see what I’m talking about. Not everything is well-defined yet; a lot of the design is going to evolve over time.

Online non-MMO semi-RPG

This will be an online game with a shared world. I’m steering clear of the “MMO” term because it implies hundreds of thousands of people and multimillion-dollar budgets, neither of which are goals here. “Graphical MUD” might capture the scale better, but not the gameplay. It will be RPG-like in that there are characters and stats and advancement, but it’s meant to play more like a gigantic online board game and there’s no single “you”.

Retro Tile-Based World

This is a retro tile-based world. Designing a game world out of tiles is a lot quicker, easier, and cheaper than laying out the details of a continuous world. Too many of the game studios I’ve worked at required 3D construction skills to actually create an environment. This kept people with good design ideas from being able to quickly get something new into playable form. At best this meant it took a long time; at worst it meant going through an art team to test a gameplay tweak or bugfix. One person working alone should be able to place a character into the world, build out a place for her to live, give her some stats, activities, and enemies, write a first draft of dialog for her, and test the whole thing in-game…all in under an hour.

Just as importantly, it abstracts away the design of the gameplay elements of the world from its glossy presentation. Right now this is being done in a web browser. With the right procedural magic, the schematic-like tile designs could be turned into 3D environments of varying fidelity from iPhones to high-end PCs, while the actual world remained the same (and was even shared by people on different platforms). That’s pie-in-the-sky for now, but I’m already thinking in those terms even for the tiles — in the editor someone can work at the level of “this tile is water and this tile is land”. An automatic phase would turn that specification into “these are shoreline tiles #112 and #247″ without requiring (or even allowing) a designer to pick among hundreds of visually distinct but functionally identical tiles. At the editor level, the goal is to work only with the elements that are directly relevant to gameplay.

Tactical Combat on a Grid

Tactical combat on a grid will be a key part of gameplay. Tile-based worlds don’t necessarily require grid-based interactions; see early Zelda games for an example of continuous movement on a grid-based world. Here they’re intimately tied. I am explicitly trying to capture the feel of miniatures and boardgaming.

I’m playing in a particularly epic D&D campaign right now, filled with miniatures and scenery. It’s fun, and it’s sufficiently different from most big games that it could carve out a niche. The right balance for combat will be when you will lose if you have all your characters stand in a line and attack, but win when you successfully execute flanking maneuvers, use terrain and sight lines to your advantage, and keep enemies off your second line.

Line of sight and friendly fire will be key tactical considerations. When I play this out hypothetically on a chessboard, it adds a much more interesting dimension when you have to think about positioning characters so they don’t shoot each other in the back. My thinking on UI is that as you mouse over the board to select a target, numbers will appear over multiple characters to indicate the percentage chance of hitting each of them with a shot aimed at the mouse location.

Action in the game world will occur in real time. Every character has a pool of action points to spend. Every action, including taking a step, drains that pool by a certain cost. Everyone’s action pools are continuously regenerating.

One Party per Player

Players will control multiple characters simultaneously. There’s always a certain tension between player skill and character skill in anything with RPG elements. For me, gaining new skills is always a carrot, but I’m decreasingly enthused with MMOs where the only skill required of the player is mashing number keys in one of a few well-practiced sequences. Controlling in multiple characters at once creates a need for player skill in how you position and combine characters, but still allows a role for stats and dice rolls in determining the effectiveness of individual characters.

There’s some question as to how much you can bond with your characters if none of them are “you”. Hopefully I’ll be able to create the feel that they’re “pets” or “projects” that you’re proud of. You’ll have your own stable, essentially.

I suspect the right number of characters per player is between 3 and 5. Too few and you don’t have tactical considerations about where they are relative to each other; the decisions is always simply “get ‘em”. Too many and it turns into a mob when you play with other people. I’m thinking about have a sliding limit on characters-per-player depending on how many players are in a group — perhaps four characters if you enter an area by yourself, three each if there are two of you, and two each if there are three of you.

Dr. Livingstone vs Dracula!

The setting I’ve dreamed up for this is a sort of exaggerated mid-1800s Europe. Technology in the main cities is on par or slightly below our own of the era. (I’ve got no love for Steampunk trope of putting brass fittings on things more advanced than current-day, effectively turning tech into magic.) Communication is much, much worse. People in the cities know relatively little of the rural lands between them, and the people “out there” are sparse, unlearned, superstitious, and scared — for all sorts of good reasons.

The in-game equivalent of Romania isn’t just a backwater, it’s a place you go exploring on safari. Your characters are intrepid adventurers seeking fortune, glory, and the respect of the blokes back home at the club. This lends itself well to self-contained, episodic adventures, and creates a lot of room to progressively build new content into a living game world.

Firearms are the weapon of choice against targets far away, but not so effective that you’d prefer to shoot someone up close — for that you’d prefer steel or plain old fisticuffs. The balance between ranged and close attackers will be a key part of combat.

Magic of a sort exists in the world, but not as spells you learn about and cast consistently as if it were simply a predictable tool. Rumors abound of artifacts and fetishes, found by explorers such as yourself, which have caused the most strange happenings in a moment of utmost need. Strangely, many of them seem to turn to dust after use, and seldom does anything more than a great story make it back to the city. Those rare items of proven power and provenance are valuable beyond measure.

Help Wanted

I’m presently looking for an artist. Someone to help define the look of the world, and in the very immediate term help come up with a tileset that doesn’t scream Ultima. Getting that together is my top priority right now, because even if it’s just prototyping I dislike using art from another project. Needless to say this is an entirely non-commercial project, so you’d be doing it for love, gratitude, and the respect of dozens. Email me at ameggs@gmail.com if you’re feeling willing and creative. Otherwise, tell me how I suck in the comments…

Hello, world! (Literally)

January 19th, 2010

I’ve been doing a lot of work on AJAX and server and networking stuff recently. I haven’t quite gotten to the point of hosting that up on this server instead of my home machine, though. (In particular, there are still easily-exploitable security holes in the server. Since I intend to post source code, there’d be no hiding them.) However, since I’ve gone ahead and put this up in public, for obvious reasons my top priority is now to replace the Ultima map I was using as a placeholder with some copyright-free placeholder. And thus, the world of “Noisarria”:

A map of the tileset of Noisarria

Noisarria Rises!

And here’s an updated “game” using the new map so you can explore it at ground level. You start on the eastern-central section of the map. As before, click on the game window and then use W/A/S/D or arrow keys to move around:

Since I just needed to put something together in a hurry, and I don’t yet have anything resembling a proper map editor, the obvious answer was some quick fractal noise. (Get it? Noise? Noisarria? *ducks*) And of course, that meant F#. Functional languages are really useful for making functions that generate stuff, and the interactive mode is great for iteratively tuning the output. Read on for the code…

Read the rest of this entry »

In the Beginning…

January 18th, 2010

Over the last few years, I’ve become convinced that this whole web thing is probably the future. Outside the traditional game industry that’s probably not a controversial thing. When you’ve spent the last 20 years coding in C++ and then scrutinizing compiler’s output to get the most pixels or polygons or draw calls you can out of the bare metal, it’s a shift in thinking.

So, on my departure from EA Mythic a few months ago, I set out to learn some new skills. This isn’t a shift away from games; it’s an acknowledgment that the web has progressed to the point where you can do interesting interactive things on it. And so, grinding through the W3Schools tutorials, I put together my very first bit of Javascript code:

It’s a simple little program that lets you run around on the map from Ultima IV, the very first CRPG I ever fell in love with. To interact with the demo, just click on the map and then move around with W/A/S/D or the arrow keys. A few disclaimers:

  • The map was borrowed from the freely-downloadable copy of Ultima IV on the web so I didn’t have to spend time making a world map just to learn Javascript. I’m not out to remake Origin’s game when there are so many other games that still need someone to make their first version. :-)
  • The tileset was from a very nice Ultima fan site.
  • The monsters were purely decorative. This was really just to prove that you could scroll around some map tiles in Javascript and make this work. Any future “game logic” would happen server side using AJAX.

The fun thing about this is that it was 100% Javascript and HTML, no Flash or applets or plugins were involved. (I’d truly appreciate any feedback on my horrible first attempts at Javascript, by the way. Right-click, View Source, etc.) In the very short term, Flash would have probably been faster, especially on IE, but I’m a believer that open standards are going to win in the end — and be a better foundation for working on other platforms.

And now that I’m finally fully out of my EA contracts, where to now? There’s a particular game I’ve been wanting to make for years…