Call for an Erfworld Video Game

[zeekgenateer]

I am not all concerned with 3d. Fire Emblem which is one of my favorite games is 2d, and FFT is pretty much 2d with layers. I like the hex map overview better, but once again, I can only code in java, so...

[Drunut]

Yeah I mean Kind of like that, but not the HOMM3 battle system (that would be too large) I meant the HOMM3 World system. Like how movement points are used, and unit management.

Put aside your hate for HOMM4 and think like that game. You could send out creatures with "heroes" (IE leadership) or you could send them out as just monster stacks (IE stacks) with the strongest unit leading. It is actually very similar.

And I would dabble with the top down. I guess it would all matter on how the coding works.

[privatepepper]

Here's an idea for a completely different approach to it:

Design an MMORPG, where players control individual units, be they Pikers, Warlords, or Casters- we could have an opportunity to make a 3D game, and it would be much more social. It would also give us a way to have units that are ultimately autonomous, rather than directly controlled by the chief warlord or overlord.

For an idea of what I mean, first play Command & Conquer: Tiberian Sun [a realtime strategy game by Westwood] and then play the first-person version: Command & Conquer: Renegade.

-Otherwise, I think that online play should act like this: players can be the Chief Warlord / Overlord [both can control troops, overlord sets production orders for cities and appoints warlords], other Warlords or Casters leading their own stacks, or individual units leading leaderless stacks. That is, one "side" could have six human players with a chain of command [in case one logs out], allowing some level of autonomy to infantry stacks and other units. I think that this type of approach is important because units are _not_ 100% loyal by default. Wanda, for example, was not entirely obedient to Faq OR Gobwin Knob.

-If this is difficult or impossible, Barbarian mercenaries should be much more common- each player starts as a Barbarian and must found/conquer a city, do mercenary work, or obtain resources in other ways to support troops.

[privatepepper]

...Stop-Motion! Here's a thing I'm working on (yes a frame is missing), so that this idea isn't just thrown in a vacuum...

That's nice.

However, I think it would be both cheaper and more effective to create the same style of graphics in Blender if we choose to use them- and I think they should mostly be used for a cinematic intro/outro to the game.

[Drunut]

That is an interesting take on a game Pepper, but how would that work with an AI? Would this whole chain of command deal be purely an optional gamemode? I really like the idea but I can't see how it would be easily executed. In fact I LOVE the idea. It adds depth to the game. Only that would bring up LAN and Online issues, balancing it so that one player was not more powerful than another (too much) and creating seperate LOaD systems for every creature. (So if you have a creature in your command all the time it's loyalty to you goes up as oppoesed to the other leadership.)

It's actually pretty daunting.

[zeekgenateer]

First things first lets hammer out the base logic and mechanics. Then single player, then multiplayer. We can discuss gametypes on the way, but I was hoping for TBS with single/multi support

[privatepepper]

First things first lets hammer out the base logic and mechanics. Then single player, then multiplayer. We can discuss gametypes on the way, but I was hoping for TBS with single/multi support

Actually, developing multiplayer-over-LAN would probably come _before_ single player- set up the system, then make a system for AI to control player 2

[depricated]

as far as system goes...

I think it would be interesting to set up an SQL server to keep track of unique players. They can then have "Canon" and "non-Canon" battles.

Follow: each player is a Warlord. They pick their stats when they pop(register) and then get XXXX # of Schmuckers to spend buying units that are directly under their control. The units are stored in the database. Then, when they finish a "Canon" battle, the results of the battle are updated in the database. Unit deaths, experience gain, profit, etc. are applied. In a non-Canon battle, they simply aren't updated.

We can set up a number of unique factions that players can choose when they pop. Each Warlord has a unique city that they can design? and there will be a bunch(hopefully) of generic maps we can load up. If we do it right we can have multiple warlords to each battle.

I hope that came out coherently. What do you think?

[madmaw]

as far as system goes...

I think it would be interesting to set up an SQL server to keep track of unique players. They can then have "Canon" and "non-Canon" battles.

Follow: each player is a Warlord. They pick their stats when they pop(register) and then get XXXX # of Schmuckers to spend buying units that are directly under their control. The units are stored in the database. Then, when they finish a "Canon" battle, the results of the battle are updated in the database. Unit deaths, experience gain, profit, etc. are applied. In a non-Canon battle, they simply aren't updated.

We can set up a number of unique factions that players can choose when they pop. Each Warlord has a unique city that they can design? and there will be a bunch(hopefully) of generic maps we can load up. If we do it right we can have multiple warlords to each battle.

I hope that came out coherently. What do you think?

Although I haven't thought about the architecture yet, so I can't really say either way, using an SQL server to store the game state might save us some work (the alternative being we could just store everything in memory). There are a couple of options that you can integrate directly into your product that don't require the user to install a server as an external process (HSQLDB).

On the topic of scenarios, surely the first one we'd implement as a test case would be The Battle for Gobwin Knob? That said, I'd like the game to be more of a sandbox style thing, so it will quickly diverge from the plot if you make different decisions than Parson/Ansom do in the comic, making the concept of canon and non-canon battles kind of irrelevant.

[depricated]

actually my idea was more along the lines of keeping track of player information separate of the game. I mean, what's the point of having 20 levels if the highest you'll get is level 4 in a well played game?

[BLANDCorporatio]

On game type

We might want to discuss, briefly, these things. We know there will be klogs over the summer to detail some more world-mechanics aspects of Erfworld so that aspect, collecting rules, will have to wait slightly.

Nonetheless, we can see where we think we can be heading. And the "MMORPG" multi-Warlord idea, also floated in the "Systems of Gaming" thread, is rather nice. I might even be persuaded to delve into communication protocols again for it !

Simplest thing to do is TBS, a-la Heroes of Might and Magic or Wesnoth.

A little more involved is the multi-player/side, each player being a warlord with retinue. It might even be *gasp* inventive- which has the flip side of being prone to epic fail.

On graphics

If I like stop-motion so much I should just go ahead and do something myself There's a shadow of an idea but it's not at all Erfworld related. So enough of that.

Again, it was just suggested as an example. If you guys think it can fly, groovy, if not then it's not.

What I would like to impress on everyone is that we don't need to use 3D engines for the game. Even the MMORPG version.

Then again, not a fan of the cg 3D look. When done right it looks awesome, as I have seen first hand peering over the shoulder of a very talented 3D animation artist. From the same experience I know that the machines required need to be uber-powerful for the rendering. Plus, there's no escaping hard-work.

If you do want to use something similar to stop-motion imitated in Blender or the like, well ... if computer-generated construction paper is good enough for Southpark, it's good enough for us

[Drunut]

I will agree, I think that 3d is not the way to go. I'm one of those people who prefer great pixel or 2d graphics to simple 3d. And I believe that erfworld is and should be a 2d world. That's part of the point of the Arkentools being 3d. Erfworld is a 2d world.

I think we need to think about accessibility. When thinking about graphics we need to keep in mind that this has to be easy to use, and not cluttered. If we have large unit avatars and we have say 40-50 of those unit avatars, things can get slow and cluttered fast. We need to think of a graphic style that is easy to use (you should be able to tell if a creature is a Marbit or a Gobwin from a decent distance.) not to comp. intensive, and streamlined.

[malekith]

holy hell drunut! you must be like my american alter ego!
i swear I was thinking the exact same thing.
and another thing to consider before delving to deep into graphics is play style and UI. I mean we know it's gonna be turn based strategy, but what sort of levels are you thinking of having? A total war style setup, or more advanced wars??
Just to keep you guys thinking
I suppose that's where we start conferring between the two erf game teams, it might be a good idea if you guys can decide what you're doing and get a skeleton/frame ready whilst we sort out our game then we can merge the two together

M

[BLANDCorporatio]

and another thing to consider before delving to deep into graphics is play style and UI. I mean we know it's gonna be turn based strategy

Will have to disagree slightly with you there, on both counts

We don't know yet what it is we will aim for, whether it is a "simple" TBS or something that, while still involving turn-based tactics, will be a bit different than what most people think when hearing TBS.

As for graphics, while discussing things like the view on the units may be a bit premature, discussing the general look and feel of it is appropriate.

Drunut: agree on the accessibility issue. The avatars don't have to be at all big, with a possible exception if the unit itself is "important". Think of a table-top game involving many miniatures, which is the road that real-time strategy games take. Or, for that matter, Heroes and the others as well (though units tend to be a bit bigger in Heroes than in Wesnoth). If that dwagon thing looks big, for instance, it's just for show anyway and can be resized.

In general, what options are there are briefly so:

a) large units, small parties. The Disciples series uses this approach. Two opposing parties per battle, with a maximum of six units for each.
b) small units, medium-sized battles. What real-time-strategy games do. Each individual unit is animated. Typically a couple of hundred units are in the game.
c) size irrelevant, "epic" battles but -> stacks as opposed to units. This is what Heroes does; you can have hundreds of thousands of units on the field, only really you don't, because they are organised in stacks, each stack represented by a single avatar.

Another thing to consider is

a) battle view/exploration view separate. The typical approach for TBS, apparently. In Heroes, only the Hero is visible in the exploration view; other games may show the hero with the units following him/her/it closely clustered together (and maybe reduced in size).
b) all views merged. There is no difference between "exploration" and "battle" mode. The path taken by real-time-strategy.

For inspiration, we can look at Wesnoth. Particularly for what NOT to do Battles quickly become unwieldy if the number of units grows, not because of the graphics but because you need to order your units, as well as wait for them to complete the task. Then, when it's the computer's turn ...

[Drunut]

I believe that option B on BLAND's post is the best option. Sure others might say, "But what about GK? There were thousands of units there!" and that is because it was (i'm going to estimate) 4 or 5 'players' all ganging up on one other 'player. In a classic 1v1 or 2v2 you wouldn't have thousands of units. You might have a few hundred. For inspiration I look at games like HOMM, Star Wars Galactic battlegrounds, and The Battle for Middle Earth. The first because of it's view and style (coupled with mechanics), the second for it's ease and simplicity while still being extremely fun, and the third because of it's unit systems.

Star wars: Galactic Battlegrounds

I've already gone over why HOMM is good so I'll start on SWGB. That game (it's quite old now though) is one of the best RTS games I have ever played with others. Sure the editor was a pain in the rear and the CPU was ungodly hard but when you get 4 or 5 friends together it's fun. The resource system is easy and intuitive. There aren't 80 million different resources and they all play an important but balanced role. Also, if your base is failing (as GK's was) you could get a worker or two in a transport and set up somewhere else.(a tactic often used when facing Expert difficulty CPU.)

The Battle For Middle Earth

TBFME is wonderful becuse of how it handles units, when you buy an average unit instead of getting one you get 20 or so lead by a (you saw it coming) stack leader. The units are killed off individually (the stack is withered out) and as the number of units per stack decreases so does the amount of damage it does. It's also good that when you order a heavy unit (like a troll) it makes one to balance. Suddenly it fits right in with our idea. The first Battle for Middle Earth also had something that is heavily used in Erfworld. Immovable city points. So I find the system to be very useful as reference.

If you have played these games you will know exactly what I mean.

[BLANDCorporatio]

Will look for screenshots of the two you mentioned.

**** The rest of this post assumes we want to create a turn-based something, in which a player/side will control "many" units, on the order of several tens or more, in a battle. ****

What we should look out for is the Wesnoth trap of overlong turns because each unit needs to play its action. That, when done on a scale of the hundred units, would be ungodly. Download Wesnoth, it's free. Play with it for a while. You'll see. Without even nearing the hundred unit mark.

So, if we want to have something RTS-like in terms of individual unit count, we will need to consider the RTS approach of units doing their thing simultaneously.

But how come, we are doing a TBS game and sometimes it makes all the difference which unit attacks first and which second- it's a vital part of tactics!

Here's a suggestion- have units attack in "waves". You could order several of your units to carry out actions, but they wouldn't start until you say launch wave or similar. Launch wave, and the units simultaneously do their thing (which would be a killer for the interface as all those views will have to be merged somehow ... or maybe not we'll see). Then, after/during the wave executes you can relay orders for the second wave etc, until all your units exhaust their action points.

A computer player would do the same thing obviously. Nobody in their right mind would want to wait while a computer individually orders its 200 units around.

[Drunut]

I don't understand what you are saying Bland, could you clarify? I get the Wesnoth turn time ordeal (*shudder*) are you considering something like games such as Disgaea and Final Fantasy Tactics where you tell everyone what to do and then hit an "execute" button?

I was going for a HOMM style turn system. There is a Fog of War that prevents you from seeing what you haven't scouted or used Eyemancy to see. Every person takes turns moving but if they are engaged they can actively retaliate. And at pre-determined times units pop at each of your owned cities.

EDIT: I would assume that units would attack on your side by whichever order you assign them. (so you want Dwagons to attack then archers. Therefore you select your Dwagons and tell them to attack and then you select your archers to attack.)

[privatepepper]

From the same experience I know that the machines required need to be uber-powerful for the rendering. Plus, there's no escaping hard-work.

Actually, no. Play "Morrowind: The Elder Scrolls III" on a Windows 98 with a 36-bit Athlon processor and a graphics card that was substandard in 2003, and then tell me that awesome 3D needs uber-powerful machines. Although, yes, 3D wouldn't be too necessary.

[privatepepper]

So, it looks like we're probably going to end up with something similar to Heroes of Might & Magic and Battle for Wesnoth.

So, from there, how -specifically- are we going to do this?
Hex display (large or small) -A) Only allied units may share the same hex- the highest ranking warlord / strongest unit is the only one shown over small hexes or B) Only units that are not at war with each other may share the same hex. The strongest units of the first few stacks are shown in small icons over large hexes.
Combat (simple, less simple, less simple & graphic)- A)Will combat be simplified to the entire block of units like Meier's Civilization, or B) to individual stacks like Heroes of Might and Magic (might be intellectual property issues there), or C) showing the entire stacks on a "battle" screen but still treating them as groups?

I would personally go for the large hexes, so that more detail can be shown on the battle screen.

I think a combat system that pulls you out of the overworld map is a given- my preference would be for the player to control the warlord and give simple orders (engage, retreat, defend me) [I forget- which is the Star Wars game where you have four options to give orders?] to units- one order per stack, and the units would take the most direct path to their target and follow the order until it is changed. Since Erfworld makes it clear that units are not 100% loyal, giving the player reduced control would probably be best.

[Drunut]

I would assume that with hex sizes that when your zoomed out you would see a regular hex, but when you zoom in the sub-hexes would slowly become visible. Also I would go with option C on battle displays. Maybe when your zoomed out (to full Hex) the stacks are shown as one unit with a number, but as you zoom in (to the sub-hex layer) you see many units where that one unit was, though you control them as a group. Do I need to clarify the sub-hex idea?