Basic Design

I know this might be a bit early, but I just wanted to share my vision and hopes for this game.

RTS games have had the bad habit of focusing around resources and that is crap, in my opinion. While the aquisition and spending of resources gives a very interesting strategic element to games, the fact that all those games all pretty much only revolve around getting the biggest and best units the fastest makes it a crappy rts in my book. Strategy should be about what units you choose, where you send them and how you handle them.

So what I hope is to avoid this as much as we can. No resources. I have however read about an interesting game called Z where you could get more soldiers by owning flags that represents areas of the map. This sounds like a good replacement for resources to me. The idea of scrapping all kinds of resources irks me a bit becuase it could be a little bit too simple for a game. Now having the element of conquering areas that you might otherwise ignore makes for a bit more interesting battles. For example, a common question could be: "Would it be worth it to take that valley? Does the units it can produce be worth its poor defense?"

I figure we'd start the development with the idea of having merely one "race" and only a few basic units, thus not having to worry all too much about balance. So I think having pikemen, standard melee units, archers, light and heavy cavalry might be a good way to start. Anything else is just a bonus. They should be handled in "units" gathering a bunch together, yet everyone should count. I'll elaborate on this later, it is a bit too complex to start off with.

Maps are a tricky thing. How will that be handled? Making static maps or making them generate themselves based on a few guidelines and models? What kind of protocol would be used for maps? Should we put effort towards making a map-making program or is that something we can wait to decide? It feels a bit like something we should decide in the beginning so that we will keep that in mind will developing the map-protocol.

Alright, I think this might cover most of the basic issues. Discuss them please as well as anything else needs to be discussed. Anything you disagree with?

All the game design concepts seem fine. We needed some end goal to see what we might want to emphasize on in the coding but for now our first milestone should be to get a single unit that we can move around and a simple map with only grass.

We also need to address the camera angle. I'm assuming it will be the normal 3rd person view at a 60 degree angle to the terrain and not 90 degrees (i.e. perpendicular). If we do it that way we will need to work heavily on layers and I suggest we have the domain layers, which also brings about the question of do we want the ability to dig underground? If so we should consider the domain of layers to be all integers and have 0 be the terrain and negatives be below the terrain.

Sounds like a good milestone. Nothing to fancy or advanced, but a good start.

60 is standard? Should be our goal then I think. I've really got little knowledge how to do this and really no idea why layers are so neccessary. I really don't have any opinion of digging underground either. I feel it might be a cool feature, but for all I know, that is all it is, a feature, and it could be added later, right? Though it might be worth it to consider it from the start, to save trouble when, or if it is being added later.

I don't have much hands on experience with actual graphics but from what I've read, seen and talked about layers for 2D games are important and here's why.

If you look at the zelda picture I've provided you'll notice that Link is drawn on top of the grass. That is because Link is being drawn on a layer that is higher than the terrain layer. The same goes for the trees and the bushes, but it should be noted that Link can go behind trees and in that case part of the tree's graphics is on a higher layer so certain pictures will have to be decomposed into various layers. Layers can also be used for pathing and blocking issues. Link can't walk through anything that is in his layer or higher.

Also I've thought about the wrapper class now and I think it might be a bad idea. I've looked at some opengl tutorials last night and a good deal of the event handling is captured in the opengl itself and it also has some aspects that might not be easily captured in a wrapper class. So it might be more work to make a wrapper class and it will probably add an extra layer of complication. The advantage of a wrapper class however is that it would make the code portable heh ;P

Anyway from the sound of it we seemed to be starting to already have our roles cut out for us :rolleyes: We should go about our decomposition soon. I'll get to it in a few hours as soon as I've finished things.

We should really talk, this forum thing has too much delay. =)
I'd suggest IRC but as long as it is just us two msn or Xfire will suffice.

Layers sounds critical, when put like that, yes. =)

And about the wrapper class. It could be alot of work, but if we can find out more or less what we need, or more specifically, the worst case when it comes to the events and so, we could create a specifically designed wrapper that will limit the use of the library, but also make it easier to make. The biggest advantage however, comes from the act of actually creating the class. By creating it you gain alot of knowledge about it and when done, you rarely need it =)

Sure you could just read about it, but the act of learning by experience is for me alot more effective and I've found a wrapper class to be the fastest and most useful way for most cases. Though I agree that there are some things that just ain't worth the effort to wrap.

A few hours? Could you be a little more specific? I need to know if it will be soon enough for me to stay up long enough or if I should go to bed right away so that I can get up earlier tomorrow instead?

Sleep now and wake up tomorrow. I have a lot of things to clean up both in real life and in EvE.

oh right here's the picture...

Quote:

---

Originally Posted by Angeleon

I know this might be a bit early, but I just wanted to share my vision and hopes for this game.

RTS games have had the bad habit of focusing around resources and that is crap, in my opinion. While the aquisition and spending of resources gives a very interesting strategic element to games, the fact that all those games all pretty much only revolve around getting the biggest and best units the fastest makes it a crappy rts in my book. Strategy should be about what units you choose, where you send them and how you handle them.

So what I hope is to avoid this as much as we can. No resources. I have however read about an interesting game called Z where you could get more soldiers by owning flags that represents areas of the map. This sounds like a good replacement for resources to me. The idea of scrapping all kinds of resources irks me a bit becuase it could be a little bit too simple for a game. Now having the element of conquering areas that you might otherwise ignore makes for a bit more interesting battles. For example, a common question could be: "Would it be worth it to take that valley? Does the units it can produce be worth its poor defense?"

---

Company of Heroes uses a territorially-based resource system. Its interesting, and allows for a lot more combat a lot sooner. As an RTS developer myself (mere historian, no technical skills), I've always found that sort of approach to be more "tactical" than strategic. Games are over relatively quickly, or focus primarily on command&control during long, static battles. "Traditional" RTS design allows for more calculating, slower-paced maneuvering, and typically requires a more "grand strategy." Like real war, this involves a lot more than just seizing territory and shooting people up -- but it takes away from the fun.

That said, resource-collecting RTSes can easily have well-balanced unit types, as opposed to having "uber" units that you create entire armies out of. Rise of Nations was relatively close (until the end game) to this, but the rapid progression of time would allow disparity between forces.

A good place to start, in my opinion, would be to describe how you want a typical game to go. Do you want "eras" as in most 'slower' RTSes? What will players start with? What diplomatic options are available? How about trade and how will the economy function as a whole? I don't know if I'm looking too far in, but these are just some thoughts I'm having.

Quote:

---

Originally Posted by Aethelric

Company of Heroes uses a territorially-based resource system. Its interesting, and allows for a lot more combat a lot sooner. As an RTS developer myself (mere historian, no technical skills), I've always found that sort of approach to be more "tactical" than strategic. Games are over relatively quickly, or focus primarily on command&control during long, static battles. "Traditional" RTS design allows for more calculating, slower-paced maneuvering, and typically requires a more "grand strategy." Like real war, this involves a lot more than just seizing territory and shooting people up -- but it takes away from the fun.

That said, resource-collecting RTSes can easily have well-balanced unit types, as opposed to having "uber" units that you create entire armies out of. Rise of Nations was relatively close (until the end game) to this, but the rapid progression of time would allow disparity between forces.

A good place to start, in my opinion, would be to describe how you want a typical game to go. Do you want "eras" as in most 'slower' RTSes? What will players start with? What diplomatic options are available? How about trade and how will the economy function as a whole? I don't know if I'm looking too far in, but these are just some thoughts I'm having.

---

No rts with resource management has had a good balance in my book. The first two Age of Empires were close, but in the end, they too can't keep up the resource vs unit balance. And a rts cannot 'easily' have well-balanced units becuase the moment you introduce resource-management the cost vs power balancing becomes maliciously tricky. There is a reason why rts games with resource management don't have well-balanced units, and that is becuase it is hard.

In my opinion, a game should progress something like this:

First, creation of the game. Player one waits in the lobby and player two connects. In the lobby the size of the starting army is decided along with other aspects, but the size is the more important one. Then, each player chooses his starting army from the units available and then the game starts. Both players now have an army composed of units of their choosing but otherwise equal. They start. Now, something that they should defend like a castle or something could be good to give a clear objective, but otherwise it is kind of irrelevant.

With this army, they scout and manouver across the map, trying to meet the enemy at strategic locations at the map so that they will have the upper hand, while at the same time trying to get as many areas as possible to get some reinforcement.

Battle will ensue and whoever utilizes the terrain(hilltops, valleys and obstacles) along with the tactical formations the best will emerge victorious. Whenever this winner feel confident, he attack the base of his enemy and wins. This won't be games that take hours for each play, but the speed of the skirmishes and the movement of the units are something that probably should be decided through testing, and at this moment, battles a bit slower than in AoE2 should be good, to properly be able to manouver and use the formations, if they get implemented.

Sounds almost exactly like Warhammer the mark of Chaos and err that didn't do too well. Anyway that's not the point, guys try not to think too much about the game design right now! You're going to start day dreaming and get ahead of yourselves. It seems to be the number one amateur project killer... one unit and some grass!