My Take on Turn-Based Combat

[Khor1255]

I agree with all of that. Especially the 3d thing.

It is pretty, but usually more of a nuisance gameplay wise than anything that adds something of value.

 

[soggie]

Ok, here are my thoughts:
1) If you want to make a 3D world that's fine, but do not make the mistake of allowing the player to rotate the camera. Lock it in place or you will end up with all of the problems that games like NWN2 have with no additional benefit.

I'm sorry, I don't really understand this part. Could you elaborate on this? I personally thought the problem with NWN2 was the world itself, with the camera too badly coded to handle varying elevations and downright horrible handling in indoor scenes.

My idea of the camera is to have a minimum zoom distance, in which the player can only zoom in so much to that level (which is about the view of Fallout, where your character is never smaller than 1/6 of the screen's height). And since there are no tall buildings in the game, I think there's very little chance of the buildings screwing up the camera like it did in NWN2.

Or perhaps you were referring to something else? In any case, do elaborate, thanks!

2) You need to play some games like TOEE to actually see per-pixel turn-based combat before trying to decide the merit of it. Frankly, grid based is superior for a number of reasons; some of which have been already mentioned.

Got it. I'll write up a quick flash prototype as a proof of concept on combat.

3) This game is far too ambitious to do in 6 months with 3 people. Even if you buy all of the art. Even if you work 12 hours a day.

6 months is just for development period, on a very generous budget that we're gunning for. If we don't get funding, 6 months is impossible.

Pre-production for the game had already begun, so I'm anticipating a very straight forward process during the development stage. Of course, most probably you'll be proven right and I'll be proven wrong, so I'll only hold this estimate as the most optimistic estimate, and strive to hit that deadline.

At least in this kind of planning, we would be able to allocate enough buffer time to ensure that the project is over-funded to accommodate missing of deadlines.

 

[J1M]

I'm sorry, I don't really understand this part. Could you elaborate on this? I personally thought the problem with NWN2 was the world itself, with the camera too badly coded to handle varying elevations and downright horrible handling in indoor scenes.

If you allow the player to rotate the camera you have to make everything look good from every angle. It also confuses some players as to which way they are going, which way north is, and requires you to assume that you will code a camera that works well. That last one is not something to be underestimated. The staggeringly low percentage of games where people have no complaints about the camera needs to be taken into consideration.

So in exchange for a shit-ton of extra work you MAYBE create a camera that works well and allows players to rotate it. So what? How does that make your strategy/tactics RPG better than if it had a fixed isometric viewpoint?

Also, why would you go to the work of doing a flash prototype when you could just investigate a full fledged game that does what you are talking about? The problems with a per-pixel movement system do not require your special cover mechanic to make themselves apparent.

 

[gromit]

I think you can avoid a lot of the problems of a tiled system, since you don't want your game to be "about" the tiles (Shining Force II, III are good examples of "very tiled games") but don't discard the idea of having the game operate in such units anyway. Particularly for a 3d engine, where you can pull off some pretty cool tricks to clean it up, and still save yourself time, which seems to be the key here.

Of course using a grid doesn't mean your characters have to do the "hexagon wiggle," as you can just have the model run down a line or curve. All tile distances can easily be converted from "tile steps" and world units, into natural units for the player to see... if you want, you can even charge the player for movement along the smoothed path rather than the underlying tiles, but that could require "weird" movement costs, and from there higher AP precision. AP should never be an inflated currency, particularly when turns simulate a very short amount of time.

Dividing the world into deliberate units also makes "good" AI easier to produce. Nodal pathfinding, well written, is quite quick, both computationally and in production, and it's very, very reliable. Even if you want to simulate collision when shots are fired, the AI can appraise tactical movement in stark terms of "behind these bushes" or "just inside the door" with less worrying about what constitutes those places.

Ease of use, and making gameplay clear, are critical. Dummies who don't take cover deserve to be shot, not players who don't take a straight-edge and compass to their monitor, mis-click the cursor a few pixels south, or zig just too far to zag where they wanted to. Everything the player needs to know should be easily calculated by the player. Or at least estimable. It doesn't help there is a "sitting duck" feeling in turn-based combat.

Again, that doesn't mean you need to shove tiles into the player's face with tiled floors, odd movements, or grid overlays - the most you'll really need, if your levels are even slightly purpose-built, is some sign of the cursor's current snap point. Since we're thinking about shooters in a world, not pieces on a board, you can even shrink down the tile sizes (maybe standing is 1x1 tiles, prone is 1x3, etc,) and experiment with how your borders, terrain, and objects work for providing cover and mobility.

 

[soggie]

If you allow the player to rotate the camera you have to make everything look good from every angle. It also confuses some players as to which way they are going, which way north is, and requires you to assume that you will code a camera that works well. That last one is not something to be underestimated. The staggeringly low percentage of games where people have no complaints about the camera needs to be taken into consideration.

So in exchange for a shit-ton of extra work you MAYBE create a camera that works well and allows players to rotate it. So what? How does that make your strategy/tactics RPG better than if it had a fixed isometric viewpoint?

Then why do it in full 3D? If that's the case, I'd be better off with pre-rendered scenes planescape style. And truth to be told, that was the original plan before we decided on destructible environments.

I think it's easier right now to make it fully rotatable camera now and then fix it to an isometric view later in the game if things don't go well.

Also, why would you go to the work of doing a flash prototype when you could just investigate a full fledged game that does what you are talking about? The problems with a per-pixel movement system do not require your special cover mechanic to make themselves apparent.

A flash prototype is... a prototype. I've checked out ToEE's combat videos, and I think by playing ToEE alone won't give me a definite answer on the merits of a per-pixel approach. I think it's faster for me to prototype in flash using a top-down view to test out both the character system and combat system (including destructible walls) than to download ToEE, play through it and write up an analysis.

Besides, I can easily implement both hex-tiles and per-pixel in the same prototype with a simple on/off flag.

I think you can avoid a lot of the problems of a tiled system, since you don't want your game to be "about" the tiles (Shining Force II, III are good examples of "very tiled games") but don't discard the idea of having the game operate in such units anyway. Particularly for a 3d engine, where you can pull off some pretty cool tricks to clean it up, and still save yourself time, which seems to be the key here.

Noted.

Of course using a grid doesn't mean your characters have to do the "hexagon wiggle," as you can just have the model run down a line or curve. All tile distances can easily be converted from "tile steps" and world units, into natural units for the player to see... if you want, you can even charge the player for movement along the smoothed path rather than the underlying tiles, but that could require "weird" movement costs, and from there higher AP precision. AP should never be an inflated currency, particularly when turns simulate a very short amount of time.

Dividing the world into deliberate units also makes "good" AI easier to produce. Nodal pathfinding, well written, is quite quick, both computationally and in production, and it's very, very reliable. Even if you want to simulate collision when shots are fired, the AI can appraise tactical movement in stark terms of "behind these bushes" or "just inside the door" with less worrying about what constitutes those places.

Ease of use, and making gameplay clear, are critical. Dummies who don't take cover deserve to be shot, not players who don't take a straight-edge and compass to their monitor, mis-click the cursor a few pixels south, or zig just too far to zag where they wanted to. Everything the player needs to know should be easily calculated by the player. Or at least estimable. It doesn't help there is a "sitting duck" feeling in turn-based combat.

Again, that doesn't mean you need to shove tiles into the player's face with tiled floors, odd movements, or grid overlays - the most you'll really need, if your levels are even slightly purpose-built, is some sign of the cursor's current snap point. Since we're thinking about shooters in a world, not pieces on a board, you can even shrink down the tile sizes (maybe standing is 1x1 tiles, prone is 1x3, etc,) and experiment with how your borders, terrain, and objects work for providing cover and mobility.

Good point. On the AI, I mean. Then again, without a prototype we wouldn't know what approach is the best. I'll get one up real quick and try them out.

Thanks.

 

[J1M]

If you allow the player to rotate the camera you have to make everything look good from every angle. It also confuses some players as to which way they are going, which way north is, and requires you to assume that you will code a camera that works well. That last one is not something to be underestimated. The staggeringly low percentage of games where people have no complaints about the camera needs to be taken into consideration.

So in exchange for a shit-ton of extra work you MAYBE create a camera that works well and allows players to rotate it. So what? How does that make your strategy/tactics RPG better than if it had a fixed isometric viewpoint?

Then why do it in full 3D? If that's the case, I'd be better off with pre-rendered scenes planescape style. And truth to be told, that was the original plan before we decided on destructible environments.

I think it's easier right now to make it fully rotatable camera now and then fix it to an isometric view later in the game if things don't go well.

