Still around people

[croxis 150]

If you call selecting a region something worth playing At least it has multiplayer LOL!

[Nique 291]

If you call selecting a region something worth playing At least it has multiplayer LOL!

Haha, well there is something visible It is a result.

[Buggi 685]

There are issues with opening the project up to all. First no major company would then touch it with a ten foot pole, and second is the people factor. How many projects have been started and died for any reason? Even we, as a dedicated community, haven't produced anything along the lines of a clone. (I look at the OpenTTD community as an example.) So how could we manage to produce a full on new project with multithreading and all the render tricks used in todays games.

Yes I want to make a beautiful game, as beautiful as SC4 and more. I wanted there to be a real day-night cycle which would require real-time shadows and lighting effects. I wanted to really give cities and their buildings as many options for real awesomeness as possible.

Talking about development language and the like is so far ahead of where I'm at right now. The design should be locked in before development starts so all the variables are known and the coding doesn't need any patchwork down the road because of tacked on features.

[Nique 291]

Just wanted to say that using c++ with the panda3d sdk is no problem at all:

[code]#include "pandaFramework.h" #include "pandaSystem.h" PandaFramework framework; WindowFramework *window; int main(int argc, char *argv[]) { // Open framework framework.open_framework(argc, argv); // Set Window properties WindowProperties *props = new WindowProperties(); props->set_size(1280,720); props->set_fixed_size(true); props->set_title("CityMania"); // Open Window (and delete props) window = framework.open_window(*props,0); delete props; // Start main loop framework.main_loop(); // Close framework framework.close_framework(); return (0); }[/code]

Add a PandaSettings.vsprops (for Visual Studio 2008) file to the project and it works like a charm!

[code] <?xml version="1.0" encoding="Windows-1252"?> <VisualStudioPropertySheet ProjectType="Visual C++" Version="8.00" Name="PandaSettings"> <Tool Name="VCCLCompilerTool" AdditionalIncludeDirectories="&quot;D:\Development\Tools\Panda3D-1.7.2\python\include&quot;;&quot;D:\Development\Tools\Panda3D-1.7.2\include&quot;" /> <Tool Name="VCLinkerTool" AdditionalDependencies="libp3framework.lib libpanda.lib libpandafx.lib libpandaexpress.lib libp3dtool.lib libp3dtoolconfig.lib libp3pystub.lib libp3direct.lib" AdditionalLibraryDirectories="&quot;D:\Development\Tools\Panda3D-1.7.2\python\libs&quot;;&quot;D:\Development\Tools\Panda3D-1.7.2\lib&quot;" /> </VisualStudioPropertySheet> [/code]

  Edited August 13, 2011 by Nique  

[catty-cb 4,412]

There are issues with opening the project up to all. First no major company would then touch it with a ten foot pole, and second is the people factor. How many projects have been started and died for any reason? Even we, as a dedicated community, haven't produced anything along the lines of a clone. (I look at the OpenTTD community as an example.) So how could we manage to produce a full on new project with multithreading and all the render tricks used in todays games.

Yes I want to make a beautiful game, as beautiful as SC4 and more. I wanted there to be a real day-night cycle which would require real-time shadows and lighting effects. I wanted to really give cities and their buildings as many options for real awesomeness as possible.

Talking about development language and the like is so far ahead of where I'm at right now. The design should be locked in before development starts so all the variables are known and the coding doesn't need any patchwork down the road because of tacked on features.

I think you should visit the "Metropolis Project"

The Metropolis Project is a community-controlled non-profit organization dedicated to creating an open-source urban simulation game called Metropolis. We are hoping to create a next-generation successor to the ground-breaking Sim City series.

link to website http://themetropolisproject.org/

and also http://themetropolisproject.org/forums/game-design

[A Nonny Moose 8,262]

As a professional programmer myself, I tend to agree that getting something out on the market quickly is a good thing. However, such a 0.1 version must clearly be so labeled, and among other things, it must not crash. It must also perform as specified, speed notwithstanding.

I have overseen and implemented several commercial projects, and none of them were allowed to bring down a system without good reason. In one case I can think of quickly, a system came down because insufficient space had been allocated for a growing data base when the actual volumes were unknown at the time of first implementation. This system did not crash but did an orderly shutdown on getting a refusal from the data base segment, with full diagnostic of the problem. It was back up the next day with proper allocations, and watched carefully thereafter. All data were recovered.

Of some interest to high level language lovers, of which I am one, the system was written in COBOL. It was about five times faster than its predecessor which ran on a different machine with a different data base. We subsequently wrote a B+ tree version of the data base segment which was 100 times faster than the one in the first implementation. Unfortunately, we had to go to assembly language with operating system incest to do this. We kept the previous interface from COBOL, so it was a plug-and-play switch over. The time frame for this was myself and two expert assembly programmers for about a year. Both of the programmers had doctorates in mathematics.

My main objection to higher level languages is the associated overheads that come with packaged routines. In a simulation environment, this has to be cut to the bone. Multi-processing is a must, and the simplest mechanism is the C fork verb. Once you establish your child processes, it becomes a matter of rendezvous (synchronization) management and some critical section processing. There does come a time when if you want to go really fast you have to get down on the iron and scratch. Even with full optimization and embedding programmers need to be aware of the code being generated. I think there are few these days who can do real assembler reading and understanding.

The other thing that slows projects down considerably is the idea that a large team can do this efficiently. You can't make a baby in one month by thowing nine women at it, and you can't reduce a ten year project to one year by throwing ten men at it. In an open source situation with no particular time frame, you might get away with this. A commercial project can never be done this way. The Chief Programmer Team concept remains the best for this with a well-controlled hierarchy. A full specification review and amendment process must also exist. Takes time, but you get a quality job. It also costs the earth.

EDIT: I nearly forgot. Manufacturing principles apply. Zero defects! Do it right the first time.

  Edited August 12, 2011 by A Nonny Moose  

[croxis 150]

Open ttd is an interesting example actually. If memory serves what happens was that one person reversed engineered the ttd executable and released his source code. What happed was the community project of open ttd had t heir version 0.1 from day one.

Like I said I never worked for a company as a coder, but it sounds like a fundamentally different philosophy is needed, kind of like

like the scrum model.

[A Nonny Moose 8,262]

I've never seen a coder in my entire career. Most people who wrote code in my day were also analysts. The production lab in our company hired only programmer/analysts for programming projects. Most were either Math or Physics grads. There was a lot more money in programming in those days than in math or physics-related jobs.

I can't image following someone else's documentation slavishly to produce code. Sounds like a good way to embed trapdoors in the code.

[drharris 3]

I think you should visit the "Metropolis Project"

This looks really interesting (and a good compromise between FOSS and "getting it built"). However, one things that sticks out is the fact that the blog posts started almost 2 years ago. So, for 2 whole years they've been talking about how things will be, and never actually getting started on it. So by the time they launch "phase 1", it will be about 5 years down the road, assuming they ever launch. That's the problem with a donation approach - you need that initial money to hire developers. Alternatively, they could go with community development immediately, get a launchable product, and then ask for donations to hire full time developers to make it into a full game. It's an interesting idea, and I'd certainly pledge some money if it looks like they'll actually do it... but for now, it looks like just a lot of sim lovers talking about what would be really cool.

[NBAFAN1 28]

There are issues with opening the project up to all. First no major company would then touch it with a ten foot pole, and second is the people factor. How many projects have been started and died for any reason? Even we, as a dedicated community, haven't produced anything along the lines of a clone. (I look at the OpenTTD community as an example.) So how could we manage to produce a full on new project with multithreading and all the render tricks used in todays games.

Yes I want to make a beautiful game, as beautiful as SC4 and more. I wanted there to be a real day-night cycle which would require real-time shadows and lighting effects. I wanted to really give cities and their buildings as many options for real awesomeness as possible.

Talking about development language and the like is so far ahead of where I'm at right now. The design should be locked in before development starts so all the variables are known and the coding doesn't need any patchwork down the road because of tacked on features.

Have you thought of asking Paradox Interactive? They are a PC game company that makes niche strategy games. They have published a lot of games from small newly started developers too.
  Edited August 12, 2011 by NBAFAN1  

[croxis 150]

To veer off topic on there community project, the more I think about it the more I wonder if a sc4 clone would be the best option. Too much time is spent on discussion of "TEH BEST GAMZ EVAR!" If the project was locked to recreating the engine with compatibility with existing assets the discussion immediately jumps to technical implementation. That and much of the design work is already done as the modding community has done a great job understanding how the engine works.

[A Nonny Moose 8,262]

By the time this gets as far as "The Best Game Ever" specification, I expect I will have shuffled off this mortal coil. My 74th birthday is next month, and there is too much batting of gums and not enough specification documentation. C'mon guys, make a cut, and let's get going.

Do we even have a proposal outline?

[TheHaso2011 152]

Moose: How do you have time to Send all these messages. One Second your Sending messages to the RSA the next to this thread. How?

