Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Vapourware Codexian Game Development Thread

Self-Ejected

Davaris

Self-Ejected
Developer
Joined
Mar 7, 2005
Messages
6,547
Location
Idiocracy
Did you know? Turn-based combat is harder to code than realtime and RTwP combat.

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.
 

shihonage

Subscribe to my OnlyFans
Patron
Joined
Jan 10, 2008
Messages
7,157
Location
location, location
Bubbles In Memoria
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.

I agree with your data, just not your conclusion.

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.

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.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,616
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.
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
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.


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

shihonage

Subscribe to my OnlyFans
Patron
Joined
Jan 10, 2008
Messages
7,157
Location
location, location
Bubbles In Memoria
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.
 

baturinsky

Arcane
Joined
Apr 21, 2013
Messages
5,526
Location
Russia
What is actually harder? I would think that TB is already structured naturally - so it's easier to convert to code. While real-time requires...well real-time, simultaneous actions. If you make it "real" time, of course, and not just TB with continuously flowing turns

A typical game loop is naturally predisposed to moving multiple actors simultaneously. That is the default state, and straying away from that toward turn-based actually imposes a buttload of new code. You need a separate arbiter to enumerate and handle combat participants, keep track of action points, sort turns by initiative, and more.

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.
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
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).
 

shihonage

Subscribe to my OnlyFans
Patron
Joined
Jan 10, 2008
Messages
7,157
Location
location, location
Bubbles In Memoria
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.
 

baturinsky

Arcane
Joined
Apr 21, 2013
Messages
5,526
Location
Russia
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.
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
Initiative doesn't simulate attack speed, it simulates reaction time. Action points simulate attack speed.

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.

Leftover AP can be usually usefully spent on movement.

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.

Also, you're generally splitting hairs with no point in sight.


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.
 

28.8bps Modem

Prophet
Joined
Jan 15, 2014
Messages
302
Location
The Internet, Circa 1993
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.
 

shihonage

Subscribe to my OnlyFans
Patron
Joined
Jan 10, 2008
Messages
7,157
Location
location, location
Bubbles In Memoria
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.

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

"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.
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
"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!"

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.
 

DosBuster

Arcane
Patron
The Real Fanboy
Joined
Aug 28, 2013
Messages
1,861
Location
God's Dumpster
Codex USB, 2014
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?
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
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.
 

Mastermind

Cognito Elite Material
Patron
Bethestard
Joined
Apr 15, 2010
Messages
21,144
Steve gets a Kidney but I don't even get a tag.
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:

yHV93Zm.png

gqzLgwX.png

8VJXrMC.png

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.
 

CryptRat

Arcane
Developer
Joined
Sep 10, 2014
Messages
3,548
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).
:badnews:
I am already dead.

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

DosBuster

Arcane
Patron
The Real Fanboy
Joined
Aug 28, 2013
Messages
1,861
Location
God's Dumpster
Codex USB, 2014
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..
 

Destroid

Arcane
Joined
May 9, 2007
Messages
16,628
Location
Australia
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).
:badnews:
I am already dead.

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

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.
 

CryptRat

Arcane
Developer
Joined
Sep 10, 2014
Messages
3,548
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).
:badnews:
I am already dead.

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

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.


Thank you. I will need to consider these different options.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom