A long overdue update on my gaming project

[Margalis]

(Reminder: check out http://www.geocities.com/margalisix/ for news, screens, etc)

Tonight I hit a major milestone - All the stuff that was working before is working again in a client-server environment. It took me a long time to get this working because I was busy with other stuff (weekend visitors, job, etc) and because I really didn't know what I was doing. But I slogged my way through it. So I now have a server and a client, the server does all the work and the client basically displays stuff and takes keyboard input. Right now there is no security in that the server will just do what the client tells it without checking if it is legal but that is easy enough to put in place.

So the basic structure now is:
Client: "I'm moving the active unit to square X"
Server: "Go for it!"
Client: "Now I' m attacking unit 7"
Server: "Ok you do 11 damage"

Simple enough. Right now I only have one client that takes input for both players but it will be easy enough to support multiple clients. It's just easier to test with one window doing everything. I will probably spend a few days cleaning up stuff and documenting to get the code in a pretty stable and well-understood state.

As I do that I am going to do another run through of some design concepts. I have to think more carefully about some basic things like which stats units should have. For example, should units be able to dodge and miss? Should units have defense or just HP? Etc etc. I am trying to reduce the complexity because I need some good guidelines for unit costs and if I have HP, defense, attack power, agility and a bunch of other things it becomes really hard to come up with reasonable costing.

So instead what I want to do is create a baseline scale similar to M:TG. In Magic you have your typical Grizzly Bears forumula, 1G for a vanilla 2/2, and your 2/2 for 2R Gray Ogre. If you want that 1G to have a reasonable specail ability you have to make it GG or something like that. In Magic you have power, toughness, and then any keywords or special abilities.

My units will also have special abilities, attack power and HP, so I am trying to reduce to that. On one hand it seems silly, but I would rather start small and add back complexity that proves useful and fun rather than start with a mess. And I remind myself that Chess has no random die rolls, no stats or anything and is still fun.

As an excersize I'm going to create some equivalents of some typical Magic creatures to get a feel for what a baseline unit should be and also some basic rules of combat to go with them. For example if someone attacks you do you get a counter attack always, or only if you didn't attack on your turn, or never? That makes a huge difference when balancing units. Stuff like that.

So I will probably update my site in a few days with some more design type stuff.

Playable alpha when? I will probably have a version up where you can play against yourself relatively soon so people can mess around if they want.

[schild]

I look forward to it. :)

[Merusk]

My units will also have special abilities, attack power and HP, so I am trying to reduce to that. On one hand it seems silly, but I would rather start small and add back complexity that proves useful and fun rather than start with a mess. And I remind myself that Chess has no random die rolls, no stats or anything and is still fun.

Also remember that Stratego has an X always beats Y layout and is still loads of fun. (Part of that being remembering who's where and not being able to see units until you win/ lose a fight.)

I think you're going the right direction just reducing it to a power/ move/ HP/ Ability layout. You're developing a simple strat game, and the complexity should come in the mix of abilities and taking advantage of the terrains.  Things like Dodge/ Parry/ Counter/ etc should be your special abilities, not inherent to all units.  It will let you have a wider variety of units while keeping the base game pretty simple. 

Start adding-in too much to the units and you'll want to start creating a 'character budget' spreadsheet.  (Dodge costs x points, each hp costs y) Then I imagine your mind would wander to "well I've got this, why not let people create custom units and armies?) Things like that can be too easily abused, IMO. 

[Margalis]

Yeah, that is the problem I started running into. How much is 3 points of dodging worth, how valuable is 5 extra toughness, etc? There will be lots of special abilities so as you say that is differentiations enough.

There are a couple things I would like to have but they are easy to replicate. For example a Golem from Ogre Battle type creature that has high defense but low HP. I can always replicate that by giving it high HP but making it take double damage from "magic" type attacks. (Or something like that)

[koboshi]

  I have a suggestion but first I need to know better what you’re talking about when you’re discussing the character budget. Are you talking about trying to make every card relatively equal? And as such each character has a limited power budget. Or are you talking about the cost to a player to use a card? So that your problem is discerning what each card should cost.

[Margalis]

Each card will have a different cost. So it's ok for one creature to be twice as good as another, as long as they are costed that way.

[koboshi]

Ok then, here's my suggestion...

  Let the costs for each card be dynamically defined. Instead of hard coding the 'right' cost for the cards use an algorithm to determine at what value the players hold the cards. This could be accomplished by something as simple as when a player uses a card they add X hundredths of a percent to the cost of the card. The countering force would be something like a decay of cost, so that cost drops .01 percent more than the previous drop every x minutes/turns/games/days until the card is used again. (You could also use hard values too. exa: .1% of a point)

  Key points to making such a system work
  -The percentage amount each player adds to card cost must change according to the number of users, if you have ten users it will take forever for hundredths of a percentage to add up to any change in price.
  -The rate of decay of cost should err on the side of too quick to heal. Too slow and cards may get unjustly spiked and stay that way.
  -The system must start somewhere so you will still start with your ideal card costs.
  -Card costs shouldn’t be in percentages, just round the numbers off.

  Pros
  -Much less legwork for you. Players will decide the cost of cards so you don’t need nearly the same prerelease alpha testing. Think of M:TG, their ramp up time for each pack is huge. Unless you want to be alpha testing forever.
  -Once again I point to M:TG; Within the first two weeks of a new deck being released there is a fixed deck that is adopted by most players as it is the best one, Affinity, and Re-animator decks for example. Because in this system cards' costs aren't firm players can't depend on the same old lineup every game, unless it’s sufficiently original.

  Cons (or those changes that aren’t clearly pros)
  -Negative card costs are possible, if your code allows it. This means that players would be able to take on bad cards to mitigate the price of the most expensive cards.
  -Players will be required to learn how to deal with constantly changing their decks. Those who are good at only "best deck" strategies will not be happy.
  -Smaller player bases will allow for individual players to 'play the system' to manipulate prices.

[Roac]

Do you have your XML schema defined?  I saw your ninja xml doc, and wondered if you had all your nodes fleshed out as to what you want.  You mention a lot of special abilities, but "special" can mean "special code", which can be a serious pain in the ass, especially if you want more than a handful of specials. 

Of course, there's a few ways you can tackle that.  Special may mean ranged, first strike, etc - things you're already aware of that you want, just that you highly restrict how many cards get access to them.  Then you have special effects - say, an armageddon power, or aoe, etc.  What if you include an assassin - T:Destroy Target.  You may be able to reduce that to something easily coded in XML (a "tap" function, a "target" function, and a "deal damage[9999]" function), but you'll want to keep it that way. 

[Margalis]

Reply in two parts. First Kobishi:

There may be a happy medium here. One issue with your system is that it takes a while to stabilize. It may also be possible for people to game the system by playing tons of copies of cards to make the price go up on purpose. Or there may be cards that work well is specific decks but not many people *want* to play with them so they are always undercosted. I kind of wary of things that are totally automated like that because someone will spend time and effort trying to mess with it.

That said, I can collect stats on what cards are being used. One of the huge advantages to being solely digital is that I can issue corrections. (AKA nerfs!) Those can be changes to costs as well as changes to abilities or anything else. I already have a scheme in mind for issuing corrections. Old players can keep the old versions of cards forever but they can only play with them in "vintage" game types or for some set period of time before they are phased out. If your card is being modified you get to keep the old version or exchange it for the new one. (Or maybe just get issued the new one for free, something like that anyway) If you look at a card like Jitte in M:TG, if it was online only they could easily issue a correction to power it down a bit and make a bunch of people happy. (Only add 1 counter instead of 2, only add counters for player or creature damage not both, increase equip and casting cost to 3 each, etc)

So I can certainly track stats for things like which cards are popular and make some changes based on those. One thing I want to avoid is the Magic 10% of cards are good syndrome.

To Roac:

I don't have a schema right now. Just kind of making it up as I go along at this point. Basically I have classes and subclasses of actions that you can customize. Standard attack is an action, projectile attack is an action. Eventually there will be things like use rules and filters that you can apply to those actions. Like:

Attack does 4 damage.
Attack is filtered by [hits only in range X or less] filter
Attack is filtered by [hits only FLYING creatures] filter.
Attack is filtered by [hits only BLOCKING creatures] filter.
Attack produces effect [destroys creature]

