Viridian Games

Guess what broke about a week ago. ‘Sright, my computer. All my attempts to resuscitate it have been met with failure. My attempts to commandeer my daughter’s computer this weekend were met with pleading and begging and tears (real, actual tears!)…so I decided not to do that.

Which left me with my laptop. Which, if you’ll recall is really just a netbook (a Gateway LT31, in fact). It’s got two gigs of RAM and a dedicated ATI Radeon X1270 graphics processor, unlike most netbooks which just use an Intel 950 Integrated Graphics Processor, which are cheap and work fine for web browsing but are nigh-unusable for games.

So I hooked my monitor, mouse, keyboard and speakers up to my laptop so I could at least compute in comfort.

Then I got out some games to see how well the rig would run them. The results:

Oblivion: Ran, but was unplayable even on the lowest graphical settings. This wasn’t a big surprise or disappointment. I knew I’d have to drop back a generation or two to get some results.

Morrowind: Ran fine; but I had to turn the graphics detail and the draw distance all the way down to get above 15 FPS outside. So it looks like Vvardenfell is constantly shrouded in fog. Interiors, on the other hand, run great – and dungeons are interiors so dungeon running is fine. Overall, playable.

World of Warcraft: Again, detail at the lowest settings. Large cities with lots of people like Dalaran are complete lag zones, but questing out in the wild greatly improves the frame rate. Overall, playable, if slightly annoying.

Deus Ex: The game defaults to 16-bit color mode, which I haven’t changed. Frame rate is good, if a little choppy in some places. Definitely playable.

Warcraft III: Perfectly playable on medium detail. I can even play on Battle.net and watch replays.

Starcraft: Perfectly playable. Again, playing on Battle.net and watching replays is no problem.

Half Life: Runs great, no changes needed.

System Shock 2: The big surprise of my experiments, this game runs perfectly without any need for tweaks (other than the minor ones necessary to get it running).

Fallout: Runs fine.

Tonight I’ll be trying Baldur’s Gate 2 and I might even be able to get away with Neverwinter Nights.

Oh, and Zeta development works fine, yadda yadda yadda.

During the 2004 run-up to the launch of the Playstation Portable, one of the promises made by Hirai & Co was that I would be able to carry around a playable copy of Final Fantasy VII at all times.

Now, five years later, that promise is finally kept.

So maybe now I’ll get one.

(Yes, I know, I could’ve already done it with homebrew, yadda yadda yadda.)

All right, here it is. Click here to download the beta.

Ya’ll be gentle with her, now. She’s sensitive.

Readme follows:

This is a work-in-progress demo of my game Planitia.

Current version is .73.

NOTE: IF YOU GET A MESSAGE SAYING THAT D3D9_**.DLL IS MISSING THEN YOU NEED TO UPDATE YOUR DIRECTX.

Planitia is a real-time strategy game that allows you to both build an army and use god powers to crush your enemies.

In this demo you play Green. In the main window you will see the game world, your general (the large guy with the green cape) and your village.

———————
BASIC CAMERA CONTROLS
———————

Planitia is meant to be played with one hand on the mouse and one hand on the WASD cluster on your keyboard. (Sorry left-handers – I’ll get controls in for you soon!) You use the mouse to interact with the interface. You can also move the camera by pushing the mouse to an edge of the screen, but it’s much easier to move the camera with the WASD cluster. You can rotate the camera using the Q and E keys. You can also click on the minimap to jump the camera to that location.

———-
GOD POWERS
———-

On the right side you will see a GUI display with a minimap. The blue bar below the minimap is your mana. Below that are buttons for the god powers. Only some of the god powers work now, inactive god powers have their buttons greyed out. The working god powers are:

Flatten Land (looks like up/down arrows): Costs 3 mana per second.

Allows you to raise or lower land to village height. Click and hold in the world window on any terrain to affect it. Flattening the land around your village will allow it to grow, and the more villagers you have the faster your mana will regenerate. Villages only grow at certain populations, so your village may not grow immediately even if you’ve flattened the land properly. Just be patient. You may also need to use this tool to create land bridges so that you can attack your enemy.

Earthquake (looks like concentric circles): Costs 25 mana.

Drops an earthquake wherever you click in the world window. Be careful not to cast it on your own village. The earthquake prevents enemy villages from growing and forces their gods to use more mana fixing what you’ve done.

Lightning Bolt (looks like…um…a lightning bolt): Costs 10 mana.

Casts a lightning bolt wherever you click. The lightning bolt damages units and throws them into the air. You can even knock them off the game world this way.

All god powers have a shared 1.5 second cooldown.

————–
MILITARY UNITS
————–

You can left-click on your general to select him and move him by right-clicking on the terrain. You cannot select your villagers.

If you click on the second tab on the GUI (looks like a red general) you will see the military buttons. You will see buttons for archers, barbarians and warriors, along with a display of how many you currently have of each.

Clicking the archer, barbarian or warrior buttons converts a villager into a military unit of that type and adds it to your army. Your army will always follow your general so you don’t have to worry about controlling units individually. You can attack enemy armies or villages simply by moving near them – once your units get within combat range they will attack automatically.

One thing to keep in mind is that once you convert a villager to a military unit it no longer gives you mana.

——-
OPTIONS
——-

If you click on the third tab on the GUI (which is currently blank) you’ll see the exit button. You can also exit the demo by pressing ESC.

If you wish to give me feedback on this demo, you can do so at anthony.salter@gmail.com, or comment on my blog at www.viridiangames.com.

Copyright 2006, 2007, 2008 by Anthony Salter. All rights reserved.

When I started working on Planitia full-bore again after the holidays were over I mentioned that I’m going to release a new beta by the end of January. I want this beta to have actual gameplay in it, and for that I need three things.

* I need to get the villages spawning new villages. They’ve been expanding for months, but once they hit the pop cap they are supposed to spawn another village nearby.

* I need to put combat back in. I ripped it out for debugging purposes – and I know it’s at least partially broken. That needs to be reactivated and debugged.

* I need to get more god powers implemented. Right now the only two that do exactly what they are supposed to are Flatten and Lightning Bolt.

I got the first two requirements done over the weekend and an amazing thing happened…

It’s a game now.

It’s got a definite beginning, requirements for success, and those requirements can be fulfilled – the game can even tell when you (or someone else) has won. The first time I crushed the AI player and had the game actually feed back to me that I’d won…well, that was a great moment for me personally.

So finally, fourteen months after I started this project (and eight months after it was supposed to have been finished), Planitia is a playable game! It’s not a very good game, but I wasn’t expecting it to be – this game is a perfect candidate for the iterative game design process.

And this means I still have two weeks to polish it up and add features before I post it. I’ve even started adding – GASP! – sound!

After a whole lot of work last weekend (and a lot of help from Ryan) I finally managed to get Planitia’s frame rate up and keep it up even when terrain morphing.

As much as I would have liked to put terrain.cpp to bed, I wanted to do two more things – make the terrain look less tiled, and make the water look more interesting.

So I did.

And I updated the demo so that anyone who wants to try it out can. Performance should be greatly improved, but there’s no new functionality (yet).

Now I need A* on the General. After that, no added features should really impact the frame rate. In theory.

I still feel I’m on track to have the first playable alpha version out by the end of August.

Okay. For your edification, I am going to post my current “Things To Do On Planitia” list. I’ve been maintaining this list since I started the project. According to SVN, I created this file on Monday, December 11, 2006, so I guess I can say that’s when I started working on Planitia.

Everything starred is done. Everything not starred is not done.

Tasks to be done on Planitia

*  Create a heightfield.  Texture it with our grass texture.

*  Create a camera object and implement our moving, rotating, zooming camera. Do
*  nothing else until this works.

*  We'll start with billboarded sprites as our objects.  Rip graphics from
*  another game.

*  Make it so units move smoothly across the landscape at any angle.

*  Create the walker unit.

*  Create the archer unit.

*  Create the fighter unit.

*  Create the barbarian (for now) unit.

*  Add combat stats to all units.

*  Fix the weird mipmapping on the units.

*  Add code to ensure that two units can never stop in the same grid square.

*  Fix problems with the picking input and box drawing.

*  Create the arrow unit.

*  Change the unit selection and orders to match a more traditional UI style.  In
*  other words, make it so that right-click gives orders.  Also change it so that
*  left clicking on a new unit dumps the current unit selection.

