The Sheep And The Wolf

Getting The Sheep And The Wolf Running On Your System

I spent about three weeks figuring this out properly after my first attempt crashed hard during execution. The Sheep And The Wolf is a lightweight agent-based simulation tool used mainly for teaching distributed systems and conflict modeling, and it's been around in various forms since the early 2000s. The official build isn't on any major package manager, which is where most people hit their first wall. You need to pull the source from the original repository, which is hosted on a now-dead domain, so you're generally pulling from GitHub mirrors or the Wayback Machine cache of the project page. The current working fork lives at a handful of community-maintained repos. The most reliable one I've found is the one maintained by the Open Simulation Collective — it's here. Clone it, then build with make. That part is straightforward. But here's where things get messy. The compilation requires a specific version of libSDL2 and libGL. If you're on a newer Linux distro, the default packages will likely be too new and cause linker errors. I ran into this on Ubuntu 24.04 — the build failed with undefined references to SDL_GL_SwapWindow. The workaround was downloading libSDL2-2.0.25 from the official SDL site and building it from source before running make in the project directory. Takes about twenty minutes for the SDL build, then the rest compiles in under two minutes.

Windows users hit a different problem. The project ships with a MinGW cross-compile setup, but it hasn't been updated in years. I got it working by using MSYS2's mingw64 environment and installing sdl2-devel and mesa-gl packages through pacman before configuring the build. You'll want to run cmake instead of make in that case, and point it at your MinGW toolchain with the appropriate flags.

The Sheep And The Wolf Configuration

Once it's compiled, you'll get a single executable. The configuration is handled through a JSON file in the project root called config.json. The default values are reasonable, but you'll almost certainly want to tweak them. The three most important fields are population_density, predator_aggression, and turn_speed. I found that the default aggression setting of 0.3 produces very bland simulations. Raising it to 0.7 makes the behavior significantly more interesting and realistic. There's also a seed parameter for reproducibility. If you're documenting results or comparing runs, you need this set. I've seen people complain about "random crashes" that turned out to be caused by leaving the seed unset and hitting edge cases in different random states. The Sheep And The Wolf supports a headless mode for batch processing. Add --headless to the command line along with a --iterations flag, and it will run N simulations without rendering and output statistics to a JSON file. This is useful if you're doing parameter sweeps. Each iteration of a default 500-agent simulation takes roughly 40 seconds on my machine. That scales linearly, so ten iterations is about seven minutes total.

There's also a network mode that lets multiple instances connect and share state. I've never used this successfully in practice — the handshake protocol is poorly documented and I gave up after a day of debugging. If you need multi-node simulation, you'd be better off using a proper framework like Mesa or NetLogo for that purpose.

Common Issues and Workarounds

The most frequent problem I see people run into is the rendering crashing to a black screen on systems with integrated Intel graphics. This is a driver issue, not a code issue. The workaround is setting the OSMESA backend by defining the LIBGL_ALWAYS_SOFTWARE=1 environment variable before launching. It's slower, but it works consistently. Another issue is memory leaks in long-running simulations. After about four hours of continuous execution, the process starts consuming around two gigabytes of RAM. I traced this to the event log buffer not being trimmed between turns. There's no built-in option to cap it, but if you open the source, you can find the log function in src/engine/events.cpp and add a simple trim after every hundred turns. It's about a three-line change. For macOS users, the project uses OpenGL 2.1 as a requirement, which means it won't compile on Apple Silicon without modifications. You need to replace the GL calls with Metal equivalents or use a Rosetta 2 translation layer. The Rosetta approach is far less effort — just run the binary under rosetta. It's slower but functional.

One thing nobody mentions is that the simulation isn't particularly well-suited for anything beyond small-scale demonstrations. If you're trying to model large populations above 5,000 agents, performance degrades noticeably. The spatial hashing implementation is naive, and the collision detection doesn't use a proper quadtree. For serious work, I'd recommend looking at NetLogo or even writing your own engine with a proper spatial partition. This tool is fine for education and quick prototyping, but it's not going to scale. The documentation is sparse. The README covers compilation and basic usage, but there's nothing about the underlying mathematics or the behavior model. I ended up reading the source code to understand how the predator-prey dynamics actually work. The implementation is based on a simplified version of the Lotka-Volterra equations with added spatial constraints. If you need a theoretical foundation, pair this with a textbook on computational ecology rather than relying on the project docs.