[Nique 291]

Moose: How do you have time to Send all these messages. One Second your Sending messages to the RSA the next to this thread. How?

Is that really important . If you type fast you can reply on 10 topics in 1 minute.

[Jamesrules90 133]

Nope you can post on one topic a minute due to the 60 second post limit. The admins put in something so we have to wait 60 seconds before making post after another.

[Nique 291]

Well i don't care, please man, its completely off-topic.

[Buggi 685]

Another reason to have the game in 3D is to allow animations much easier. Oil derrik's pumping, elevators up-and-downing... :/

Roller coasters coasting... General machinery moving...

@_@

Anyway, something to think about.

Also, I missed a resource type earlier, there is one called "DRILL" for those resources that are used but dont cover the used area with a lot. Meaning the area of effect on the resource does not equal the area covered by the lot.

I know it would be a lot of work to manually do different LOD's for the buildings as well as use the special maps (like normal maps) but in the long run it would allow the most expandability with out needing a rewrite. So in case another 10 years go by without a new version my version will have staying power.

[A Nonny Moose 8,262]

Buggi, how about consolidating all this in a PDF? If you need a host, I could put it on my private web pages.

[croxis 150]

Another interesting thing about sc4 2.5d vs full 3d. SC4 rendered the scene to an off screen buffer. When the camera moved it would actually take the buffer bitmap, pan it, and then rendered the new view, instead of fully redrawing each frame. Offscreen buffers are now really common in game engines as they move away from fixed function pipelines to using shaders for everything. Shaders do offer quite a bit of customizable power that can scale based on hardware levels. It can also offer an unprecedented level of visual feedback to the player.

  Edited August 16, 2011 by croxis  

[Dannibee 138]

Personally I think half the reason why these projects never get very far is because of how many different games there are. If everybody just got together to do one huge project with all the community like the Metropolis and Synekism people we could create something truly magnificent, it would have to be organized though, because at the moment we've got about 7 different teams essentially making the same game...

[Nique 291]

Thats why we want to merge

[jacksunny 741]

If there was a merge, what would happen to the games these groups have already created? I don't think they would just give up all their hard work and basically start over.

[A Nonny Moose 8,262]

You know, we could proceed the same way that ARPAnet was created. First we put together a set of Requests for Comment (RFCs) with a time limit on each, then have them reviewed after comment by an editorial group to thrash out a draft specification for each part, then go from there into DFD's and other construction tools as needed. Two main specifications will be important: The internal interface to all modules, and the graphics specification. Think of the POSIX standard as an example. This phase could easily take two to three years if you are going to the world-wide community. It may be necessary to have some documents translated professionally for some reviewers.

I have done some standards work both in the CSA and with ISO. This is a long haul, and has to be done very, very carefully with gentle massaging of individual wants to reach an acceptable compromise. Evenutally we'd get a very high quality product. Initial versions could be released to the development group and selected testers as the product becomes runnable, and tuning can go from there. I see a horizon of about 10 years.

If this becomes an open source project, we might seek help from the Free Software Foundation.

[Buggi 685]

10 years? I don't have that kind of energy. Plus I have all the features already spec'd out in my design.

Problem is I don't have it in digital format yet. My computer died awhile ago and I'm typing these posts in the library. Remember the entire design is hand written, so much work will need to be done for me to convert the text and (especially) the diagrams. And my version of photoshop is ancient.

So, truth be told I don't have the tools to get it to that point right now and am finding it hard to get enough money for next months rent let alone a new computer and all the trimmings.

So maybe I posted too prematurely. But I am excited about the design and really want to go forward with it.

As a side note, does anyone know how the terrain in SC4 is stored? What the data structure looks like, for example. And a breakdown of the bytes per square that can be assumed for future terrain modeling. My design has a terrain model that depends on a large piece of terrain that is only broken down into sections internally to speed up rendering, otherwise the user sees just a large piece of terrain. The thing that controls what is available to build on is a City border system that I have fully designed. It would be nice to know how the terrain can be LOD'd out at mid-high draw distances.

As you can tell, I have features spec'd out that require a little problem solving on the technical end that I don't have the experience or expertise to find a solution. (Diagrams would go a long way in helping illustrate my design... damn computer.)

