Simcity Classic clone / work alike: anyone interested in helping develop?

ironically, I've got a partially done mockup of a city builder sitting on my PC, though like you, I want to have the device in hand to mess with. It's the sort of time-waster game that the day-long battery life was built for. :P

...you could even add an RTC backpack to keep track of the time so you city continues to grow (or decay...) when the console is off *__*

Pretty cool project :)

Well since you have to build to grow having it "grow while you sleep" wouldn't really do much... it would grow a bit and then eventually reach each a state of equilibrium...  I presume you wouldn't want storms and fires to destroy your city while you slept... so the basic eb and flow would even out over time to really be meaningless.

That would be totally kick ass for a slightly different type of game though.  And you could potentially do it even without a RTC - one of the first things I want to do is see how long the battery lasts with the CPU and screen in "sleep" mode... days? A week?  Depending on how you've wired things that could potentially be quite a long time.

Found it and fired it up.  This is 128x128 and in the PICO palette though.  I imagine we'd use RGB565 unless someone volunteered and really wanted to do the graphics in the Gamebuino Palette.  Not sure what that would look like.  You can see the PICO8 palette wasn't what I'd call perfect.

I thought about the backpack idea for the sake of RAM, but hadn't thought about using an RTC with it.... Hadn't thought about an RTC module at all, actually... right, goanna just... file that away in parts to get...

I'd been messing with the GB palette (in Paint of all things) to make mine. I was messing with the Sim City 2000 Isometric type layout, though how practical that'd be is hard to say.

I found it fun on the Pico-8 with only a 64x32 grid.   That's only 2kb with a 16-bit tileset.  100x100 would be 10 or 20kb.  With 8x8 tiles that's a 800x800 pixel city.  Simcity 2000 would obviously be harder to pull off graphically.  No idea on guesses until i run some benchmarks on the actual hardware and rendering.

I found an article saying that Simcity Classis (on SNES) was only 120x100. http://incise.org/advanced-sim-city-strategies.html

and the SNES was not exactly flush with RAM or anything, so it's quite doable.

You can probably do everything in a 8bits tileset with conditionals. Remember each lot is going to be 3x3 to thats 9 "variables" of 8bits each for each big building.

In fact I'd say its doable with less than 8 bits too.

I had some time to think about this, and here's a quick draft of what I mean.

Each tile has a 4 bits id:

0 ground

1 forest

2 beach

3 water

4 rubble

5 park

6 road

7 rail

8 bridge

9 tunnel (train)

10 electric line

11 electric line over road

12 electric line over rail

13 electric line over water

14 rail-road crossing

15 building

It fits exactly for all the single tile things we need… I have a feeling the original Sim City might have been done that way.

Alright, so now, when we encounter the building id, something interesting happens. We know that a building is at least 3x3 tiles in size, so when we encounter one, we read all the other tile values from that 3x3 square and we get 8x4=32 bits of information. That’s a LOT of info. From there, there’s many ways to go, that number of bits is big enough that we could just have a BIG lookup table for the images and building info. That would be fast, but it would also mean a lot of code to handle what does what. It might be better to partition the data into several lookup tables (residential, commercial, etc.) or into a specialized binary tree. So, we can read the data of the next tile (or the next two tiles for a 8 bits index, whatever seems the best) in the 3x3 grid and get some more info on our building:

0 residential

1 commercial

3 industrial

4 city service

5 special building

6 4x4 big building

7 5x5 very big building

8. Etc…

Now, again, if its for example residential, we read the next tile:

0 houses low

1 houses mid

2 houses upper

3 houses high

4 building low

5 building mid

6 building upper

7 building high

8 super-high super-special building that merges with its neighbors

Now read the next 4 bits tile again:

0 level 1 building

1 level 2 building

2 level 3 building

3 level 4 building

4 level 5 building

5 etc…

Alternatively, if we have houses, we read the next 8 bits and we get the position of the houses in a circle around the R in the center of the building (01101010).

We can keep the state of every building in there with lots of room to spare (technically, a 5x5 building has 24x4=96 bits of info). We can, for example,  store the position of the airplane(s) directly in the airport tile using a pointer. Same with the boat and train.

Now, when comes the time for rendering, we will need a bool buffer that is somewhat wider than the area on screen, and with the height of the maximum building size (here 5). Each time we have drawn a building, we set all its tiles to true in the buffer, so we know not to read them again, and we draw accordingly.

This means that we can technically have a HUGE city, with little RAM usage (100x100x4bits = 5k), we could go twice as big and still have RAM to spare even using a 160x128 display buffer at 4 bits / 16 colors.

It might also be worth investigating how it was done in the original Sim City, it ran on systems similar in specs to the Gamebuino Meta...

so when we encounter one, we read all the other tile values from that 3x3 square and we get 8x4=32 bits of information.

It's not that simple though.  Building's aren't guaranteed to be in a 3x3 or 4x4 (stadium)... the original Simcity allowed for individual tiles to be bulldozed or set on fire... and then other things built on top.  It used the "middle" tile for statistical purposes as far as I can tell.  If the middle tile of your police station was all that's left and you bulldoze it will "rebuild" eventually... but if you lose the middle tile you no longer have a police station at all - even if you have 90% of one.

So 66% of your Residential could burn/be bulldozed and you could build two more on "top" (well to the sides)... now you have "three" residential in a 7x3 block vs 9x3... 

I kind of see what you're going for by storing "blocks" (3x3), but I'm not sure that helps you as much as you think if you truly want the same "each block can be 100% independent" behavior of the original.

Of course one could imagine a different engine with different block behavior that simplified some of these problems (perhaps you can't bulldoze part of a block, etc.)

In the Picocity I did do creative stuff like have an "industrial" tileset that the game used creative to build 5-6 different "3x3 industrials" from the same exactly 8x8 graphic tiles.  (because of how limited the sprite resources are on Pico8)  So it looked like you had 6 different types of industry but they were all generated from a much narrower tiles.

Bulldozing part of a block was a huge problem in the original Sim City that allowed building stacking and that completely broke the game, so of course, I'm not trying to reproduce that. There's enough data in each building to store all the tiles that can be rubble, but that's only needed for houses tiles really, as we don't want rubble on bigger buildings, but we could alter the palette temporarily for burnt tiles or something. Fire should be stored separately since its a disaster. Each tile does not need to be independent if they are part of a building, and should be managed as so.

The 4x4 and 5x5 building are already taken care of with what I described. We just read the 3x3 area first, then when can access the other tiles when we know for sure that we have a big building.

Just for fun, I investigated how its done in Sim City 2000 and they switched to the whole building being instantly destroyed when it catches fire. That fixes a lot of problems with the original. Actually, we could have a building on fire state where we draw fire on the building, and if the fire is not put out quickly enough, the whole building is destroyed. It fixes a lot of issues, and its really quite simple to manage.

yeah, the way SC2000 did it does simplify things quite a bit. They also didn't have much of a choice because of the isometric angle.

I always liked bulldozing some residential carefully so I could better fit the housing to the coastline... and sometimes it was helpful to cram in a road in a tight fit... makes for a more organic looking city vs just blocks and blocks of grid.  I guess I'm just not aware of how it broke the game so badly... I only did it when I had a good reason to.

"electric line over road"

Also not quite that simple.  You need to know which way the road is going, which way the power line is going etc... you don't want to have to examine all the surrounding cells every time you paint the screen.  Even if you said the power could be calculated you still have to store the road tile... so there are 7 seven different road tiles if you count all various possibilities... so there go 3 of your 4 bits just describing roads.

I suppose if you had enough CPU power you could calculate a more detailed "buffer" for the screen that was visible and only calculate the specificity of the tile when it was actually on-screen.

All sorts of neat hacks that you could consider.

I don't think checking the surrounding tiles when drawing is that expensive, a lot of games do it that way. And besides, it's Sim City we are talking about, we could get by on 10 fps and no one would notice. This means we have a lot more potential CPU time per frame than more conventional 25+ fps games. We can also stagger game updates over many frames, we don't need to calculate electric connectivity, or disasters, or residential sector growth on each frame.

We don't need to follow the exact design of the original Sim City either. We could have low density residential areas that are 2x2 that can only contain houses, so this way it would be slightly easier to fit houses in some areas.

Here is an example of how building stacking broke the game so badly: