Free city simulation game software for linux

Unlimited Simulator project is a general purpose simulator.
Unlimited Simulator is not a game. Its a basis to create whatever simulations you want, from games to scientific simulations.
You only have to worry about physics, controls and how the world looks like. It can be at the same time a car simulator, a spaceships war game, or a scientific simulation.
While you can do these things on their own, Unlimited Simulator provides the ability to do all three at once. It allows interaction of completely different kinds of clients, thus achieving unprecedent realism and complexity.
Main features:
- multiplayer: many players by internet or two in your computer;
- create your own vehicles, tracks, terrains, sounds, objects;
- vehicles may have their own physical simulation functions, and interact with the game, creating new objects, destroying others. They can fly or float or move underwater; they can be animals, or surrealistic creations. You create.
- track can contain structures as loops, bridges, banked curves, and anything you can do with polygons;
- creating a track can be done DRAWING on the terrain (not implemented yet);
- objects can be animated and intelligent!
- everything is modular: this means almost all the stuff is plugable! No need to recompile the code;
- last, but not least: GPLed!
Enhancements:
- big debugging in ulengine/primitives.c. Several allocation problems solved.
- review of network code: structs separated in a new header, shared/net.h, and other improvements in code itself.
- review of client plugin format (what functions, names, etc).
- wrappers for the not-so-standard standard C variable types in config.h.
- cosmetic changes in some places, specially ulengine.h.
- BIG debugging in ulengine/project.c and ulengine/graphic.c. Only a billion or so bugs left.
- improved ulengine/demo.c; tests now include graphic functions.
- fixed two small bugs in drawHLine due to rounding.
- added a new projection system. Not tested yet.
- graphics test phase started: drawPixel, drawHLine, drawLine, drawFlatTri and drawShadedTri are working.
- modified POLY_UL structure: SCREENP_UL *projected field was deleted. This field is really unecessary, and deleting it saves 2*sizeof(int) bytes for each vertex. Projections are not individually saved anymore (why should they be after all?). See ulengine/project.c:projectP() to see how projected points are handled.
- added ulengine/image.c, to handle image operations.
- added ulengine/effects.c.
- textures support implemented.
- several small optimizations in ulengine/graphic.c.
- work in the server communications system.

The Noble Ape Simulation has been developed (as the Nervana Simulation) since 1996 and is a biological simulation software. The aim of the simulation is to create a detailed biological environment and a cognitive simulation.
The Simulation is intended as a palette for open source cross-platform development. It provides a stable means of simulating large-scale environments and cognitive processes on Windows, Mac and Linux.
The Simulation includes a detailed scripting language for user-implemented movement and cognitive-process development.
Enhancements:
- This release fixes a bug in displaying only the seen Noble Apes, and has code simplification towards OpenGL implementation.

