SimCity 4: New ways to push the game

[SUPERMESSI 294]

What is needed, seeing that CS:S is such a strong game, to push SC4 to the next level?

 

In my part, i really think that turning standard buildings in to MMP's (which can be turn in angles, diagonal, vertical, etc.) would give the game a new power. I also tend to think that, like the dragable paths, it would be possible to create some sort of dragable road (to allow building on curves). 

 

Do you agree Simtropolis?

[A Nonny Moose 8,261]

Already done from a different point of view.  The two files BldgProps_Vol1 and BldgProps_Vol2 are the SC4 buildings as props.  Both of these files are available in the Lot Editor download page. 

You can place any of these buildings in any lot configuration you like.  I would refrain from cluttering up the MMP with even more junk than is in there now.  Just create some new lots with the lot editor, and if you make them growable, you don't need to worry about menu entries.

I consider C:S a flash in the pan.  SC4 has been around for something close to 15 years in spite of many attempts to kill it.  It is probably one of the better if not best examples of state of the art programming for its time. 

The limits of the x86 paradigm have been reached and it would appear from doing a little research that increasing bandwidth (128 bit) won't be an improvement.  The coupling problems with chip components are the problem, and things are coming to Peter's Pretty Pass.  I have suggested a new architectural approach in another thread that is, essentially, a throwback to more advanced technology that exists in some main frames since the 1950s.  The era of the single bus PC has gone to the end of its capability.

[SUPERMESSI 294]

Already done from a different point of view.  The two files BldgProps_Vol1 and BldgProps_Vol2 are the SC4 buildings as props.  Both of these files are available in the Lot Editor download page. 

You can place any of these buildings in any lot configuration you like.  I would refrain from cluttering up the MMP with even more junk than is in there now.  Just create some new lots with the lot editor, and if you make them growable, you don't need to worry about menu entries.

I consider C:S a flash in the pan.  SC4 has been around for something close to 15 years in spite of many attempts to kill it.  It is probably one of the better if not best examples of state of the art programming for its time. 

The limits of the x86 paradigm have been reached and it would appear from doing a little research that increasing bandwidth (128 bit) won't be an improvement.  The coupling problems with chip components are the problem, and things are coming to Peter's Pretty Pass.  I have suggested a new architectural approach in another thread that is, essentially, a throwback to more advanced technology that exists in some main frames since the 1950s.  The era of the single bus PC has gone to the end of its capability.

Nonny Moose thanks for the answer, but i am not sure that i've understand the technical aspects, specially the last paragraph.

 

But thanks for the suggestions regarding the Maxis buildings. I would prefer other buildings (is there any way that i can take a specific BAT and turn it into a prop, in order to transform it into a MMP and be able to rotate it in degrees?), but it is something

 

Sorry for being a $%&^!

[A Nonny Moose 8,261]

If you have the BAT's components, specifically the model, you can take it into PIM or PIM-X assign properties to it, then take it into the lot editor and do what you like.  Unfortunately, you do have to have the *.sc4model file which often comes in a distribution.  I suppose it might be possible to dig it out using the Reader or some other piece of software.  I am not aware of any, but I haven't made any BATs since 2006 and have not really kept up on the current technology.

I suppose if it comes compressed in a *.dat you might be able to dig it out easier.  I know of no tool to decompress at *.dat.

[Linoa06 1,374]

I don't agree..SC4 is SC4, it will be hard to mod it to CSL level but at the same time it's got good strengths unseen in the later 3D games.. So quite honestly it feels pointless.

[A Nonny Moose 8,261]

Well, you see, some people who don't know a diamond when they see it are bamboozled by the glitter of 3D and a free camera.  Will Wright himself said they had "programmed themselves into a corner" which I've always taken to mean that they've taken the technology of stochastic simulations to the point of being NP complete.  That means that the game is totally unsolvable in the long run.

I've been doing some digging on the single bus PC architecture and it appears that the 32-bit architecture of the x86 model is about as far as they will be able to go with present technology with respect to happenings in a microchip.  The CPU/single clock centred architecture has reached its ultimate position without a serious breakthrough in modern circuitry that remains affordable for the consumer.  This is why they've gone to multi-core systems now:  Multi-cores give an illusion of faster, but in fact, they are no faster than a single core, but you can run multiple tasks simultaneously if you can handle the resource conflicts.  I've yet to meet many programmers who can get their mind around the need for critical section routines in an ordinary application.  This is the field of operating system people.

A lot of lip-service has been given to multi-tasking, but when it comes to really doing it, many just find that they can't.  This kind of code not only has to be bullet proof, it has to be ID 10 T proof as well.  Just getting out of a deadly embrace or a race condition with acceptable timing and good recovery is often beyond many programmers.  The only place I've ever seen this done effectively is in two transaction processing systems that I have used.  In both cases, extensive journalization was necessary, and sometimes even that required a system restart for complete recovery.  It is amazing how quickly a journal can eat up a storage device, and arrangements need to be made to switch and spill these frequently.  Not really a thing you can do in a game.

AE has done a lot of work on this in his current effort building Citybound.  His solution is one of the simpler ones, but it is very elegant at the same time.  His most recent post discusses this.

To get more oomph out of SC4, it would have to be overhauled to multitask safely.  A lot of analysis would have to go into dividing up the simulation into even more tasks than it has now.  Certainly the main simulation and the path finder would be core tasks, and the graphics display would have to be firmly wished off on a mandatory GPU with large on-board memory.  This would shut out many current players because they'd need a truly modern, big gaming box for this.  The journalization alone might very well eat a 1 TB storage device, and then some, very quickly, but the advantage would be that you could have multiple users in the same city.  It would, in effect, become a transaction processing system.  In such a system, each of the Advisers could become a player, with responsibility for their department, and reporting to the Mayor.  A whole different ball of wax.  For example, with the consent of the Mayor (and council) the education advisor would build and control the schools.

