J1M said: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.
J1M said: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.
J1M said: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.
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.soggie said: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.
J1M said: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?
J1M said: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.
wallace said: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.
wallace said: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.
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.soggie said:J1M said: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.
J1M said: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.
J1M said: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 said: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?
zenbitz said: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 said:[*] No trivial quests
Chateaubryan said:soggie said:[*] 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.
Great !soggie said:Hi guys, I'm halfway through pre-production of my own CRPG and had a TB combat system designed.
Ok.soggie said:I never played 3E before
Ok.soggie said:I haven't played JA2 or SS yet
Fantastic !soggie said:I've checked out ToEE's combat videos
You really love playing, don't you ? :Dsoggie said: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