*  When you don't have a selection, left-clicking on the ground does nothing.
*  Left-clicking on a unit selects it.  Drawing a box with the left mouse button
*  selects all units in that box.

*  When you have a selection, left-clicking on the ground removes your selection.
*  Left-clicking on a unit removes your current selection and selects the unit.
*  Drawing a box with the left mouse button removes your current selection and selects
*  all units in that box.

*  When you don't have a selection, right-clicking on the ground does nothing.
*  Right-clicking on a unit does nothing.  Drawing a box with the right mouse
*  button does nothing.  (Boy, that was easy.)

*  When you have a selection, right-clicking on the ground moves all selected units
*  to that spot on the ground.

*  Right-clicking units not on the current team tells all selected units to attack
*  that unit.

*  Make sure that every time you delete a unit off the stack, you check the entire
*  list to see if anyone has a target to that unit and set them all to NULL.

*  Drawing a box with the right mouse button does nothing.

*  Jigger the numbers on unit creation so that attacks are staggered.

*  Add simple "find Quinn's ass and beat it" AI.

*  Create three teams of units and see what happens when the AI has them fight each other.

*  Moving the mouse to an edge of the screen should scroll the screen in that direction.

*  Get the hit point bars off the arrows.

*  Moving the mousewheel should zoom in/out.

*  Double-left-clicking a unit should dump any current selection and select all units
*  of that type.

*  Unit movement is time-dependent, which is correct, but camera movement is frame
*  dependent, which is wrong.  Fix it.

*  Have the zoom and the pan move faster the farther out you are.

*  Fix the box so that it works in any direction.

*  Add line to the help screen that tells people to exit the game by pressing ESC.

*  Make it so that you can pan, zoom and rotate all at the same time.

*  Add braking to all camera movement so that it doesn't feel so "hard".

Need pop states

NEED STORY STUFF NOW or we run the risk of Planitia having no story elements.

Need a dirt-simple text-based scripting system for story scenes.

*  MOVECAMERATO (location)  (time the move should take in MS)
*  ROTATECAMERATO (angle) (time the rotate should take in MS)
WAIT (time to wait in MS)
*  BARK (location) (text) (time to display in MS)
DROPUNIT (type) (unit) (position)
MOVEUNIT (unit) (position) (time the move should take in MS)
*  BOUNCEUNIT (unit) - Causes unit to "bounce" as if it jumped
TURNUNIT (unit) - Causes the unit to rotate 180 degrees

*  Need parts of a talk bubble that can be put together to form any size talk
*  bubble so that we can print text on it.  Based on script input.

NEED LEVEL INI FILE FORMAT NOW

It should include:

Targa file to use as heightfield data
Location of trees
Location of rocks
Initial location of buildings
Initial location of units
Initial location/rotation of camera
Level goal requirements
Script to run for intro
Script to run for outro

Need god powers.  Start with lightning/meteor as a test.
Need to flesh out design so we can figure out which ones we
want.  Reference Populous 1/2, Powermonger, Age of Mythology,
Black & White.

Need ten playable levels, plus intro outro scripts for each level.

Need skirmish against computer.

Need multiplayer, up to four people (can come after initial release).

Need 3D buildings, trees and rocks.

Want 3D units (may not be necessary but it would be very nice).

Fix terrain picking to use a real ray-plane test (sphere doesn't work that well).

Sort units back to front before rendering.

Do a cleanup pass; the code is getting kind of murky.

At this point it’s really feeling like every single thing I finish adds two more things to the list. But I’m hoping to have the game feature-complete by the end of March so that I can spend all of April creating content for it.

I’ve been thinking about Planitia lately. And every time I do, the theme music to Sacrifice starts playing in my head.

Sacrifice was a game released by Shiny back in 2000. It was notable for several things.

First off, it was gorgeous. See?

When I first saw screenshots of World of Warcraft my first thought was, “Wow, that almost looks as good as Sacrifice.”

Second, it had fantastic voice acting. Shiny was a company that understood that good voice acting is cheap compared to how much better it makes your game.

And finally, it was notable for being completely unplayable, which is why it failed in the marketplace.

Okay, I’m being slightly unfair with that last one. But Sacrifice had a thoroughly odd design; it was effectively a real-time strategy game and a third-person shooter game at the same time, with an interface that wasn’t suited for either genre. Imagine playing Warcraft III while having to look over the shoulder of your hero at all times and you’ll get a feeling for what playing Sacrifice was like. The clumsy interface combined with a rather steep difficulty curve (the last level is famously difficult) and you get a game that entices players in, but can’t keep them. I came damn close to buying Sacrifice based on the demo but was saved when a friend of mine picked it up, got frustrated with it and then let me borrow it. Which prevented me from buying it.

But the ideas behind Sacrifice were fascinating, and I certainly have never forgotten the game. Those ideas include:

* A world made of islands floating in an etherial void

* A bickering, petty pantheon of gods

* Very obvious display of the power of the gods – there are no atheists in the world of Sacrifice

* A set of standard unit types – scout, brawler, archer, flyer, etc – of which each god has their own unique type

If I were going to try to “fix” Sacrifice, I’d probably pull it back into a more normal real-time strategy mode. I might still have hero characters, but I certainly would not force players to control the game through that one character. Not sure yet if I’d require buildings and resource management, or if I’d keep the game simpler and more free-form.

This will require more thought, but at least I’m back to thinking about it.

Another update that doesn’t involve prettier screenshots. Sorry.

Of the Big List of Stuff To Do, I’ve managed to bang out the following:

• Saving
• Map links
• Combat
• Inventory
• Equipping of weapons and armor
• Using items
• Selling items
• Spells (except Smite)
• Levelling up

So, lots of difficult stuff sorted now. Here’s what’s left:

• Buying
• Loading
• Dying (death is currently non-fatal)
• Implement a fullscreen/windowed button (very low priority)
• Fix the Smite spell
• Fix getting objects (currently you can get anything anywhere on the screen)
• Put a “hit” marker on the player or NPCs when they get hit
• Use a “missile” marker to show bow or Smite attacks
• Make the two remaining town maps
• Make the eight dungeon maps
• Make the final boss castle map

And that should be it. I’m budgeting four hours to finish the infrastructure stuff – hopefully it will take less. And then the final five or so hours will be to create the actual maps of the game.

It’s getting really tight, but I already know that I’m going to ship something playable. It may not be fun or complete, but it’ll be playable, and that’s all that is required for me to consider this project a success.

Speaking of turn-based strategy, today I’d like to talk about combat-oriented turn-based strategy games, specifically games that use the action point (AP) system.

In these games, you control a small group of individual units (usually soldiers). Each unit is rated differently in various categories like weapon skill, speed, hitpoints, etc. The players (or the player and the computer) take turns, and on a player’s turn he gets to move all his pieces based on how much AP they have. Typically one AP will move a unit one square or hex on the map, so units with more AP will move across the map faster. They may also be able to make more attacks in combat because each attack typically costs a set amount of AP. Some examples of these games are the Jagged Alliance series of games, the Front Mission series, the Final Fantasy Tactics series, and the X-COM series.

So, where did the AP system come from? Who first invented it?

If you trace the roots of these games, they all come back to the same parent. Readers with a knowledge of game history are probably nodding and saying, “Yep – they all come back to X-COM!” But the roots go deeper than that. While X-COM was the first tactical combat game to be a big hit, it wasn’t the first, by a mile.

You see, several years before Julian Gallop designed X-COM, he designed a little game for the ZX Spectrum called Laser Squad. (Shall I mention yet again how much we missed out because the Spectrum didn’t go over well here in the States?) Anyone who plays Laser Squad will instantly recognize it as an X-COM prototype. So Julian invented the AP system, right?

Nope. Laser Squad was basically just a computerized version of one of Julian’s favorite board games – a game very few people have heard of, called Snapshot. Snapshot (and its sequel, Azhanti High Lightning) were actually boardgame supplements to the Traveller series of science fiction roleplaying games. They were designed to be broken out whenever the party of Traveller adventurers boarded some derelict alien spacecraft, so that any ensuing combat could be played out in boardgame fashion. Julian programmed it in and created some custom scenarios for it and created Laser Squad (and its sequel, Rebelstar). And in doing so he invented the computerized AP-based tactical combat game.

Well, now that I’ve expressed my appreciation and documented some of the history of these games, I’m going to talk about the two biggest problems these games have. The two problems are related, and both stem from the boardgame roots of these games.

The first problem is, what do you do with units that still have AP at the end of their turn?

The second problem is that having one side move all its units, then the other side move all its units brings up some very unrealistic results. In both Snapshot and Azhanti High Lightning, if you had a unit with enough AP he could step out from behind a corner, fire his weapon up to three times, and then retreat back behind the corner without any opponents being able to do anything. And guess what, you can sometimes do the same thing in Jagged Alliance 2.

Designers have fought these two problems in various ways. Fallout, for instance, kept the total number of AP you had to spend on a turn very low (ten was the highest, if I remember correctly), and then added the number of unused AP you had at the end of your turn to your armor class, thus making you harder to hit. This wasn’t bad, but in Fallout you only controlled one character. The same system wasn’t as effective when you used it for a whole group, as Fallout Tactics proved.

Both the Front Mission and the Jagged Alliance series fought this problem with interrupts or counterattacks, which were cases under which you could spend your units’ AP on your opponent’s turn. But in both cases, your units needed a lot of AP to be able to interrupt, and in the case of Jagged Alliance they also had to make a perception roll just to get the interrupt.

Most recently, Front Mission 4 tried a different tactic – allowing units to be linked together by the player. Therefore, if one unit attacks, all linked units with AP attack, and if one unit counterattacks, all linked units with AP join in the counterattack. It’s too confusing, and improperly linking your units will cause them to waste AP. But in the end it was just another attempt by designers to find a way to allow all units to use all their AP on every turn.

So what’s the solution?

Well, it doesn’t appear that there is “a” solution. One solution is to allow all units to move in the order of their speed scores. But this has the problem of the double reward – faster units move sooner and get to do more on their move. Okay, then couple it with interrupts…except that this has the effect of making combat feel very choppy; a character will barely get started doing their thing before somebody else gets to butt in. This is realistic, but may not be that playable.

What I’d like to try is creating a system where everyone moves simultaneously. When one of your units needs input, the game pauses, allowing you to give that input – but the input isn’t acted on until the game unpauses, at which point everybody starts moving again. Combat might not be broken up so badly because you could tell a unit, “Run over here to the other side of the map” and that unit won’t require any new orders until he gets there. You could also tell a unit, “Fire at this enemy using aimed headshots until he is dead” and that unit also won’t require additional orders until his situation changes. I’ll need to prototype this to see if I can get it to work.

Basically, although the boardgame roots of this series have served us well, it’s time to discard them and truly use the new medium of the computer to transcend the previous games in this genre.

Okay, purely for my own edification, I intend to write an RPG in 40 hours.

I was, of course, inspired by this blog post, and also by the fact that I really, really wanted to participate in the most recent Ludum Dare challenge, but couldn’t. So I’m sort of doing it on my own. Now you know why I was researching Roguelikes; 40 hours is too short to do just about anything graphical. Text mode will allow me to get the most out of my time.

Here’s the rules:

1. This will be a project created in Visual Studio .NET, using C++. It will be a console application, and it should run on both Win2K and Win9x.

2. The timer starts when I first create the project (which I haven’t yet).

3. Since I am a father of three and employed full-time, I can’t do something stupid like work on this for 40 hours straight. Instead, I will work on it whenever I have time, rigorously keeping track of my time. When the 40 hours is up, I will post whatever I’ve got, even if it’s not playable (though I will do my best to make sure that it is).

4. Time designing, coding and creating content counts against my 40 hours; time thinking about the project and writing blog entries about its progress do not. Thus, I can do some “mental preproduction” work on it as long as I don’t code anything or write any design down.

5. Failsafe. I have 40 hours to do this project, and I can spread them as thin as I want, but if the project is not done within 30 days (that is, it is not done by midnight, June 18th, 2005) the rest of my time is forfeited and I must post what I have.

Currently my thinking is that I will break the project up into two 20-hour chunks – one for coding the engine and one for creating content that runs on the engine. This should (note the word “should”) ensure that I ship something a bit more robust than just a hack & slash engine. My fears are that I will either overestimate the difficulty of the project and set my sights too low, resulting in a completed game so simplictic that no one wants to play it, or that I will conversely bite off far more than I can chew, resulting in no functioning game at all.

Oooh, this is going to be fun. I think.