In Caesar III, your "blocks" were organized by how far the laborers walked. For example, the houses a Bath Worker walked by determined which houses had access to a bath. If the worker took a left at a fork, all the houses to the left would have access to the bath, but none of the houses to the right would have a bath.
This led to the strategy of minimizing forks and maximizing the worker loops to create "blocks", where workers reliably provided needed services (marketplace for food/pottery, furniture. Bath houses. Doctors. Prefects/police+firefighter units, religious services, entertainment, etc. etc.0.
-------
Pharaoh / Cleopatra, the next game in this series, made this more explicit. With "roadblocks", any worker who "determines services" would make a U-turn upon touching a blocker. This allows you to explicitly make blocks (by preventing workers from taking the wrong fork in a road).
So I guess what I'm saying is... the "height" of the gameplay was found in Pharaoh / Cleopatra, rather than Caesar III. Impressions Games did a great job with Caesar III, but those last few additions in Pharaoh / Cleopatra really makes the designing of blocks / housing areas much easier and more consistent.
> While Julius does not implement any gameplay changes, a fork of Julius named Augustus is implementing many long-wanted gameplay changes, such as roadblocks.
Ah, that's somewhat exciting. At least another open source project is backporting the roadblock to Caesar III's engine. Which of course breaks compatibility... but it'd be a better game IMO.
In my recollection, roadblocks didn't really fix the walker issues.
I've had countless occasions where a walker would suddenly stop servicing a row of houses he or she could previously access just fine without any change to the layout of a "neighbourhood". This seemed to happen because the houses had gotten too big and a resource the walker was distributing to the houses did not last until the last few houses (walkers had limited stores of resources they carried, although this seemed to happen with religious walkers also who as far as I remember didn't have quantifiable stores; might be wrong). At that point the walker would have to go back to fetch more of the resource to service those last few houses. Meanwhile those houses would devolve because they didn't have any more of the resource they needed to keep their current level. Devolving houses would lose one or more levels and shed occupants. Once the walker reached them with the required resource, the houses would evolve again. Then when they ran out of the resource again they 'd also devolve again, in a vicious circle that could drive a player mad. Usually the only solution was to demolish some housing and build a service building in their place. Which messed up everything all over again.
To be fair, I observed this primarily in Emperor: Rise of the Middle Kingdom (which I played at least as much as Cesar III, but more recently since I found it on GOG a few years ago). I've only played a little bit of Pharaoh and Zeus, but if this kind of problem wasn't fixed in Emperor (which came after Pharaoh) then I'm guessing it affected Pharaoh too.
Interestingly, I observed exactly the same issue in Lethis: Path of Progress, a Cesar III clone I've played. Lethis also has roadblocks, but they don't really help, you gotta be prepared to pull some houses down and build new service buildings.
Well, the key to these games is to "not solve every problem" for the players, but only to "solve the tedious problems" for the players.
You could build very good blocks in Caesar III with consistent services. However, it meant that you couldn't have _ANY_ forks in the road at all, and that all of your blocks would be giant loops. By adding roadblocks (ie: Pharaoh), you can suddenly have as many forks in the road as you like. For different sized blocks. Expanding the kinds of "block designs" that are optimal for the game is probably a good thing. Base CaesarIII is too restrictive IMO.
--------
"Running out of resources" locally is solved through warehouse management. I'd argue that this is the "fun" part of the game. Each warehouse + marketplace only can serve as many homes / houses as they can reliably pull supplies. For something like pottery, that is:
1. Clay Pits
2. Pottery furnace
3. Warehouse
4. + Additional Warehouses throughout the city for a good distribution network. Possibly augmented with foreign trade / docks.
5. Marketplaces
6. The final delivery to the house.
Yes, the Marketplaces, and even warehouses, have limited "throughput" and can only serve a finite number of houses. After that, you must expand by building "parallel marketplaces". Eventually, you build too many marketplaces and the Warehouse cart-pusher is overloaded with work, so you need additional warehouses to expand that bottleneck. Etc. etc.
IE: This problem is "reserved for the player to solve". The game shouldn't solve it for you, otherwise it wouldn't be a game anymore. Deciding "which bits" of the game to solve vs leave to the player to solve is the fundamental question of game design: what is fun anyway?
You're saying it's part of the challenge to build an efficient neihgbourhood, and I agree but it detracts from the charm of the game to see a neighbourhood oscillating wildly between house levels. At that point, for me anyway, the game's behaviour goes beyond "a challenge" to "an annoyance".
Now that I remember it, my solution was rather to keep some neighbourhoods deliberately low-level so that my city had enough working hands, even if some of them weren't living in luxury. It meant I could keep their houses provisioned much more easily to stay at a middle level, even if I had to build more of them. So I created an underclass, in short. In Emperor, the distinction between citizen class was part of the rules of the game.
Another solution is to do more or less what you and ufo below say: break up the city in small enough blocks with enough close-by service buildings that they won't run out. But that takes up a lot of space and the need for warehouses in close proximity tends to depress the land value of plots, which again hampers development. But that's OK, I agree that overcoming that sort of challenge is part of the fun of the game. Although I mainly played those games because I loved seeing a pretty ancient city filled with simulated people going about their life run on my machine :)
If you like that sort of challenge in a game (where to place distinct production units in a predetermined space with limited options) then you might enjoy the game Slipways:
Nothing to do with ancient cities, or city building, but for me at least it scratches the same itch of micromanaging as playing Cesar III sometimes did.
In my experience, the biggest source of "random" glitches were the entertainment walkers. Because of a bug, sometimes the dancers would teleport and wonder off outside of the block. Lack of bazaar goods can also be a problem, specially if you have 1x1 houses because those run out of supplies faster than 2x2 houses. For 2x2 houses they need a bazaar visit twice a year, which matches the period in the random walker algorithm. However, for 1x1 houses that might not be enough; I suggest building an extra bazaar to be safe. Religion & water walkers don't spend resources. Education walkers consume papyrus every time they leave their building. If they're out of papyrus they don't go to work.
Right, I thought I might be misremembering the need for resources of religious workers, thanks.
The markets always tend to be a little unwieldy. It's easy to run out of space to place a maker far enough from housing to not depress its value, on smaller maps or ragged terrain with lots of rivers etc. So you gotta manage carefully.
One funny thing about bazaars is that they decrease desirability for adjacent houses but increase desirability for houses that are 3-6 tiles away. A good strategy is to build them close to the houses, but surrounded by other service buildings.
Yeah, I really wish those games allowed me to simplify "draw" the trajectory of the workers. You'd still be limited by the length they can walk from their origin building but would not get frustrated by worker suddenly choosing another route, breaking all the nice areas you took hours to build.
But they were really great games anyway. Caesar III in particular is the first game I spent many hours on, and hold a special place in my heart.
Augustus has been playable for a long time now. I was playing it months ago when I went back to revisit CIII.
The walker mechanic struck me as a clever solution that really feels like something from a more resource-constrained era of games. With one feature, they managed to solve two problems: “is this service building close enough to this other building when following the road graph” and “guys walking around whom you can click on”.
This would be a bit more usable if it were in a sortable table and/or had more filters. The badges look is cute, but less useful for quickly skimming. As a casual "hey I want to play an opensource game" reader, I think it would be beneficial if the landing page focused only on those that were Playable. A long list of Unplayable games with Halted development degrades the quality of the resource.
I am haunted by the of things that caught fire and as a 8-9 year old I didn’t understand why. I don’t think I generally made it far enough that the plebs were in need because the whole city had burned.
Yeah 10 yr old me burnt a dozen or so cities before deciding the point of the game is humiliating me by burning my granaries/gymnasiums etc and moved on to Czar and ultimately Age of Empires 2.
I really liked Caesar III but I never seemed to be able to get service reach a reasonable amount of real-estate, presumably due to the left turn mentioned in another branch. So I ended up plopping way more temples and engineers/prefects than strictly required.
I have spent countless hours on this on my unlocked PS Vita... it runs very smoothly, and the controls are great. Really scratches an itch that few games do. Man does it get difficult at the later stages though...
The problem was, even in peaceful cities, if you failed in economy and borrowed money from Caesar and not pay back for a long time or failed to send him his “gifts” he would send an army to destroy you.
In peaceful cities that was game over. In combat cities you could potentially defeat his army once or twice and buy yourself some time to pay up his debt.
Most of the economic/"peaceful" cities also have invasions that you need to deal with, though they're smaller than if you had chosen the military city.
Save game compatibilty is impressive and maybe an "unnecessary" feature. Any reason that this was possible, was the save game format documented or just reverse engineered?
This appears to be a huge effort. The "Augustus" engine, which shares a lot of code with "Julius", has all of the incompatible updates (roadblocks, zoom, changes to worker behavior, etc. etc.).
The compatible updates (compatibility with modern Windows, MP3 based sound support, etc. etc.) are all together in Julius... I guess for all the people who have 20+ year old save files they want to come back to.
The save format was reverse engineered. Quite a bit was already known from my previous tool to create a .png image out of a saved game file, and from someone who created a Mac <--> Windows converter for saved games: the Mac version of the game used a different file format. Julius also contains tests to make sure it stays compatible.
Is it necessary to build a game like this in C? Could one build a game with comparable computational and graphical requirements in Python or something?
However, many people in game programming care about their craft and having as much control as possible and also being efficient with their resources. In this project specifically, there might be also some kind of nostalgia thing going on.
By the way, even though I use Python daily for ML and some web stuff, I find Python very lacking for serious, complex projects because of the dynamic type system, bad performance, and the infamous GIL. I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing.
> By the way, even though I use Python daily for ML and some web stuff, I find Python very lacking for serious, complex projects because of the dynamic type system, bad performance, and the infamous GIL.
I don't disagree re: the downsides of Python specifically, just threw it out as an example.
> I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing.
Well, some of us are self-taught developers and so system-level languages are very unapproachable.
Ultimately though, seems like a simply unnecessary headache even if one would be competent in using those languages. Friends of mine with CS degrees still don't opt to do side and hobbyist projects in those languages, for example.
Rather than calling it sloppy, I would instead say types barely exist at all in C. A type in C is really just a transient label reminding you and the compiler how to interepret some block of 1's and 0's, which is the only true type.
The Python type system really has quite a lot of overhead compared to this :P
Not specifically C, but you do want to have a language that's as close to the hardware as possible. Since Julius supports way higher resolutions than the original, the time required to draw the screen also increases: full-HD resolution requires 6.75 times more pixels to be drawn than 640x480. I've had to make optimizations to the drawing code to get a decent framerate on higher resolutions.
Seems unlikely. The performance ratio of native code vs. Python is hundreds of times. The original game targeted roughly 100 MHz CPUs. Computers have gotten faster since 1998, but not that much faster in terms of single-threaded performance, the relevant metric here. I'd guess a python x86 emulator would run at 1/5 to 1/10 the required speed.
Unfortunately, that's just not true. At least not in pure Python without using Cython, C-extensions, graphical libraries implemented in C, or the like. In pure Python, you can't even write an NES emulator that operates at full-speed. Look it up. Every NES emulator ever written in Python uses C libraries or some kind of C extension like construct to achieve 60 FPS.
As someone who used to feel that the most beautiful and elegant code was written in C, I feel the same way about (base) Rust. Assuming you 1) avoid async and 2) avoid excessive use of traits and generics, it has a real, pure C feel to it.
There's something fundamental about C though - and in some ways it feels as pure and fundamental as LISP.
This led to the strategy of minimizing forks and maximizing the worker loops to create "blocks", where workers reliably provided needed services (marketplace for food/pottery, furniture. Bath houses. Doctors. Prefects/police+firefighter units, religious services, entertainment, etc. etc.0.
-------
Pharaoh / Cleopatra, the next game in this series, made this more explicit. With "roadblocks", any worker who "determines services" would make a U-turn upon touching a blocker. This allows you to explicitly make blocks (by preventing workers from taking the wrong fork in a road).
So I guess what I'm saying is... the "height" of the gameplay was found in Pharaoh / Cleopatra, rather than Caesar III. Impressions Games did a great job with Caesar III, but those last few additions in Pharaoh / Cleopatra really makes the designing of blocks / housing areas much easier and more consistent.
> While Julius does not implement any gameplay changes, a fork of Julius named Augustus is implementing many long-wanted gameplay changes, such as roadblocks.
Ah, that's somewhat exciting. At least another open source project is backporting the roadblock to Caesar III's engine. Which of course breaks compatibility... but it'd be a better game IMO.