So basically I need a bunch of different attacks, a bunch of different filter options, a bunch of different effects, costs, etc. I could auto-generate the text from those or just suck it up and type them in. I need to hard code all the individual bits but then they can be combined for full effects.

I have the basic framework for the filtering stuff, essentially a filter takes some map coordinates and returns valid positions. So I have filters for normal movement, flying, ranged attacks, etc.

Currently the names of things are actually Java class names and it uses reflection to sort of hook things up. Makes it harder on the eyes but easier to maintain and add stuff rather than going through some translation layer of names to class names. I may change my mind on that at some point though.

[Roac]

I would strongly urge you to work on your design as much as possible before going much farther with the code, otherwise you may find yourself doing a lot of backtracking or workarounds.  It's probable that you can't think of everything you might want to do, and that's ok; just make sure your design is flexible enough to account for as many of the "I don't know"s as possible.  For example, if you know you have a certain way you want to filter an attack, try to write your objects such that adding new filters isn't a major overhaul.  Just make sure that any object/information that a new filter might need is readily available, so that even if you can't fill in all our design or XML tree, you have a good idea of what else might be going in there.

[Alkiera]

I would strongly urge you to work on your design as much as possible before going much farther with the code, otherwise you may find yourself doing a lot of backtracking or workarounds.  It's probable that you can't think of everything you might want to do, and that's OK; just make sure your design is flexible enough to account for as many of the "I don't know"s as possible.  For example, if you know you have a certain way you want to filter an attack, try to write your objects such that adding new filters isn't a major overhaul.  Just make sure that any object/information that a new filter might need is readily available, so that even if you can't fill in all our design or XML tree, you have a good idea of what else might be going in there.

That way, by the time you're done, your code is full of lots of excess unused functions, data access routines, variables, and other random flotsam.  Sure, a compiler would optimise it out, except it's Java, it doesn't pay that much attention to which of your functions are called, after all, they might be called by some future project that would access this compiled form of the class.

You also end up making things more difficult than necessary, especially early on.  Planning out every possible way of handling every single object is great if you're writing a library for public consumption, but mostly useless mental masterbation otherwise.  Occam's Razor:  The most simple design that meets the requirements is the best.

Alkiera

[Roac]

That way, by the time you're done, your code is full of lots of excess unused functions, data access routines, variables, and other random flotsam.

If he'd work out design before code, it wouldn't be an issue.  He probably won't since it's for fun, therefore, keep options open.  Yeah, it won't be optimized for speed.  It'll be optimized so that he can add more fun to it when he feels like, without going around his ass to do it.  Needs to be flexible in the same sense public libraries are, and for the same reasons.

Besides, this is a 2p game using very basic graphics, not a high performance enterprise app.  Squeaking out a few calls in combat routines won't be noticeable without massive nested loops.

[Margalis]

Meh...let's not turn this into a discussion of the engineering. As an engineer I am quite capable. I will make things flexible enough without going overboard.

As far as performance is concerned actually drawing the screen is the biggest perf problem by far and there isn't much I can do to get around that.

[Pococurante]

As far as performance is concerned actually drawing the screen is the biggest perf problem by far and there isn't much I can do to get around that.

(! Java)

[Margalis]

It isn't *too* slow and my video card right now is a Voodoo 2 that was made before XP was even out so I'm not too worried. (Everything is slow on my home machine) Also I can always allow people to turn off AA and tranparencies. The game doesn't really require awesome animation or anything like that.

The perf problems I'm more concerned about are server side, but that shouldn't be too bad either.

Edit: About my development methodology. I do write out design things if I need to, and I usualy rapidly prototype stuff. I've ton a ton of programming in my life so I have a pretty good balance of not painting myself into a corner vs. making things so general they are hard to understand. I'm also not above spending time slogging through refactoring changes.

The one thing I will say is that I am glad I approached the network programming part when I did, because that is something I hadn't really done before and the original organization didn't lend itself well to that. It wasn't really a lot of recoding but it was a lot of reorganization.

[Pococurante]

Edit: About my development methodology. I do write out design things if I need to, and I usualy rapidly prototype stuff. I've ton a ton of programming in my life so I have a pretty good balance of not painting myself into a corner vs. making things so general they are hard to understand. I'm also not above spending time slogging through refactoring changes.