Also, why would you go to the work of doing a flash prototype when you could just investigate a full fledged game that does what you are talking about? The problems with a per-pixel movement system do not require your special cover mechanic to make themselves apparent.

A flash prototype is... a prototype. I've checked out ToEE's combat videos, and I think by playing ToEE alone won't give me a definite answer on the merits of a per-pixel approach. I think it's faster for me to prototype in flash using a top-down view to test out both the character system and combat system (including destructible walls) than to download ToEE, play through it and write up an analysis.

Besides, I can easily implement both hex-tiles and per-pixel in the same prototype with a simple on/off flag.

3D has advantages if you want to show equipment and weapon changes on characters. A scripted trigger is a scripted trigger. It makes no difference if it is attached to a 2D wall or a 3D one.

As for the rest of your comments, I sense that you think you know better than the rest of the game industry. And while that might be true for some companies, you seem to be lacking the breadth of experience required to even make that judgement. Nobody here is recommending things to you that are a waste of your time. They are offering you shortcuts so that you can learn from other people's mistakes without having to make them.

The flippant way you claim creating a 3D camera would be "easier" belies the naivety of a man who thinks he can accomplish what takes 3 years of a full development team with a couple of friends in 6 months. The time you have given yourself is barely enough to get an engine and a set of authoring tools working, let alone any real content for a game.

 

[Khor1255]

Well, I don't want to add insult here but there is really nothing wrong with 2d isometric. Plays easier and is most likely easier to code.
I have seen very few professionally rendered 3de games that look anywhere near as cool as 2d isometric. Detail always gets sacrificed and the whole thing ends up lacking any real soul. 2d games on the other hand are pictures coming to life. What could be better than that?

 

[soggie]

3D has advantages if you want to show equipment and weapon changes on characters. A scripted trigger is a scripted trigger. It makes no difference if it is attached to a 2D wall or a 3D one.

As for the rest of your comments, I sense that you think you know better than the rest of the game industry. And while that might be true for some companies, you seem to be lacking the breadth of experience required to even make that judgement. Nobody here is recommending things to you that are a waste of your time. They are offering you shortcuts so that you can learn from other people's mistakes without having to make them.

The flippant way you claim creating a 3D camera would be "easier" belies the naivety of a man who thinks he can accomplish what takes 3 years of a full development team with a couple of friends in 6 months. The time you have given yourself is barely enough to get an engine and a set of authoring tools working, let alone any real content for a game.

Sorry about that. Not that I think I'm better than the best minds out there in the game industry. I'm just thinking is there a best compromise between the two extremes.

I guess its just that I can't understand the reasoning behind those arguments yet, now that I'm still flipping around with lots of ideas on various fronts.

 

[soggie]

Well, I don't want to add insult here but there is really nothing wrong with 2d isometric. Plays easier and is most likely easier to code.
I have seen very few professionally rendered 3de games that look anywhere near as cool as 2d isometric. Detail always gets sacrificed and the whole thing ends up lacking any real soul. 2d games on the other hand are pictures coming to life. What could be better than that?

Well, I'll just keep this in mind for the moment. Truth to be told, there's still an ongoing debate in the team about going for pre-rendered scenes and 3d worlds.

I'm actually worried that 2d pre-rendered scenes would actually take more time to make than 3d levels.

 

[Khor1255]

Leveling in 2d is a little tricky. If you have multistoried buildings on your maps things behind them tend to get very obscured so a more clever way to make the multistoried building dissapear is a must here. But I have seen similar problems with 3d games. It is a difficult situation that requires careful handling.

 

[zenbitz]

Sounds cool. My guess is that (like others posted above) the pure pixel approach is not going to gain you much over a grid. Just use a small grid!

