Vapourware Codexian Game Development Thread

But by doing this, you can introduce more complex interactions, because at any given point you only care about a small portion of gameplay - in real time it would be a bit harder think. Harder to implement, debug, balance etc. With TB you kind of divide and conquer complexity. It's still complex, but more structured, manageable. Depends of course, on features.

 

To me there is no difference between RTwP and RT, because with RTwP all you have to do is stop/start the updates and you're done. And TB code can be a tangly mess if you are inexperienced, but path finding is a lot easier in grid based games.

If you're using a good commercial 3D engine, RT is not something you have to worry about though, as that's what they design them for.

 

I agree with your data, just not your conclusion.

You're approaching more of the idea why TB combat is inherently superior, with which I agree. It's not that RTwP combat is harder to balance (that's why we have DPS and shit), or harder to have "features" in, but it's inherently less strategic. Stats like "initiative" essentially become meaningless, because there's still too much player dependency in there as opposed to character dependency. Everything from RT and RTwP combat can be put into TB combat, plus more, but not the other way around.

 

RTwP is impossible to balance unless you restrict pausing to a certain interval. At that point it becomes turn-based because the cheat code has been removed.

 

Nope, you can't implement attack speed differences properly in turn based games.

 

Attack speed = How many actions you can perform within a set timeslice = Action points

Slow lumbering character in TB would have fewer action points, thus walk lesser distance, fire less shots, not be able to heal in time, etc.

 

RT is not simulatneous action. It's just very short actions. Move 1/60 seconds worth of distance, add 1/600 seconds to timeout to your next shot, etc. So, it's not really that big difference with TB.

 

Action points don't work any better than an x actions/turn system in representing smaller attack speed differences. You can also end up with leftover AP even though you might want to do nothing but attack with them.

Conversely, initiative doesn't work well in RT because attack speed (and speed is what initiative tries to simulate) already does the job in determining action order (IE: it's redundant). In other words, real time is very good at simulating even the smallest differences in action speed since its only barrier is frame rate, whereas TB has to make sacrifices (IE: global increase in actions/turn).

 

Initiative doesn't simulate attack speed, it simulates reaction time. Action points simulate attack speed. Leftover AP can be usually usefully spent on movement. Also, you're generally splitting hairs with no point in sight.

As for you, baturinsky , RT combat doesn't move one actor per frame. You need to start thinking about things before you say them.

 

I never said anything like this. In RT EACH actor does his mini-move each frame.

 

You obviously ran into a language barrier here.

 

Reaction time IS a part of attack speed. You need AP and initiative to roughly attack speed because you can't do it properly in TB.

The point was that in RT you can attack continuously. Not so with AP, where you would need to patch things over. It's also hard to simulate small differences in attack speed.

Nope. Attack speed can factor in quite a few decisions, both on the design and the player side, thus providing tactical options you may not be able to get in TB. Your original claim that you can do things in TB that you can't in RTwP is also suspect. TB is just an abstraction of real time (which is how the real world functions), so that's impossible.

 

He's right, the computer still needs to perform actions in a specific order, even if it happens in the same frame.

 

This is kind of a weird conversation to me, since the way I've implemented it both the real time walking around the map not in combat, and the turn based combat mode are the same code, the only difference is how the scripting thread updates the map data.

The basic loop is:

1. The scripting VM thread gets an exclusive write lock on the map data global.
2. The VM pops the item from the end of every actor's plan queue and places it in the immediate plan slot for every actor.
3. The VM releases its lock on the data and signals the main thread a plan update is available.
4. The main thread gets a read lock on the map data and for each actor on the map updates their animation pointer for the next set of animation ticks.
5. The VM happily carries on adding to plan queues as appropriate.
6. The main thread happily carries on executing its animation list. When it's done with the current set of animation pointers, it switches to the new and signals the VM it's ready for another update. Repeat.