Multi-Simulator Interface, in shrot MSI, is a simulation interconnection engine. In other words it is a program that connects simulations together by synchronizing their clocks and data. Multi-Simulation Interface serves the same purpose as HLA and supports most of HLAs functionality (and more).
The MSI is an HLA alternative. The major motivating factors in the design of the MSI are speed, interoperability, and ease of use.
The MSI was written as a cutting edge distributed simulation component to connect multiple instances of ATLs premiere simulation software, CSIM, and it can be used to interface any compatible simulations.
How does the MSI compare to HLA?
The MSI was originally created to be just a light weight HLA RTI. However, as it was written, limitations in HLA were discovered. The MSI is an improvement on both the design and implementation of HLA. Some highlights include:
A 1,536 to 1 reduction in size over the publicly available (until late 2002) HLA RTI.
At least one order of magnitude of bandwidth consumption less than the publicly available (until late 2002) HLA RTI.
The ability to subscribe to an object name in addition to a type.
Time synchronization that allows for proper causality when used with discrete event simulators.
Support for systems-of-systems (SoS) and hierarchically organized simulations.
Availability for many platforms.
MSI Concept - A Synchronized Data Broker
The concept behind MSI is the synchronized data broker. There are many connected software systems that posses state data that changes over the life of that system. In the case where these systems need to exchange this changing data with other systems and the other systems will exhibit the effects of this data on their own state, the synchronization of this data may need to be managed.
Historically the management of this data has been as simple as tagging it with the time of its release. If there is any conflict in the data the most recent version of the data is used. If the data is late an extrapolation can potentially be used. In SQL relational databases transactions and locking are used to ensure data integrity. Most data brokering services offer little or no sychronization, only delivery.
MSI Setup and Use
The MSI uses a XML stream through a direct socket connection for communications. This enables the MSI to be used from any programming language that can use sockets (C, C++, Java, Ada, Lisp, Perl, etc.). Also, the MSI was written with cross-platform libraries that make it portable to all the major OS platforms (Linux, Solaris, Mac OS X, Microsoft Windows, IRIX, HPUX, etc.).
The MSI is a single executable file and is distributed with example code for the simulator/federate side interface.
MSI Time Synchronization
The MSI time synchronizer can mix unconstrained with time constrained simulations. Each constrained simulation reports the time of the next event that will occur in that simulation/federate. This time may be artificially inflated to cause loose synchronization (less overhead but less guarantee of accuracy). The simulations/federates will advance to the announced time.
MSI Data Synchronization
The MSI implements a publish/subscribe data broker. The MSI is presently not validating, therefore it does not require a separate data format specification (like the HLA FOM). When data format validation is implemented, it will be an optional feature and not written in Lisp. This greatly reduces MSIs setup time. Also, not being locked to a predetermined data format allows for dynamic data types.
There are five commands associated with the MSI data broker: publish, subscribe, update, unsubscribe, destroy (destroy is not implemented yet). Simulations/federates may subscribe to object names in addition to object types. This allows simulations to subscribe to specific objects of a type without needing to receive updates of all objects of that type. The update command is both an incoming and outgoing command. When a simulation/federate receives an update command, it is expected to reflect the new values of that object.
The MSI has a very flexible publish and subscribe system. A federate may subscribe to an object type or an object name. In addition a federate may specify particular attributes of an object or object type. For example, if an object has attributes name, x, y, and z, a federate that only considers two dimensions may choose to subscribe only to name, x, and y.
The MSI also supports systems of systems and object hierarchy in simulations. A publishing federate may designate a parent object. Subscribers may then subscribe to the objects children.
MSI Messaging
The MSI allows simulations/federates to send messages (interactions in HLA) to each other. These messages can contain multiple attributes and be multicast to a specific group of simulations.
Recently Added Features
Removed external library dependencies to improve the portability and fragility of the MSI.
Added a better client library.
Improved documentation.
Enhancements:
- An XML parsing bug in the utilities library was fixed.
- The socket library was enhanced with more protocols, Win32 tricks, and the ability to key off of addresses as well as names.
- The --wait-for command line argument was added.
- Several internal bugs were fixed.
- More of the client library and the CSIM interface were flushed out.
- All standard functionality was tested.

This is an adapted, improved version of the popular javacave game, written in QtRuby.

Installation:

download
chmod +x snake(gl).rb
run it.

Simulation::Sensitivity is a general-purpose sensitivity analysis tool for user-supplied calculations and parameters.

SYNOPSIS

use Simulation::Sensitivity;
$sim = Simulation::Sensitiviy->new(
calculation => sub { my $p = shift; return $p->{alpha} + $p->{beta} }
parameters => { alpha => 1.1, beta => 0.2 },
delta => 0.1 );
$result = $sim->run;
print $sim->text_report($result);

Simulation::Sensitivity is a general-purpose sensitivity analysis tool. Given a user-written calculating function, a "base-case" of parameters, and a requested input sensitivity delta, this module will carry out a sensitivity analysis, capturing the output of the calculating function while varying each parameter positively and negatively by the specified delta. The module also produces a simple text report showing the percentage impact of each parameter upon the output.

The user-written calculating function must follow a standard form, but may make any type of computations so long as the form is satisfied. It must take a single argument -- a hash reference of parameters for use in the calculation. It must return a single, numerical result.