The one thing I will say is that I am glad I approached the network programming part when I did, because that is something I hadn't really done before and the original organization didn't lend itself well to that. It wasn't really a lot of recoding but it was a lot of reorganization.

If you have not already you might want to check out the net code for RunUO and Torque, the former is Java-like and the latter is pure C++/C script.

I'm at home now so I can fully agree with your first statement.  Jack of all trades enterprise architects are not allowed to say that out loud a small group of highly talented devs rarely need much more than four whiteboards (3 1/2 perma-inked DON'T ERASE) and the spiked nerfball to toss at the deserving co-worker of the moment.

[Sauced]

Since you are doing it in Java, you might also want to take a look at the Narya code from GameGardens.  It's fairly straight forward - if I were so inclined to tackle a project like yours I'd probably just start there.

[Margalis]

I am familiar with the basics of how Torque works at least.

My method is somewhat similar, I have the objects living on the server and thin representations of them on the client. Actually in some cases I have the object on the client in full but I don't bother keeping all of it up-to-date so you can't look at client memory and get useful info out of them. The client essentially sends out suggestions to the server and the server tells it what actually happened based on whether those things are legal.

Luckily I don't need anything complicated like selectively updating certain things depending on whether they are in range or field of view or any of that. Actual updates only come across a couple times a second if even that. Most likely once every couple of seconds.

I've looked at GameGardens before but I kind of forget what that was like.

[Sauced]

I've looked at GameGardens before but I kind of forget what that was like.

Well, "out-of-the-box" it supports a lot of things it sounds like you have implemented.  Client-server with chat and a basic lineup of /slash commands, a distributed object model, a sprite management library, that sort of thing. 

[Stephen Zepp]

I am familiar with the basics of how Torque works at least.

My method is somewhat similar, I have the objects living on the server and thin representations of them on the client. Actually in some cases I have the object on the client in full but I don't bother keeping all of it up-to-date so you can't look at client memory and get useful info out of them. The client essentially sends out suggestions to the server and the server tells it what actually happened based on whether those things are legal.

Luckily I don't need anything complicated like selectively updating certain things depending on whether they are in range or field of view or any of that. Actual updates only come across a couple times a second if even that. Most likely once every couple of seconds.

I've looked at GameGardens before but I kind of forget what that was like.

Keep in mind that the Torque Networking Model (you can see the open (limited to research) source project at Open TNL actually only sends as much info as it does for client side prediction--in that when a client inputs a move, it actually predicts on that client what will happen (and renders it) before the server even receives the move input from the player. Once the server does receive the move input, it applies it to the authoritative server side simulation, and then updates all the clients as to what -actually- happened (depending on scope, which you mentioned you are blowing off).

In other words, every client keeps a representative (non-authoritative) "copy" of the server simulation, and allows the client to manage the move side of things for their particular control object directly--but then interpolates as necessary back to what the authoritative server says actually happened.

If you (or anyone else for that matter!) have questions regarding the deeper aspects of TNL, feel free to ask here, in PM, or via email.

[Margalis]

Yup, dead reckoning and such. A system like that would be huge overkill for me and would not work very well.

In an FPS game when the server updates your position if you are a bit off it may mean you slide around a foot or so, no big deal. In my game all the actions are discrete. By that I mean if I choose to attack someone the next thing that happens is it switches to a battle screen. If the server then tells the client that it didn't really attack after all the battle screen would have to immediately be taken down, which would look like a graphics glitch.

That sort of stuff works in FPS games because the movement is continous and being off a bit is easily correctable and not really noticeable. In a discrete turn-based game if I render a unit in the wrong space then move it that would be very obvious. It just doesn't lend itself to interpolation.

Plus there really is no point. It's a turn-based game, even playing very fast you are only going to update a couple tmies a second and the updates are very small. What this means in practice is when you move next to someone and attack them you have to wait for one server round trip before the attack actually takes place. Not a big deal really.

[fnddf2]

As to including things like defense/armor and dodging/parrying, etc., it seems to me that these game mechanics would introduce an element of chance into your game.  Dodging, for instance, is done by the computer through random rolls on most games.

So, I guess my question is: do you want a game that has an element of chance, or is the outcome completely determined by the input of both players and fixed variables only?