I also wonder if you could even dump the action points... in our game I have decided to leave them, figuring that it "collapses" to 1 AP = 1 action (with some "combo actions - like step 1 space and fire).

I am also not sure about "saving" AP up... although I think in our system I was doing something like "if you skip your turn, you can act whenever you want in the next one" (people with initiative can "delay"). For interrupt, I would do something like having characters set their "action" for the turn to "overwatch" and if a target appears they can interrupt. If they are not using the overwatch action, they cannot interrupt, and if they are overwatching, they cannot do anything else at the end (if no targets appear, they "lose" their turn).

I guess it would make sense to "abort" out of overwatch if someone throws a grenade at you.

The hard part will probably writing the AI.

 

[soggie]

Sounds cool. My guess is that (like others posted above) the pure pixel approach is not going to gain you much over a grid. Just use a small grid!

I also wonder if you could even dump the action points... in our game I have decided to leave them, figuring that it "collapses" to 1 AP = 1 action (with some "combo actions - like step 1 space and fire).

I am also not sure about "saving" AP up... although I think in our system I was doing something like "if you skip your turn, you can act whenever you want in the next one" (people with initiative can "delay"). For interrupt, I would do something like having characters set their "action" for the turn to "overwatch" and if a target appears they can interrupt. If they are not using the overwatch action, they cannot interrupt, and if they are overwatching, they cannot do anything else at the end (if no targets appear, they "lose" their turn).

I guess it would make sense to "abort" out of overwatch if someone throws a grenade at you.

The hard part will probably writing the AI.

About the overwatch, yes that's exactly what I meant when I mentioned "interrupt", in the sense that you can instruct a character to "aim" (overwatch) a certain area and if anybody comes into that "killzone" (overwatch zone) the character will open fire assuming if he/she has enough AP left.

Aborting an overwatch on a grenade won't be in the game I believe. This is because grenades don't explode immediately. The player can set them to several modes depending on the feats or skills that they have: airburst, 1 round delay, 1.5 round delay or 2 round delay. The idea is that grenades can be used tactically to flush out enemies from cover, thus the delay.

As for AP, I think we'll keep it because it's a pretty simple visual indicator of how many actions you can take per turn. Useful for the player and easy to understand, considering that our main target audience would be players of the original Fallouts.

I think right now the direction of the design is moving from per-pixel into grid-based. For two very good reasons mentioned by other participants of this thread: (1) easier AI programming and (2) better usability for the players.

 

[Chateaubryan]

[*] No trivial quests

Why not ? As long as they are well-designed, trivial quests can successfully introduce the player into the game world. Arcanum first sub-quest (with the liar monk, and the two burglars) set up the game's ending, for example.

Same as in Planescape : the quest to recover the contract from the dustmen introduces the player to the world and rules of Sigil.

 

[soggie]

[*] No trivial quests

Why not ? As long as they are well-designed, trivial quests can successfully introduce the player into the game world. Arcanum first sub-quest (with the liar monk, and the two burglars) set up the game's ending, for example.

Same as in Planescape : the quest to recover the contract from the dustmen introduces the player to the world and rules of Sigil.

I wouldn't count those as trivial. What I define as trivial are: generic fed-ex quests that have no bearing in the game world at all; "clean the warehouse of rats" quests that is just an excuse to initiate combat and get experience; and so forth.

Every quest in the game, even the side-quests, should have a place in the setting, and every action should at least play a part in changing the dynamics of the game world to a certain level.

There's actually a quest planned in the game where after a brothel closes down, you can actually "stalk" one of the hookers back to her house and there if you eavesdrop on the girl you can hear her sobbing. If you break into her house, you'll find a journal, and then find out that she is selling her body for a reason, and receive a quest like that.

That's just a side-quest, but it shows the kind of philosophy I wish to include in the game - quests that aren't received from vending machines called En-Pee-Cees, but encountered often in unsuspected ways. These are not even hard to script - you just need alternative "quest triggers".

 

[JarlFrank]

The game's gonna have trivial quests but you won't know that they're trivial. It's subtle.

But no really, I guess I'll leave out fedex quests altogether except if I can make them interesting (like the ones for Jongle Dunne in Arcanum). There won't be any "Bring this letter to my daughter living 2 blocks away because I'm too lzay to do it myself" shit.

 

[keithburgun]

Don't let me rotate the camera unless there is a direct NEED to do this. Make it mostly top down/iso and fixed.

 

[DickieBear]

So, um...Is there any news on this?

 

[racofer]

We are waiting for our turn to reply.

 

[soggie]

None yet, sorry. Sorting out icky funding problems currently.

 

[GarfunkeL]

JA2 combat with Fallout world and Arcanum quests? Where can I send money?

 

[Lonely Vazdru]

Hi guys, I'm halfway through pre-production of my own CRPG and had a TB combat system designed.

Great !

I never played 3E before

Ok.

I haven't played JA2 or SS yet

Ok.

I've checked out ToEE's combat videos

Fantastic !

and I think by playing ToEE alone won't give me a definite answer on the merits of a per-pixel approach. I think it's faster for me to prototype in flash

You really love playing, don't you ? :D