CONSTRUCTORS

new

my $sim = Simulation::Sensitivity->new(
calculation => sub { my $p = shift; return $p->{alpha} + $p->{beta} }
parameters => { alpha => 1.1, beta => 0.2 },
delta => 0.1 );

new takes as its argument a hash with three required parameters. calculation must be a reference to a subroutine and is used for calculation. It must adhere to the usage guidelines above for such functions. parameters must be a reference to a hash that represents the initial starting parameters for the calculation. delta is a percentage that each parameter will be pertubed by during the analysis. Percentages should be expressed as a decimal (0.1 to indicate 10%).

As a constructor, new returns a Simulation::Sensitivity object.

Epiphany project is a multiplatform clone of the game Boulderdash.

It is written entirely in C++, using Clanlib as its graphic library.

The player must collect all valuable minerals scattered in levels, while avoiding being hit by a falling boulder or a bomb.

Ice Hockey Manager is a hockey simulator which has the ultimate goal of creating a game that offers the most realistic simulation experience possible. Our focus is more on substance than style.
While we want the game to be intuitive, we arent looking to compete with the flashy 3D graphics you might see in games from EA or Sega. Theyve pretty much cornered the market when it comes to pretty graphics.
Were more interested in games that challenge your mind and not your hand-eye coordination. We plan to take hockey simulators (and perhaps sports simulators in general) to places theyve never gone before, The way we see it, the possibilities are limitless, much like real life hockey.
While IHM may not have photorealistic facial features for every player model in the NHL we do strive to create a game that really does make you feel like you are at the helm of your own hockey franchise.
We first started developing IHM in late 2001 and the development team consisted of two members, Bernhard von Gunten and Arik Dasen. The first real release of the game was version 0.1.1 in January of 2002. The game was playable but still very basic, more intended as a framework for future development. In July of 2002, version 0.1.2 was released with many updates to the game but after this release the project essentially went on hiatus until September/October of 2004.
Up until that time the project hadnt garnered much interest from the open source community, either the project was too localized to Swiss-style hockey or it perhaps just didnt get the exposure needed to get people to jump onboard, whatever the reason, IHM seemed to be more of a labor of love than a project that perpetuated itself. Fortunately, in October 2004, development kicked back into gear and all sorts of new and exciting features started to take shape. Some of these features include computer AI, multiplayer-support, trading/transfers, sponsoring/finances, full season/playoffs simulation, etc.
And the IHM team is currently working towards version 0.3, which has been dubbed a "Preview Release" to demonstrate a fully-operational playable game. Will this Preview Release set any kind of standard as far as hockey simulators are concerned? No, not yet. In fact, many elements within the game are still rather simplified, such as in-game simulation (which will begin development post-0.2), but we hope the Preview Release will compel other open source developers to help out with the project as there is still a lot to be done before IHM can be considered a complete game.
This website is intended to both introduce you to the game as well as to encourage you to participate and/or contribute to this project in some way. Whether you are a Java developer, a graphic artist, a beta tester, or something else entirely, we want to hear from you. IHM cant build itself, and while we have invested many hours into the games development we still have our limitations as to what we can achieve, both in time and resources. So if you think you can help out in some way, please let us know. Ideally, you should be a fan of hockey, but thats about the only prerequisite.
Main features:
- Game controller, based on a game calendar.
- Multiuser framework
- League framework (Swiss style leagues implemented, including playoffs and relegations).
- Teams, with statistics and informations.
- Players with attributes, statistics, contracts and informations.
- Simulated matches with generated plays and "radio" output.
- Training
- Injuries
- Contracts framework
- Sponsoring framework, based on contracts
- Financial framework
- Real Impacts (on teams & players)
- Transfers (Swiss style)
- Infrastructure framework (Arena implemented)
- Prospects
- Assistants
- and more ...
Technical stuff:
- Written in 100% pure Java
- Running under Linux and Windows and every other Java 1.5 platform
- Swing GUI
- More than 200 java classes
- More than 30000 lines of code