And if I were to make a decision on language and core, I would honestly go with C++, with C# tools because it's what I know and it has such a huge amount of support. I would target windows 7 and higher, with "LITE" versions for tablet and mobile systems as the community wants them. It would be nice to create a client-server system for a single person to install the game on their system and have it running at home while they are at work and allow them to log in via their phone or web-page and update or change their game. I would, as project lead, head the server side of the coin, leaving the specs for the community to create the client tools they prefer. The server side would basically be loading a region and city, and running the game without a renderer, opening the data to clients. And it would also allow other people to "log in" to your city and look around without having the rights to change anything.

[drharris 3]

And if I were to make a decision on language and core, I would honestly go with C++, with C# tools because it's what I know and it has such a huge amount of support. I would target windows 7 and higher, with "LITE" versions for tablet and mobile systems as the community wants them. It would be nice to create a client-server system for a single person to install the game on their system and have it running at home while they are at work and allow them to log in via their phone or web-page and update or change their game. I would, as project lead, head the server side of the coin, leaving the specs for the community to create the client tools they prefer. The server side would basically be loading a region and city, and running the game without a renderer, opening the data to clients. And it would also allow other people to "log in" to your city and look around without having the rights to change anything.

Though I'm an advocate of C# and XNA, I can definitely see the reason for primarily C++. If most of the game logic is encapsulated in C++ libraries, you can easily wrap those for any phone, tablet, or computer platform. It's never seamless on the presentation end, but it means not rewriting a lot of internal code for simulation.

Instead of client/server model, have you considered a Peer to Peer network for the multiplayer? I did an experiment on P2P gaming in undergrad, building on top of DirectConnect at the time (horribly slow, too much for a real game, but fine for poker). Better protocols exist today (NodeJS would be an interesting option), but the main takeaway is that every player is both a client and server. Each city would, in effect, be its own server. Use public key encryption to keep things safe and you're good to go. This also allows you to do things like run your city during the day, and keep an eye on it from work or phone. The multiplayer code then becomes simple negotiation between multiple clients and servers. I say simple, but it's really not; you have a lot of NAT issues to overcome with this. But most P2P protocols can easily provide good functionality out of the box. Just something to consider. Sometimes, "running a server" is a complicated idea for a player, and it doesn't have to be if everyone's both a server and a client.

[Jazzmaster 716]

Another reason to have the game in 3D is to allow animations much easier. Oil derrik's pumping, elevators up-and-downing... :/

Roller coasters coasting... General machinery moving...

There's no earthly way of knowing,

Which direction we are going,

There's no knowing where we're rowing,

Or which way the river's flowing,

Is it raining? Is it snowing? Is a hurricane a-blowing?

Not a speck of light is showing so the danger must be growing,

Are the fires of hell A-glowing? Is the grisly reaper mowing?

YES! The danger must be growing, for the rowers keep on rowing,

And they're certainly not showing, any signs that they are slowing!!!

Heh, sorry, could not resist.

[A Nonny Moose 8,262]

Buggi, from your last post I take it that you are either underemployed or unemployed. I've been there and done that when the large-scale business in Canada fell into the black hole of the PC. In the end, I wound up teaching computer science part time. I never held a full time job after 1990, so I understand your situation. I hope you don't have any immediate dependents. I had two kids in college. Best of luck with getting something soon.

Just a note on your next machine. Do not get Photoshop. It is too damned much money. Download the GIMP (free). It is essentially a drop in replacement for Photoshop, and don't forget to pull in the animation package (GAP) and the tutorial (Grokking the GIMP).

[croxis 150]

10 years? I don't have that kind of energy. Plus I have all the features already spec'd out in my design.

Problem is I don't have it in digital format yet. My computer died awhile ago and I'm typing these posts in the library. Remember the entire design is hand written, so much work will need to be done for me to convert the text and (especially) the diagrams. And my version of photoshop is ancient.

So, truth be told I don't have the tools to get it to that point right now and am finding it hard to get enough money for next months rent let alone a new computer and all the trimmings.

So maybe I posted too prematurely. But I am excited about the design and really want to go forward with it.

As a side note, does anyone know how the terrain in SC4 is stored? What the data structure looks like, for example. And a breakdown of the bytes per square that can be assumed for future terrain modeling. My design has a terrain model that depends on a large piece of terrain that is only broken down into sections internally to speed up rendering, otherwise the user sees just a large piece of terrain. The thing that controls what is available to build on is a City border system that I have fully designed. It would be nice to know how the terrain can be LOD'd out at mid-high draw distances.

As you can tell, I have features spec'd out that require a little problem solving on the technical end that I don't have the experience or expertise to find a solution. (Diagrams would go a long way in helping illustrate my design... damn computer.)

And if I were to make a decision on language and core, I would honestly go with C++, with C# tools because it's what I know and it has such a huge amount of support. I would target windows 7 and higher, with "LITE" versions for tablet and mobile systems as the community wants them. It would be nice to create a client-server system for a single person to install the game on their system and have it running at home while they are at work and allow them to log in via their phone or web-page and update or change their game. I would, as project lead, head the server side of the coin, leaving the specs for the community to create the client tools they prefer. The server side would basically be loading a region and city, and running the game without a renderer, opening the data to clients. And it would also allow other people to "log in" to your city and look around without having the rights to change anything.

I'm not sure how sc4 does the region data, but the tile method is obviously the way to go for large scale "infinite" terrain. My suggestion is investigate GeoMipMap, which itself can be tiled. There is also geo clip maps. There is also the Virtual Terrain resource if you havent discovered it yet, specifically the papers section.

I would go so far as to require a DX11/OpenGL4 card. Going full 3d will need not just raw gpu muscle, but also the latest in shader tech, such as Compute shaders. This is a dev blog on how DX11 is used to render terrain.

Though I'm an advocate of C# and XNA, I can definitely see the reason for primarily C++. If most of the game logic is encapsulated in C++ libraries, you can easily wrap those for any phone, tablet, or computer platform. It's never seamless on the presentation end, but it means not rewriting a lot of internal code for simulation.

Instead of client/server model, have you considered a Peer to Peer network for the multiplayer? I did an experiment on P2P gaming in undergrad, building on top of DirectConnect at the time (horribly slow, too much for a real game, but fine for poker). Better protocols exist today (NodeJS would be an interesting option), but the main takeaway is that every player is both a client and server. Each city would, in effect, be its own server. Use public key encryption to keep things safe and you're good to go. This also allows you to do things like run your city during the day, and keep an eye on it from work or phone. The multiplayer code then becomes simple negotiation between multiple clients and servers. I say simple, but it's really not; you have a lot of NAT issues to overcome with this. But most P2P protocols can easily provide good functionality out of the box. Just something to consider. Sometimes, "running a server" is a complicated idea for a player, and it doesn't have to be if everyone's both a server and a client.

My understanding of p2p is that it is difficult to design to join "mid game" as it would require the entire state to be synced. By using a standard client/server the new client only needs to be sent chunks of the state on an as needed basis. C/S also allows for more divergent hardware specs. I do not see my 1GHz ARM phone keeping up with my game running on a quad core, which is what it will have to do on a p2p system. Running a server can be as easy as hosting a mp game from inside the client, which is what has been done for years, to running it on a headless machine (to which linux support becomes important imho).

[drharris 3]

My understanding of p2p is that it is difficult to design to join "mid game" as it would require the entire state to be synced. By using a standard client/server the new client only needs to be sent chunks of the state on an as needed basis. C/S also allows for more divergent hardware specs. I do not see my 1GHz ARM phone keeping up with my game running on a quad core, which is what it will have to do on a p2p system. Running a server can be as easy as hosting a mp game from inside the client, which is what has been done for years, to running it on a headless machine (to which linux support becomes important imho).

It depends on how you have it set up. Any node in any p2p system can be contributing fully, partially, or just viewing things. If you have 3 full PCs and one phone, there's no reason the heavy lifting can't be shared between the 3 PCs and the phone simply receives game state. My work involved card games, which provide a great state model; you can send a simple changeset between hands, and the turn based helps. But I feel it would scale into simulation building ok. Also keep in mind you can use a hybrid model to increase server scalability. This especially holds true if you're providing a main server for the application itself; the server (or tracker) can negotiate both the initial connection and the passing of game state.

For example, if node A sends game state to node B directly, B can then pass a hash code to the server/tracker, and ask "is this game state change valid?" The server responds yes or no, and the client then incorporates it. This prevents cheating by implementing a trusted 3rd party for verification. Once a level of trust is established you can reduce these requests. Joining Mid-game would not be any more difficult; you can simply request the current state from all the existing players. You don't need to know initial or historical states, just where it is now. Since you have multiple nodes able to provide this data, it keeps the server from having to handle so many responsibilities. The game itself takes place on the distributed clients; the server or tracker is left to simple negotiation. It would be possible to distribute this functionality as well (think DHT in bittorrent).

Here is a good paper on these types of challenges: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.2662&rep=rep1&type=pdf

[Vahr 343]

Buggi, I do believe that SC4 stores the terrain as an array of Z (vertical) values (Float32,Float32,Float32,...). Terrain texture mappings are generated at runtime according to the terrain texture INI and exemplars.