If the main thread has an underflow problem, it switches all the actors to their idle animations and puts the "waiting" spinner cursor up. This is kind of a problem in real time mode, but frankly there'd have to be an extraordinary series of things going wrong for it to underflow. Mostly the plan queues are full. The underflow behaviour is mainly the default fallback for turn based mode for actors whose turn isn't up yet.

In turn based mode, the only difference is that most actors' plan queues are usually empty. Only the actor whose turn it is gets to make a plan and have it executed.

 

28.8bps Modem You have glided over a number of things that become necessary to take care of in turn-based combat. In choosing not to write a separate TB combat arbiter, you have been, or will be, forced to thinly spread its functionality along your "normal" code. So the arbiter will exist in one form or another, and it is, in any form it takes, an additional management layer on top of realtime code.

"Hey guys, we have a loop in the engine, therefore turn-based combat is easier to code than RT! Because everyone in the loop has a turn!"

This "big picture theorizing" is useless when it comes to practical implementation. Primitive concepts don't scale up so elegantly, which is why you have habitual programmers start on grand projects that get quickly abandoned. Because they estimated how it will work based on their previous small projects. There's astronomically more work in there than there seems to be when you look from a fuzzy distance of future dreams.

On this level you can also "theorize" that C&C is nothing but a series of easy IF-THEN statements, dialogue parsing is just reading choices from a text file, and handling animation states is just incrementing frames. It's all very reassuring, convenient, and wrong.

 

Relax bro, I never said TB is easier to code, I just said RT actions are performed sequentially rather than simultaneously. I made a small codex roguelike a while ago and know how much of a pain it is, even in gamemaker.

 

Hmm.. I'm considering going with FOnline's engine for a Commercial project I'm working on with some friends. Only problem is, the svn is down. Anyone here got some backups of the latest version? Also, where can I find some good documentation?

 

Got the jumping augmentation working. Character can now hop around, knocking back enemies on landing and damaging them. I'll probably add an energy cost to it, will see when all the systems are in and I can actually do some balance testing. I "dumbed down" the augmentation system (which took place of basic stat progression) because... it wasn't really that much stat progression. Most structural augmentations now boost resources (energy, shields, armor) and in some cases basic stats like movement speed. I'll still leave some small aug slots for stuff like enemy radar. The previous system interfered with the "skill system" too much, and I had two passive systems going that had too much cross-over and only a thematic difference.

 

I've been putting off implementing this weapon for a while, because I thought for sure it would be a fucking pain. Nope, went smooth as fuck, especially compared to all the $#@$ beam weapons. It's a charge-up weapon. Hold the button to suck up energy, release it to fire a wide beam that damages anything based on the energy used:

Show Spoiler Hide Spoiler

A bunch of weapons still need upgrades. Fuck, I don't even have a basic design for some of their upgrades, and I still need to come up with another handgun. But I'm happy they're almost out of the way and the worst has passed. I also implemented artifacts, which change appearance and give you additional bonuses.

 

First, I am sorry if you already talked about that and i didn't find the thread.

I am currently developping some isometric turn-based combat-based game and I have got a few questions :

1- Do you restrain mechanics because the ai is unable to consider them?
A precise example : I use a scoring system to determine what the computer does.
I implemented one turn for each player rather than one turn for each unit because i really prefer it that way.
I added some auras, and some reaction skills a la Front Mission 5 (which means that the position of allies is important when a unit plays).

I am already dead.

2- What reading do you use to develop the ai for that kind of game?

 

Finally, I have managed to assemble a basic team to help start work on an interesting game that I've wanted to make for a while! I will say, the future does look terrifying..

 

There's nothing to fear, except, of course, all the upcoming horrible terrors.

 

You mean his game or the news?

 

It really depends what you want from your AI. If you want to simulate a human opponent, then you need to be able to write an AI that can take advantage of your mechanics. On the other hand, if you don't need or desire that kind of symmetry you can make the AI play by considerably different rules from the player, or simply provide them with more units or other advantages to balance the fact that they don't take advantage of certain mechanics present in the game.

 

wat news