=====Contents========= | |
- Project Overview (#post_ProjectOverview)
1.1 Title (#post_Title)
1.2 Logo (#post_Logo)
1.3 Game Description (#post_GameDescription)
- Goals (#post_Goals)
2.1 Main Goal (#post_MainGoal)
2.2 Target Audience (#post_TargetAudience)
2.3 Platform (#post_Platform)
- Basic Agreements (#post_BasicAgreements)
3.1 Measuring Standards (#post_MeasuringStandards)
3.2 Gamespeed Logic (#post_GameSpeedLogic)
|
- 1 Project Overview
- 2 Goals
- 2.1 Main Goal
Main Goal
- 2.2 Target Audience
Every human from 9 years old should be able to play this game.
Mainly (ex) SimCity 4 players. Our target is the niche simulator market, not the causal player.
- 2.3 Platform
The game should be playable on Windows XP or higher, Most popular Linux distributions and MAC.
- 3 Basic Agreements
- 3.1 Measuring Standards
The game uses the following measurement units as standards.
- 3D axis (space): (X = width, Y= length, Z = height) (!)
- Distance is measured in meters or kilometers (m or km)
- Time is expressed in hours, days, month's and years.*
- Weight is expressed in kilograms (kg)
- Velocity is expressed in meters/second (m/s)
- Volume is expressed in cubic meters (m³)
- Force is expressed in Newtons (N)
- Currency is expressed in credits (cr)**
- Angle is expressed in radians (rad)
- Power is expressed in Watts (W)
- Temperature is expressed in Celcius (c)
* | | A new game starts in year zero (0). We don't use 'realtime' dates. For example: Of course depending on the decision if we use the region method like simcity is using, the year zero starts when the first city has been saved to the region. This date counts for the whole region. If you start a new city in the same region 6 years later. All (new) cities use the region date and time it is based in. |
** | | Based on Euro's (€), the name 'credit' will not be shown to the player.
The value will be converted on the base of € to the player's desired currency. |
- 3.2 Game Speed Logic
to be edited...
With speed we mean the time in milliseconds. How many milliseconds before a AdvanceOneHour() like method is called.
This should be edited as i don't know on what we base the time.
to be edited...
Speed multipliers:
0 = pause
1 = slow
2 = medium
3 = fast
4 = ultra?
|
W O R K I N P R O G R E S S
This is the stage where the previous attempt (UrbUrbis?) died. Lot of talking over ideas but not much coding or asset creation. Everyone has their pet idea on what will make this the Best City Game Ever™ and some of these ideas will conflict with each other. A design document makes sense for standard commercial applications which ships a final product, but not for open source project. Some elements of a design document is needed such as coding style and how the components fit together. What makes a lot more sense is a roadmap.
Example pulled from my rear:
0.1 basic rci, citizens can use road network
0.2 basic land value calculations, basic budget
0.3 terraform tools, custom content system
0.4 - sim city equivelnt gameplay
...
0.7 sc3k equivelnt
...
1.0 sc4 equivlent
Doing it this way instead of a full blown 1.0 document will help keep the team focused. There have been awesome ideas like being able to go into city hall and see your advisers or underwater cities or whatever, but going for a full design doc will cause the team to focus on these awesome end-point ideas instead of the more boring but more important practical matters.
I like OTTD suggestion policy, if you want you idea in game make it yourself ;D Then the devs go over the code and commit it to the trunk if it meets quality standards. A lot of features in that game were added as patches from people whoa re not on the official dev list.
Quote from: croxis on August 31, 2009, 12:40:34 PM
I like OTTD suggestion policy, if you want you idea in game make it yourself ;D Then the devs go over the code and commit it to the trunk if it meets quality standards. A lot of features in that game were added as patches from people whoa re not on the official dev list.
The first priority is creating a base, like simcity 4.. and do it in such a way, mods can be add with ease.
Right, I fully agree. I threw up an unsorted list on different features in sc4. I also have the delux edition prima guide which provides numbers to help give us a closer approximation.
As croxis noted, don't call for input now because you'll be inundated with pet projects that may sound wonderful but will sink the boat. Stay focused, your roadmap is very clear: build your core, and when you get it to run like SC4 with SC4 modded content, then invite everyone in for a party. A core team building the core should be your first goal.
Work like the NAM team; who knows really what they do; the suggestions don't faze them, they just do their stuff, and when it appears it's great and everyone's happy--but no one voted. ;)
I have created basic outline of Roadmap and it is here:
http://wiki.github.com/Nique/CityMania/roadmap (http://wiki.github.com/Nique/CityMania/roadmap)
I invite you to modify it and expand it in detail. It would also be very good if someone would set tags so it look a little bit nicer. For quick review here it is
Quote
Roadmap:
-Write Design document:
Specification of goals:
Minimum features required.
Optimal features list.
Nitpicking.
Description of social model.
Description of economic model.
Description of transport model.
Description of environment model.
Outline of software structure.
Choice of programming languages and development tools.
General software implementation.
Simulation-Graphics engine communications protocol implementation.
Economy implementation.
Society implementation.
Transportation implementation.
Environment implementation.
Interface design.
Graphics implementation.
Additional modding tools.
-Based on design document write pseudocode for critical parts of the project.
-Develop simulation engine until minimum of wanted features are reached.
-Simultaneosly develop "quick and dirty" graphics engine for tests of simulation engine.
-Get people to test simulation engine.
-Gradually add features to simulation engine.
-Start developing actual graphics engine.
-Start developing additional tools needed for the project (modding, content tools).
-By this stage, simulation engine should support everything from optimal features list.
-When minimum of simulation features are supported by graphics engine get people to start testing.
-Add features to graphics engine up to the optimal features.
-Reach version 1.0
-Add further features both to the simulation and graphics engine.
Ah, that way. Well, it does look pretty good to me, though there are already a few errors I spotted, and since it looks unfinished, I think there will be many more to follow.
Regards,
Korot
Ps: Het Engelse woord voor moeder taal is 'native language', niet 'mother-tongue language', alhoewel het begrijpelijk is, voor mij, iemand die Nederlands kan, althans.
Ack, hard to copy and paste text embedded in flash so I could edit it :P And git hub is down.
Ok lol,
Well see the attachment.. here it goes.. i know exactly what i want to write. My weak point is my English, (still learning it while I'm 25)
docx = Microsoft Office Word 2007
pdf = Adobe Acrobat Reader
Nique, I suggest saving the Word file as a .doc instead of a .docx. Why? Because Word 2007 can open .doc files, but Word 2003 has a difficult time opening .docx files. Still, I've got the file, now to check it on grammar issues.
Regards,
Korot
Thank you.
Regards,
Korot
Found and fixed some grammar mistakes, now if only my permissions were set properly to allow me to upload files. I already contacted jeronii, but I think that Dedgren might be a better call. Though, Nique, having you mail address in your profile means I can send the file to you, which I'm doing right now.
Regards,
Korot
uhm, my version is finished but I can't upload the file
Quote from: WC_EEND on September 02, 2009, 01:29:40 PM
uhm, my version is finished but I can't upload the file
Send the file to nick by mail, you can find his mail address in his profile.
Regards,
Korot
Quote from: Korot on September 02, 2009, 01:30:42 PM
Send the file to nick by mail, you can find his mail address in his profile.
Regards,
Korot
just did that
Ok, thank you
I think i will approach you guys in the future (if you want) for more. This document is far from finished, but it is a start.
Quote from: Nique on September 02, 2009, 01:36:54 PM
Ok, thank you
I think i will approach you guys in the future (if you want) for more. This document is far from finished, but it is a start.
sure, count me in
I threw my edit on the wiki
Wasn't the Wiki down?
Regards,
Korot
Hope I'm not too late to give a hand!
Jayson
Quote from: sithlrd98 on September 02, 2009, 01:56:39 PM
Hope I'm not too late to give a hand!
Jayson
Thank you
I think your way is the best (because it's your native language).
I'm sorry i can't write the document in good english but with the help of you guys it will look more serious.. because it's worth to be taken serious.
Github is now bakck up
If you guys want to change anything or add new parts, go ahead. I want this document being finished so that we can start with the big work soon. (don't forget about the roadmap).
As writing documents is not my best skill, i can only describe in wrong grammar what i want to put there :P
Anyway:
The WIKI is the BEST place to do it. Don't use Word / pdf, i did this because it was just easy for me. The final version will be also written in a downloadable binary file like doc or pdf. *Using wiki on the github, we can change things without losing the original or other versions of the document.
Quote from: Nique on September 02, 2009, 02:06:08 PM
Thank you
I think your way is the best (because it's your native language).
I'm sorry I can't write the document in good english but with the help of you guys it will look more serious.. because it's worth to be taken serious.
Despite it being Sithlrd98's native language, I still find errors in his version. For example, I was always told that a ',' should go before 'that', that player isn't plural.
The sentence: "This game will make use of full 3d models to place, but render the graphics once the player places the object at the desired angle." Still looks weird to me, as you place something on a certain location, not on an angle and a couple of other, similar, problems.
Regards,
Korot
Edit (sort off): Nique, could you provide the link to the wiki?
http://wiki.github.com/Nique/CityMania/
I mainly kept the original context of what was being said . I wanted to change the wording , but keep as much of the original intact. Hey, just because I can speak it , read it and write it , doesn't mean I'm a master of it! ;D
Jayson
Lol,
I really hate that texttile thing.. i can't make-up the text right.
Quote from: Nique on September 02, 2009, 02:09:43 PM
I want this document being finished so that we can start with the big work soon. (don't forget about the roadmap).
Don't rush. The more we pay attention now, easier out lives are gonna get later.
Quote from: tomkeus on September 02, 2009, 02:57:25 PM
Don't rush. The more we pay attention now, easier out lives are gonna get later.
I don't want to rush it (i never rush) but at least, i wanted to make a start ;)
Look @ start post
I think we need to be careful about calling it a sc4 clone. SC4 seems like a major inspiration, but we will not be copying sc4 exactly. Also I am not sure I like the word credits. I am positive we could come up with a cute, humorous name. We could also copy what OpenTTD and have the player select which currency they want to use, and the game will adjust exchange rates accordingly. (based on a predefined table that approximates the ratios, not the real life day-to day exchange rates)
Other than some wording, everything looks good!
Quote from: croxis on September 03, 2009, 12:52:42 PM
I think we need to be careful about calling it a sc4 clone. SC4 seems like a major inspiration, but we will not be copying sc4 exactly. Also I am not sure I like the word credits. I am positive we could come up with a cute, humorous name. We could also copy what OpenTTD and have the player select which currency they want to use, and the game will adjust exchange rates accordingly. (based on a predefined table that approximates the ratios, not the real life day-to day exchange rates)
Other than some wording, everything looks good!
See the * note on the bottom of that list
I swear that wasn't in before! ;D
Quote from: croxis on September 03, 2009, 01:07:15 PM
I swear that wasn't in before! ;D
It was, but maybe badly formulated. i changed just one word... instead of value i wrote 'name'.
If you want to add/modify something to the document, please contact me or post a new reply on this topic.
I want to have croxis and tomkeus also moderators of these forums as they have a lot of input and are serious also about this game.
Game speed logic is already added. The server framework is event driven, so the spinner will send out a blank "tick" event periodicy. Right now Slow is set to 1 a second, medium 2, and fast 3. I figure each tick would represent a game day. Some other part of the program will listen, properly count the ticks depending on the month, and send out an event for AdvanceOneMonth() at the appropriate time.
Quote from: croxis on September 03, 2009, 08:53:42 PM
Game speed logic is already added. The server framework is event driven, so the spinner will send out a blank "tick" event periodicy. Right now Slow is set to 1 a second, medium 2, and fast 3. I figure each tick would represent a game day. Some other part of the program will listen, properly count the ticks depending on the month, and send out an event for AdvanceOneMonth() at the appropriate time.
Just to add a few details, to make sure there are no misunderstandings.
Game speed should be handled by clients not by server. Simulator has no concept of time. It just queues instructions, at AdvanceOneMonth() he executes them and once it's done it waits for new instructions. Game speeds should be implemented within GUI. Game speed will only determine interval between consecutive AdvanceOneMonth() calls by GUI.
croxis:
will you implement queuing?
We need to be able to queue instructions while server is busy performing simulation.
Having the clients determine the simulation speed, and having the server have no concept of it, is a terrible design decision imho. But I guess I'll do it anyways because I don't have a sufficient argument not to.
Is there any way possible to start with some base coding for the game this weekend?
Quote
Having the clients determine the simulation speed, and having the server have no concept of it, is a terrible design decision imho. But I guess I'll do it anyways because I don't have a sufficient argument not to.
That's because I haven't explained in detail what I had in mind when I mentioned client/server method. I'll write down in more detail and post it here. I need input about that, especially from people who know networking. I hope I'll get to do that and some other things by the end of the weekend, but I'm not promising anything. I'm throwing a party tomorrow night so I'll try to do something this evening and tomorrow morning before I'm put out of commission.
OK, I'll need to elaborate a bit one thing I haven't been
particularly clear about. That is division between GUI and
simulator.
Let us examine in more detail SC4. Player is unaware what is
happening in the city. What he sees are pictures of buildings,
roads, animations of buildings under construction, cars running
around and so on. Player is not exposed directly to the
simulation. If he wants directly to access data produced by the
simulation he has to query building, graphs or various maps.
Each of this aspects is updated once per game-month. Based on
that appropriate animations and appearance are chosen.
The fact, that player is not directly exposed to the
underlying simulation is in the core of the idea of
GUI/simulation division.
To abstract a little bit. City is a complex system whose state
is described by numerous parameters. City's state is a function
of time, meaning that it is continuously changing. Within
software, city is stored as a number of variables, and
simulation is performed with a number of functions operating on
aforementioned variables, producing new set of variables which
represent new state of the city. Time evolution of city's state
is discretized for the sake of computation, meaning, that
consecutive states are set apart by some finite game-time.
Here, it is very important to choose optimal model to simulate
city and its evolution. Too detailed model, meaning too many
parameters and functions, results in high computation
requirements . Same statement holds for very fine
discretization of time.
Thus, parameters are chosen on the basis of their importance
for description of the most essential aspects of the city: like
population, budget state, traffic flow etc. Time step is chosen
so to provide realistically changing city, but since the player
is exposed to continuously animated city he is not particularly
aware of underlying evolution of the city state. So time step
doesn't have to be too small.
This is how I've envisioned gameplay:
GUI will provide the player with the visual representation of
the city's current state, interface to alter city's parameters,
appearance and query various details. When player starts new
city he will be presented with the blank terrain. Clock is
paused. Let's say player starts game at game speed normal.
Let's say that in normal speed, one game-month lasts 1
real-life minute (though, this will not hold exactly - I'll
explain bellow). Since this is the beginning player will
perhaps start building some necessary infrastructure, like
power plant, road connections and such. When he lays down
stretch of the road information about that construction will be
queued. Same for other construction or other changes player did
(like tax change).
When clock counts one real-life minute, these changes will be
sent to the simulator. Simulator will start crunching numbers
and then it will produce list of things that have
changed within duration of one time step. These changes
will be communicated back to GUI. When GUI receives updates it
will start new countdown and implement changes. Don't forget,
that all this time, GUI constantly displays animated city, so
player won't see city freezing up while simulator performs
calculations.
Now, let's continue. Player will continue making changes to the
city: he may lay some more roads, zones etc. When clock counts
another minute, all new changes player made are again sent to
the simulator in order for new city's state to be calculated.
Simulator will perform calculations, communicate them back to
GUI and so on.
Now, actual duration of in-game month will be one minute + time
simulator needs to perform calculation of new state. So,
fastest speed available to the game will be in-game month
lasting real-life time needed to perform calculation of new
city state. So, game speeds will be applied in GUI with clock
setting time between moment GUI receives update from simulator
and moment GUI sends to simulator changes player ordered to be
carried out.
This leads to design of communications interface. Interface
needs to be capable of queuing instructions reaching from the
GUI (more of them), and when the GUI's clock counts down,
queued instructions will be sent to the simulator. Immediately,
interface will start new queue accepting new instructions from
GUI while simulator is busy and so on. Once simulator finishes
calculations, changes to the city's state are sent to the GUI.
Here is rule I suggest for managing multiple GUIs. When we have
multiple GUIs we cannot expect them to send update commands at
same time intervals because they experience different workload,
reside on different hardware and so on. So, once first GUI
sends request to the simulator to calculate new state, request
will be put on hold until last GUI sends same request.
Meanwhile any new communication from GUIs will be stored on
queue. When last GUI calls in entire queue is sent to the
simulator and new queue is started. So, game speed will be
dictated by the slowest GUI in the network.
I hope this clears a bit what I had in mind. croxis I expect
comments from you about this queuing system. Please read
carefully and if you find that something isn't particularly
clear, please, don't hesitate to ask.
I could edit the design document for spelling, grammar, etc., if you wish. I'll probably take a look at it once I get home.
I know we have some few set sizes, but im trying my hand on a random map generator (ill need one for another project, so may as well kill two birds with one stone, one very big stone)
What im interested in is what kind of tile resolution are we looking at. Right now I have it set as 1px = 1m, but that is waaaaaaay too granular, and anything beyond small maps takes too much memory. Im thinking every 10m is a single pixel, with a pixel corresponding to a point on the heightmap? If we have a standard 10km by 10km city, (this is the base size, it may vary) and a region as 100km x100km, it means a 100mp image for the heightmap, which, while still pretty big, should reduce the number of memory overruns I have.
It is silly to have the terrain resolution that small. 10x10m should be satisfactory.
I would suggest with sticking to base-2 lengths...slightly more memory efficient...and SC4 does it :D
Joe
Eventually the aim is to produce a game with graphics as good as what 5 would have had. I pixel representing ten metres would be a grand way not to do that. Terrain imo is one area Simcity 4 is very archaic compared to what is possible. The level of detail is essentially two triangles per tile. Very poor stuff, and something which should be improved in a successor. (perhaps for older pcs there could be an option for switching between level of detail amounts for terrain?)
I have seen video games with very realistic terrain, and putting aside the problem of graphics taking up game speed, a successor to 4 should have a good realistic terrain. OpenCity imo fails at this dismally, and i think that realistic terrain is integral to the graphical side of this project.
In Atocity as i only have the lite edition of Game Maker i don't even have terrain but it stands to reason that the smallest unit of terrain definition should be smaller than that used in 4 in a fully 3D game, or you'd get ugly affects like in OpenCity