A game called DayZ has been getting a lot of attention lately, and I hope to be able to try it out soon. FPS play can be very exciting and immersive, but I still find myself coming back to turn-based games like TBSes and roguelikes in the end. Turn-based games in multiplayer run into a lot of issues though, just try playing multiplayer Civilization some time. You either have some awkward simultaneous play mode, or have to slog through a play-by-email game that takes months. Ultimately, you're always stuck waiting for another player, and that's not particularly fun.
The other day, I came across a great writeup by
Thomas Brox Røst on how to set up persistent storage for a Django environment with Amazon's EC2. It's an excellent and informative article, but I preferred to set up my environment with a number of differences, such as Ubuntu and MySQL instead of Fedora and PostgreSQL, as well as an apache2/mod_wsgi environment. The instructions are very similar, and I mostly recorded them for the sake of personal repetition, but I figured I'd share them in case anyone else finds them useful.
I've lately been paying a lot of attention to the cloud computing offerings from Google and Amazon, but the more you learn about them the more it seems like you really have to program for them. My dilemma is that I've developed a mostly complete application that I'd like to explore migrating into one of these solutions.
Running the ticket sales system for Playa del Fuego has presented some peculiar challenges I don't face in most products. Primarily, there's the issue of dealing with a thousand or more simultaneous users during opening sales but very little traffic over the rest of the year.
I just came across Cleverbot the other day, and found it pretty intriguing. When I got my first PC (an IBM AT 80286), a friend gave me a floppy with a little program on it called Eliza.
I was just looking at Board Game Geek, and got a vague idea for a persistent CCG that could be played as a browser MMO. You'd control a city in which you can place structure cards. These cards will generate resources every turn. Every day, you'll draw a new hand of cards, that can be placed using these resources. Some of these cards will be additional buildings (which can also have their own effects), and others will be unit cards, representing your military.
Just thought I'd share the final functions I settled on for isometric coordinate calculations. Unlike most of the others I've seen around the web, these account for:
* Origin offset
* Tile-based position offset
* Varied scale
* Any aspect ratio (not just 2:1)
An idea for a civ-like game has been banging around in my head for a while, and I wanted to put some ideas down. The layered node structure I've been working on gave me the idea, as I thought it would apply very well to a game that takes place on multiple levels of scale.
I've found that in more complex 2D games, I end up maintaining several "boards" containing 2D arrays of objects. Generally I have a base board to hold the floor, a terrain board for walls and other structural objects, a feature or object board for smaller items, and an actor board. The feature and actor boards are generally kept in parallel with flat feature and actors arrays, as a convenience to either access them with an iteration or by board position.
While ZedZed required only simple directional pathfinding (zombies are stupid, so advanced pathfinding is not needed), Demon Keeper required some more advanced techniques to facilitate targeting.