You wanted something extending the present system?  Well, it can be done but you'd need a server where the program ran and the PCs would be terminals.  The chances are that the server would be a mainframe.  Someone (EA) would have to find the capital for this.  Since they've been burned already, I wouldn't expect them to jump in this fire again.  Fun, huh?

[Mister Giggles 310]

Multi-threading back in your day and multi-threading now are two different beasts. Many modern games are multi-threaded and run fine on 2-8+ cores, no super computers needed.

  Edited October 10, 2015 by Mister Giggles  

[A Nonny Moose 8,261]

And is the multitasking done by the O/S or by the game?  In "my day" it had to be handled by the application because the O/S had its hands full managing the processors.

A single player multi-tasked game can easily be handled by the processor scheduler in the O/S, and the only real problem is the Interprocess Communication system (IPC).  This system I am using has at least three such mechanisms built into the kernel.  Kernels are very much larger and far more secure now than they were when a big machine had only 1 MB of memory for both the application and the O/S.  This machine has 4 GB, and the kernel is paged in rings 0 and 1.  The whole hardware view is quite different.  In the bad old days we didn't have hardware paging.  This box has hardware segmentation as well as paging.

Where life gets dicey and needs a server with very fast CPUs is when you go MMP.  With many players simultaneously life gets pretty interesting.  Deadlock avoidance and recovery needs a lot of gear.

[cogeo 960]

Windows handles multitasking properly, since the very early versions of Windows NT. It does allow running tasks concurrently, and will give applications more than one cores or CPUs if they are available, and the application runs more than one thread, or instead will use time-slicing if there are more active threads (of the same priority level) than CPUs, requesting CPU time. This is of course transparent to the application, which should not assume availability (or not) of any number of processors.

SC4 creates a big number of threads (just check the Task Manager). Now what could be run simultaneously (to take advantage of the architecture), is beyond me, it all depends on the implementation they have chosen. Simulation may (or "should") rather not, maybe they could run all simulation in one thread only, and have the others handling the user interaction, the graphics etc etc, but who knows. Fact is that their implementation obviously has problems, as you can see high CPU utilization even if you stop simulating your city, only for having the application loaded. Not to mention that players have reported that you have to set CPUcount in the command-line to... 1, or else risk crashes. You can't have concurrent processing with only 1 CPU (or core).

Quite weird, why have the application creating so many threads then? It's obvious that they never tested the application thoroughly enough, under a multi-processor system (or tested it, saw that it wasn't working well, but rushed the game's release(s), possibly planning to fix these at some later patch, which they never did - just put the CPUcount option for players which really used multi-CPU/core computers and had troubles; my speculation, but who really knows?)..It's not that no multi-core CPUs existed by the time. There were no multi-core CPUs, but there were multi-CPU boards, Windows could use them (and as mentioned above, indeed allot multiple CPUs to an application) and they were not really supercomputers, actually quite affordable. And it's harder to make a multi-threaded application running correctly on a multi-CPU system rather than on a multi-core one. The reason is that CPUs have (internal) cache memory, and the data they are working on may actually be in their cache; so, if the application does not use synchronization objects properly, each CPUs may "see" a different copy of the (same) data. This does not happen in a multi-core CPU (the same cache is used by all cores). That is, if a multi-threaded application runs correctly on a multi-CPU system, it should run on a multi-core one too (while the reverse is not necessarily true). This means that SC4 most probably never employed parallel processing correctly.

 

And SUPERMESSI, the features you are asking for are not possible to be implemented in SC4, and the reason is the graphics engine. BATs have only four aspect views (North, East, South, West), and lack "full geometry"  - they are made to be viewed only from a certain angle and viewpoint. The game is NOT truly 3D. Changing this would require changing the application itself.

  Edited October 10, 2015 by cogeo  

[rsc204 21,808]

Some good points there Coego.

I would add, whilst Multi-CPU systems existed back when SC4 was developed, they were rarely used outside of business and Windows 9x would hardly be able to gain any performance benefits from using one. That meant running NT or Win2000, whist the later gained some traction in the consumer market (very stable compared to previous editions), NT 4.0 most certainly did not. In fact at this time, getting any consumer-grade equipment with drivers or support for Win 2000 was quite a difficult task, you had to be very careful. Most games were also not coded to run under an NT environment until WinXP merged the NT kernel into the consumer versions. In that respect, it's not really reasonable to have expected Maxis to anticipate or support any sort of multi-threaded environment. I'm not even sure the HT P4's were being sold when the game was released.

[A Nonny Moose 8,261]

I did experiment with allowing SC4 to multiprocess.  It generally crashes quite soon.  What I suspect is that they used a technique called co-routines which were quite popular at the time.  Something clearly goes wrong, and the program does its usual trick of giving up the ghost.  Not much recovery code in this program at all.  However, my system monitor showed the program running at 60% which means it was in fact using two processors since one fully loaded processor shows up as 50% in that particular monitor program.

A program that, using C terminology, does a simple fork statement just makes a copy of itself and kicks off a new process.  What that child process does then is up to it, but it should have some indication of what its sub-task is, and should drop anything it doesn't need.  How it does interprocess communication with its parent is up to whatever mechanism has been set up (often shared memory, which must be gated with semaphores to prevent unforeseen double updates).  The techniques for IPC are not difficult, but have to be small, very fast and well debugged.  Certainly on a UNI*-style system another option is the use of named pipes, which might be easier.  Proper rendezvous code is needed when the child terminates, if it does.  C++ has a whole section of documentation and calls to cover deadlocks and such, but I don't think this was in the standard at the time this game was written.  The overhead for this is large, but with today's systems that is not particularly significant.