Gad Games Update: Turn-based or Real-time?

[Gads]

If you are interested in reading our latest design thoughts and considerations for Ilkor then come over to our blog: http://gadgames.com/blog/2011/03/21/turn...real-time/

[Gads]

Here is my follow up to the article I posted the other week:
Combining Turn-based with Real-time, go check it out and let me know what you think! :-)

[Ramblurr]

Hi Sean,

This is an interesting model you're proposing. I was wondering if you could expand more on the differences between actions and orders. I'm having some trouble imagining many actions that won't run into the "actions will not give the player an adverse advantage should he issue them before another player" issue.

It seems either some players will simply have an advantage, or possible actions will be of little consequence and so conserving them or carefully spending them will be unnecessary.

Of course this is likely just a deficiency in my imagination, so please enlighten me

[JonO]

I ended up with pretty much the same concepts, Sean, though a couple of slight differences have evolved -- all designed to allow asynchronous play all of the time. I think you and I have come to the same conclusion: it makes great good sense to eliminate a queue of orders in which one fail has a domino effect and totally destroys the player's turn. Suspense can come just as easily from have a plan of action that will take a week to complete, even though the orders are given more frequently, as from filing a turn and waiting a week to find out what happened.

[GrimFinger]

Here is my follow up to the article I posted the other week:
Combining Turn-based with Real-time, go check it out and let me know what you think! :-)

I checked it out, Sean, as per your request.

My gut instinct yields mixed feelings on the matter. However, there's not enough details about the specifics of what falls under each category. i think that the goal is laudable. I do think that some real-time actions spawning off emails to players in the form of a notification is a superb idea. I never understood why Fall of Rome didn't, as an example to compare to what you're planning with Ilkor: Dark Rising, send players the text narrative of their battle results via e-mail. I think that what it boils down to is expanding our view of what it means for a game to interface with its players.

A game should interface with its players in a multitude of different ways. The interface equation, if I may phrase it that way, is not limited to just and only the GUI, itself. There are interfaces (GUIs), and then there is interfacing (from the player's, not the game moderator's perspective).

To interface with the player is to engage the player. If the player's not engaged, then true interface has not occurred. That's my view on it, anyway.

[JonO]

To interface with the player is to engage the player. If the player's not engaged, then true interface has not occurred. That's my view on it, anyway.

I doubt that any game designer/programmer has ever started off saying, "I want to bore the player." I imagine that every one of them has done their level best to create an engaging, exciting, and challenging game. Some of them have been involved in a big fail and some have succeeded beyond their wildest dreams, but the question a designer faces is not whether he wants to engage, but how to engage the player which involves game mechanics, user interface (even if it is a game board) and some level of story-telling.

[ixnay]

I think you are all on the right track. PBM needs to find a way to thrive in the emerging world of casual gaming, where players clock in for a few minutes during conference calls to check on their strawberry farms.

The synchronous "pulse" serves to keep major actions and initiatives on an even field for all players, and the asynchronous "actions" let players fine-tune and obsess over their position in the interim.

It's a good hybrid approach that could lead to the best of both worlds. I'm not familiar with GagGames or Rimworlds, but if either of them invites the player to contribute creative content, then keeping an asynchronous channel open makes complete sense. For instance, if a star captain discovers a new world, then you could let him log a narrative of this discovery or some related encounter, which could then be discovered or unlocked by other players.

[Gads]

Hi Sean,

This is an interesting model you're proposing. I was wondering if you could expand more on the differences between actions and orders. I'm having some trouble imagining many actions that won't run into the "actions will not give the player an adverse advantage should he issue them before another player" issue.

It seems either some players will simply have an advantage, or possible actions will be of little consequence and so conserving them or carefully spending them will be unnecessary.

Of course this is likely just a deficiency in my imagination, so please enlighten me

Hey Ramblurr,

I can't give too much away, otherwise by the time the game is ready there won't be anything to discover

I don't think our approach would work for every type of game, but we are hoping it will work for Ilkor. Our game is single character, open-ended and at the end of the day all about exploring, adventuring and collecting. It isn't really about trying to conquer or destroy another position, although I am sure player characters will almost certainly challenge each other in various different ways.

Ilkor also isn't going to be a typical RPG. It has a twist (we think so anyway) While there will be reasonable realistic aspects to it in terms of combat mechanics, movement; much of it will be abstract. A little like many board games. Ilkor will be a combination of a board game and RPG. A board game generally has a limited amount of options that a player can perform per turn. For example he may only be allowed to cast a spell, or move, or fight. So this approach is very structured and in some ways limited, which means the player needs to think carefully what he spends his actions on per turn. It isn't unlike alot of games I guess, but as far as a RPG it is (from my experience). Most RPG allow the player to buy as much as he can afford, sell all his possessions, walk about the settlement, visit the blacksmith, then the inn, back to the blacksmith, purchase a weapon, go to the market, try a spot of pickpocketing, etc.

Ilkor will have most of these features but the player will be limited to what he can do by the various constraints and structure we plan to put in place. A classic example of this is the Challenge Action. Here the player will only be allowed to issue say 3 challenges per turn. If he issues a challenge action on phase 1 on another player character and the result is unsuccessful, his challenges get reduced to 2. He can then choose to challenge again, but not the same character, at least not in the same phase. He could wait until the next phase to try again. Or he could attempt to challenge another character. If he tried again and this time was successful the player character would be notified of the challenge. He would also have only 1 challenge action left for the reminder of the turn. He would not be able to challenge anyone else until the next phase and no-one would be able to challenge him. Once a successful challenge has been setup between characters neither can challenge anyone else nor can anyone challenge them in the same phase. Remember the challenge action is real-time so you could say that players that issue the action early on in a phase has an advantage over those that don't, but I think it is minimal. The success of the challenge is based on a number of factors and if you are smart and want to avoid challenges you can put measures inplace (outside the scope of this post).

Once a challenge has been made both players are then free to 'prepare' themselves for the conflict. This involves a combination of performing a number of actions and then the combat orders. Each player is free to re-arrange their character's equipment, armour, weapons, buy and sell (if in a settlement), etc. They are pretty much able to perform any action just so long as it is within the general bounds (total actions allowed per turn and max instances of specific actions). This is obviously fairly abstract. In a typical RPG if a challenge was made combat would commence immediately and each character wouldn't have time to prepared. However this is the approach we have decided to take for the sake of gameplay and fun. The combat orders are also issued which will enable each player to decide on their combat tactics. Both the actions and orders can be issued at any time during the 48 hour duration of the phase. The outcome of the combat occurs at midnight on the night of the phase batch run and the results will be available the next morning.

The challenge action is a nice example as it is reasonable complex and has a number of knockon effects. I haven't gone into all the detail but hopefully enough for you guys to get the idea.

Other action types could be to do with things like research, buying, selling, healing, training, joining or leaving guilds, religions or parties. Maybe hunting, memorizing spells, accepting quests, etc. There really is ALOT of actions that I believe players can perform in real-time that will not give them an adverse advantage over other players should they issue them first.

Our two core orders will be combat and movement. We like the idea of processing these in a batch manner, giving everyone time to prepare themselves. The outcome of both types of orders can also be seen as fairly important and therefore adds to the anticipation.

I hope this gives you some insight into the mechanics that Ilkor will be adopting.

---

I think you are all on the right track. PBM needs to find a way to thrive in the emerging world of casual gaming, where players clock in for a few minutes during conference calls to check on their strawberry farms.

The synchronous "pulse" serves to keep major actions and initiatives on an even field for all players, and the asynchronous "actions" let players fine-tune and obsess over their position in the interim.

It's a good hybrid approach that could lead to the best of both worlds. I'm not familiar with GagGames or Rimworlds, but if either of them invites the player to contribute creative content, then keeping an asynchronous channel open makes complete sense. For instance, if a star captain discovers a new world, then you could let him log a narrative of this discovery or some related encounter, which could then be discovered or unlocked by other players.

Hi Ixnay,

Glad to hear you approve I guess we'll only really know for sure whether it'll work once Ilkor is up and running. I think it will however. I don't think it's a cop-out either by trying to evolve PBM. Some people might see this as a cop-out and it isn't PBM or true turn-based gaming or whatever. However at the end of the day it is all about offering a game that is fun and makes sense for it's choosen media. PBM has to change to live in the online world. While alot of us dislike many of the current Browser based games, we have to learn from them, they are successful and have many thousands of players. This in itself shows a level of success. If a game with 'some depth' was designed for the web why couldn't it also attract such interest?

Cheers

Sean.

---

Here is my follow up to the article I posted the other week:
Combining Turn-based with Real-time, go check it out and let me know what you think! :-)

I checked it out, Sean, as per your request.

My gut instinct yields mixed feelings on the matter. However, there's not enough details about the specifics of what falls under each category. i think that the goal is laudable. I do think that some real-time actions spawning off emails to players in the form of a notification is a superb idea. I never understood why Fall of Rome didn't, as an example to compare to what you're planning with Ilkor: Dark Rising, send players the text narrative of their battle results via e-mail. I think that what it boils down to is expanding our view of what it means for a game to interface with its players.

A game should interface with its players in a multitude of different ways. The interface equation, if I may phrase it that way, is not limited to just and only the GUI, itself. There are interfaces (GUIs), and then there is interfacing (from the player's, not the game moderator's perspective).

To interface with the player is to engage the player. If the player's not engaged, then true interface has not occurred. That's my view on it, anyway.

Hey Grimfinger,

Thanks for checking out our blog. I just wanted to mention another angle that Ilkor will be pushing which handles the way we intend to engage with the player. Our ideas aren't new, most if not all of them have been done before but we've taken ideas from different types of gaming (PBM, RPG, Computer Games, Video Games, Online Games, Board Games, etc) and tried to tackle the problem of developing a browser-based game that has its roots strongly in the PBM genre that will appeal to many different types of people out there while still retaining some degree of complexity.

Another idea that I'll be blogging about soon is the 'community driven' angle. Here we intend to get the community involved in the actual running of the game. Although it will be computer moderated, we'll have GameMasters that will moderate the game. These GMs will come from the community. Anyone can apply to become a GM and there will be a hierarchy and workflows inplace to prevent junior GMs from doing damage. As GMs prove themselves they will rise through the ranks and eventually will be in charge of an entire continent within the game world with a team of GMs beneath them. They will be responsible for helping the players with issues and questions, populating the lands with NPCs, items, monsters, quests, basically keeping the world alive. They will also expand the history, making the game richer with detail and content.

From the player side we also intend to have different types of players. Players that help beginners, players that contribute to newsletters, report cheating, etc.

We feel this human side to an automated system will go a long way to making the people involved in playing and GMing feel as if the game is theirs and it is more of a community rather than just a cold game system. I'm not sure if this makes sense but we hope this will be attractive to people, we want them to eventually 'own' the game and drive the direction in which it develops.

Cheers,

Sean.