Gregor,
Thank you for your response.. I have received quite a few and I have really be happy about the good comments. I will respond
inline below.
Thanks again,
~Aaron
Gregor Mückl wrote:
> Hi!
>
> First of all, the difficult part of making a game is not so much having a good
> idea than actually implementing it. Don't underestimate the sweat you have to
> put into a game to get it done. No, I'm not speaking of fun coding, but of
> hard work. But I'm sure that you have heard this before. So let's get on with
> the details:
hahaha, Yes more then once.. I keep reminding myself that Linus's first mail "Can I please have the posix standard to write my own
kernel" must have received a similar response.
> Every text about game design I've ever come across told me one thing: game
> design never is a democratic process. The designer himself has to decide in
> order to get a proper balance (both features and playability) and look and
> feel into the game.
>
> Therefore, asking the comunity may actually be counterproductive: Either you
> are very cooperative and end up with a bloated, unplayable design or you are
> restrictive and kill people's interest in the game.
>
> The only possible way I see is to do periodic playability tests in order to
> get the balance right and get a grip on the most obvious misconseptions in
> the design.
This is an important point. I have also read such texts. I agree with them in general since most games have a set of rules they
are designed under. These rules can be a point of argument. I am assuming a limited set of rules such as "all objects must be
historical and relitivly non-fictional","all simulation code must try best to simulate reality". I was hoping such rules would keep
people working together but given them a freedom to work on areas of personal interest. I will make a note of this.
> > 2)The main engine is a balanced tree with “game time” as the key. Each
> > player will run his own tree and only check in with a central server
> > periodically to stay in sync. When a unit is moved it must publish events
> > locally, if it moves onto enemy ground, it must publish on both the local
> > and remote event tree.
> >
>
> This is a *very* problematic approach. This way you open barn doors for
> cheaters. Because each player has the only authoritative copy of his map
> locally it is on him/her to edit it as he/she likes and noone would even have
> a chance of noticing that.
>
> Online games are by nature very open to cheating. The only measures against
> cheating that I am aware of are rather drastic:
>
> - use a server that decides on *everything*. If a citicen in a player's city
> wants to poop, the server must confirm it.
>
> - encrypt/obfuscate network traffic.
>
> - never release the sources for your network code. This is not as far-fetched
> as it might seem: it's very likely that the people at Valve are rewriting
> their Half-Life 2 network code totally from scratch after the sources leaked
> in October. The release date hasn't been moved for nothing.
>
> Yes, right: it's a lot of effort, but it will only stop people from cheating
> for so long. There is no single method with which you can stop cheating.
> Create an online game and you are forced to enter a fight.
This is a very important comment that I would like to be flush out on his list if possible. Given the original proposal to have a
large number of concurrent players, a distributed model was seen as very critical. With that as a goal, a single server is not a
pleasant option. Encrypting network traffic seem the most realistic to me.
> > 3)The technology mapping (i.e bronze age, before stone age, computers
> > before lasers) and all unites and buildings are customizable. The idea is
> > to support more building types, units, and buildings then any one person
> > can ever play. Given boundless options, the resulting society will feel
> > very personal to the game player. This has two levels, A example is a
> > decision to research "tanks" instead of airplanes. The other is to set
> > "zoning" rules so the buildings in a town are of a style comfortable to the
> > player.
> >
>
> Sounds great. Really great.
>
> But wait: who is going to make all those graphics? Who is going to balance
> such a huge set of units? Who is going to test all this?
>
> Consider: Even professional development teams with sometimes up to 100 or even
> more developers can't create games that have that many different buildings or
> units. And we hobbyists even have trouble finding artists that want to work
> on our projects with us.
Hahaha.. Testing... we don't need any stinking testing.. :-)
I worked as a Developer for a large simulation model for a government contract. Our simulation design contained classes for "unit"
and function classes such as "move, attack, look" Generating a new unit for the simulation was really just a matter of defining the
name of the new element, linking the appropriate function classes and object constantes and then placing the correct graphic on
top. Only when a unit required a function type not previously used (generate chemical weapon plum for example) was another function
class needed. I am hoping this model will allow for alot of re-use of some of the harder parts of the model (way point movement and
such).
Balancing the units I will address in the Great library section
Graphics... I have currently rounded up 4 graphic resources, one of which is actually a small graphics company. I agree that
graphics are a key need. My hope (wish, prayer) is that the core team will work hard to release a game with a limited set of
objects and graphics, and if creating new unites is as easy as linking functions and adding a new graphic players of the game will
want to work to add the unites they want in the game. (I am aware this is a reach... My point is the focus early will be building
the frame work and units should come second)
> > 4)Great Library: A open source game that incourages new unit devolpment
> > needs to set rules. The issue of fairness is solved by having a "Great
> > Library" server hosting what units and rules will be used in the current
> > game. This is important since a project goal is to setup a server to
> > provide a commen set on the net if the user doesn't want to start there
> > own. This might also move into storing a saved city.
> >
>
> I don't get this.
>
> Do you allow the user to create units of his/her own?
Yes... I am counting on it.
> If so, what about the AI?
Not currently part of the plan... unless you know of a really smart guy :-)
> What about the strengths and weaknesses of the unit? Who is going to
> control and balance that?
When a game is started both/all players connect to the Great Library on the server side. If this is started as a "lan party" then
the units and technology mapping on player "A's" hard disk is used . all players A, B, C will use that layout. That does mean if
someone wants to make a super weapon and add it to the game it will be there... It will be available for all people to play...
Now, playing Total Anialation I got tired of joining games and not knowing which new unit was the "super unit" so We decided on
having a Great Library server running from the project web server. That way, if you go online you can use the "approved" set of
units. People can create unites themselves, use them for a Lan party and then request they be included in the "approved set". This
opens the Open Source model up to more people. Rookie developers aren't going to request CVS accounts to view the egnine code, but
they might hack together a new unit.
> > 5)City Management is similar to SimCity (zoning and taxes) but the purpose
> > is to generate money to build a army and walls and weapons. Too many RTS
> > games become routines (i.e. build 10 peons, then a barracks, then a house).
> > Mixing a real city simulation in with the tatical needs of the King should
> > be much more interesting and much less predicatable.
> >
>
> Well, I dare to say that games that are too complex are unattractive. I have
> the impression that a lot of (esp. casual) gamers want rather small, limited,
> easy to play games. You are heading into an entirely different direction.
>
> I'm not saying that nobody will want to play your game. I'm just saying that
> it is likely that you end up with a very small community and no chance to get
> near the mainstream.
I agree this game is not small, however I disagree that it will be complex. It will "have alot of options" Starting a new game
will be very simple and once running the game will run like a simulation with very little effort. I have found the games people
like the longest are the ones that start off easy, are very easy to get into, but once you become a fan allow for many many levels
of interest. From casual players to people generating new units they want to have in there cites.
> > 6)Unique units: This is easiest to explain with a example. When selecting
> > a unit factory (i.e. a barracks) you can decide to build a archer but a
> > slider will allow you to generate a more accurate archer, but it will take
> > longer. Also every battle this unique archer fights in will slowly
> > increase its unique accuracy factor. This adds a great deal of game play
> > as grouping veterans with rookies in combat units just adds another level.
> >
> Again the issue of balance arises here. Combined with your "library" above
> this is getting worse in my eyes.
This point is similar to the one above and has come out of alot of discussions with people. In the beginning most people will just
say "build a archers" and be done with it. Only a more experienced player would want to mess with options like this. But wouldn't
you want that option once you became a skilled player? It is really just a feature on the top of the object model. If each archar
is just a element class, with a collection of function classes like "shoot, move, die" then updating the objects individual
constants is easy... I am actually hoping to use a RPG style set of parameters for each element (hit points, life, skill level) to
make each unit in a army like a little RPG player.
> > 7)Massive online play: given that each player is running a unique event
> > tree it is planned to have massive online games (i.e. hundreds of players)
> > There is a plan to allow for citys at different stages of evolution to play
> > together but not as direct neighbers.(sprial layout based on a societies
> > age)
> >
>
> What about network synchronisation in this case? Will it work differently from
> what you explained above? What about cheaters then?
Each players tree periodically does a sync as you correctly assumed. No, it does works as described above. What will happen is at
the start of the game a "event" will be inserted in to the tree X seconds from the start. When this event comes up the tree will
sync and then push a new event onto the tree X seconds in the future to resync. To allow for many many players I can't have a
central server. Each players tree runs the events on his own map, and his own units. Only when a unit from player "A" walks onto a
map space owned by player "B" is there any network traffic. Each unit in that situation is required to post events to both trees.
In this way you can have many many people playing all on one "big" world but only posting events to neighboring simulation trees
when there is a need.
> > 8)Community: Since the game will support massive online play, and alot of
> > personality in each city, the hope is to support direct chat, and other
> > "IM" style features to encourage people to go online and let the game run.
> > If there isn't a active battle, you could let the game play a little like
> > SimCity and spend your time chating with other players. Some people will
> > want to fight alot of battles and some people will want to run the game
> > like a game of Sims or SimCity but will be able to share there designs with
> > others.
> >
>
> You are putting your players into two categories here: let's call them
> "builders" and "fighters". If builders and fighters never meet everything is
> fine. But what happens if a fighter attacks a builder? This will spoil the
> fun for both of them: the builder will have a hard time defending against the
> fighter while seeing his carefully crafted city go down the drain and the
> fighter will not get the fight he seeked for.
Agreed, and this is a very good point. I have previously commented on have a massive online play. It might be a good idea to
describe having a "few" worlds. One labeled as non combative. The easy thing is this idea is already supported in the design. All
that is needed is for 2 Great Library servers to be running... one with and one without combat unites...
> Except for the issues I pointed out your concept looks good so far. I'd
> recommend you to write it down in as much detail as possible and review it
> carefully for possibly contradicting passages. Given the size of your project
> this concept should at least have 20 pages, better 100 or more. Such a
> concept can be a useful reference lateron and also does an excellent job
> preventing you from drifting off too far from what you originally intended.
Agreed,
This document is what I intended to be open for public discussion, but given your comments and others I will get together with the
current team and try and get a few hundred pages together as a starting point.. :-)
> Anyway, I wish you good luck with this project!
I am sure I will need it.. and lots of help...
Regards,
~Aaron
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature