drharris

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

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.

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.

As a professional programmer who has been to grad school for it, I'll wholeheartedly agree. You can spend 12 months getting a version 0.1 up and running in pure C, or you can get a slow but working 0.1 out in a few months with Python. Having 8-10 months to then inline some C to speed things up goes a long, long way to performance improvements. Inlining C code in python usually results in code that is about 95-98% as efficient as pure C, and using pure C for compiled modules shows little difference at all. A project's death is normally directly proportional to how long it takes to get that first working version up and running. Once you can see it in action, the rest is polish and maintenance. Using a higher level language gets you that first version much more quickly, and you can worry about performance when it actually becomes an issue. Premature optimization is a huge no-no in the development world, because it bogs down your development time with little reward in most cases. It's much better to run it slow, use profiling to determine where bottlenecks are, and then redesign those bottlenecks for performance. Iterate until it runs like butter. That said, simulations running outside realtime environments are notorious CPU hogs, and I think we'd find a lot of optimization will need to be done. But I still believe a higher level language is by far the way to go here. How many other community sim projects have failed because they try to get everything perfect before even writing a line of code? You have to get a playable version out quickly or your project dies.

I registered just for this thread. I'm a full-time programmer who is willing to help however I can (if this winds up being open source; not interested in another job), being a lover of sim games since the original SimCity. No good at 3d modeling or graphics, and I primarily use C#.NET, but I know most popular languages. At the very least, I can offer some advice, having been on about 5 open source game development projects that died quickly, one as quickly as 2 months in. Some things I've learned, take them or leave them... 1) Don't even attempt multiple platforms. Try to name one successful game that really has seamless multi-platform without a huge budget and a ton of developers. The only thing that can port somewhat seamlessly is your assets and engine code. Even in OpenGL there are so many OS-specific quirks it's not funny. Focus on a Windows release, and then worry about porting to other platforms (*nix, phones, etc.). Otherwise you will get so quickly bogged down in bug reports from various OSes you'll never be able to finish the game. 2) 3D is not worth it. All 5 projects I was on attempted full 3d. It's great in theory, but when you don't have 50 developers and 50 modelers working full time on it, you get bogged down within the first month. Go with 2.5D at the most. Sim games are primarily fun because of the creative Machiavellian aspects of gameplay, not realistic full-motion graphics. For those that like city walker/copter views, simply allow the save file format to be an open format. You'll be surprised what the game community comes up with; possibly a full-3d walking viewer application. Point is, 3d bogs down a version 1.0. Worry about that in the next version. 3) Focus on what's going to make the game fun, not necessarily realistic. I know that the temptation as sim lovers is to say "wouldn't it be so cool if ____ was more realistic?", but many times there is a very explicit reason the game designers chose not to do that (usually development time). First and foremost, you need a compelling concept. For example, Cities XL fails in many regards, but the concept of cities playing together is very compelling. It's sim lovers' nirvana to have cities interconnected, forming new countries, continents, and whole planets. Imagine micromanaging a whole galaxy! Point is, it's easy to get carried away, but you should have at least one major draw that nothing else has, and it should be addictive. For all SimCity's faults, we still play it often. 4) Do not design by committee. If you try to get everyone's input, and everyone's ideas implemented, you're going to wind up with a pile of junk. In the end, one person needs to design the entire thing. It sounds like you're doing well with such a large design document. Take things into consideration, but don't try to please everyone. You won't. Now, I'll offer some suggestions later, and feel free to scratch them! Design by committee is a good way to ensure nothing will get done. Overall, I love the idea of resources playing into things. I think SimCity has always been weak on Industry, especially in late game play. Resources create a draw for industry, which creates demand for residential, and then commercial, making industry more critical. Basing it around resources also opens up better possibilities for trade. I would also say that it would be cool to allow "prospecting" for new resources. Each resource type should be some sort of gradient in the city, which forces the user to choose zoning more carefully (what if you put some low income housing over a uranium mine you later discover?) I also like the idea of what someone mentioned about property. If resources help create cities, then property does as well (simply watch "How The States Were Made" on History channel). The idea of a city being limited to one small area and having to purchase additional property is a very good idea. Also, it would be interesting to model some sort of property value trending. For example, residential near coastline is more valuable than in the mountains. Commercial near major roads is more than smaller roads. So on, so forth, and it would be all behind-the-scenes. It also allows you to do things with "individual citizens" (the other sim lover's nirvana). For example, you might partition some residential along a coastline, but when property values increase and you don't have high tech yet, nobody is rich enough to afford it and it may go dormant (lack of residents make the nearby properties increase, which drive prices even further, and then it can never be afforded). Something to consider. Property is very important in city development, so it would be interesting to play on that theme at some level. As a C#/.NET developer, I have to mention XNA studio and framework. It has excellent porting capability between PC, Xbox, and Phone (windows). This opens up immediate avenues of revenue if you go that route, and AppHub gets you visibility for cheap. Sorry for the long post, and hope it helps. Again, willing to help if this turns into open source.