flags/reactor-3

Post-apocalyptic action roguelike with a focus on inventory management and gun-based combat.

Reactor 3

Note

Please grab the unstable branch of the game when cloning. Some changes to Numpy have rendered the game unplayable due to a file conflict and I've renamed that file on that branch only. Also, delete all instances of numbers.pyc.

I stopped working on this in 2014, but a successor is being privately developed using a new framework written in C. I will post on Reddit's roguelike or roguelikedev subforums eventually.

Please do not use this game's code as a guide for working with Python / libtcod. I had never developed a project this size before and was learning along the way. R3 accomplished what it did via brute force and creative engineering. I don't recommend that way of working.

What is Reactor 3?

Reactor 3 is best described as a mix S.T.A.L.K.E.R. and Fallout with the additon of procedurally generated elements. There is a heavy emphasis on NPC interaction, squad tactics, and survival, with each action you make shaping the Zone, an unstable area surrounding the Chernobyl Nuclear Power Plant. The Zone itself is a living entity, causing erratic weather events and transforming the local wildlife into hostile mutants.

R3 is brutally difficult and unforgiving, punishing those who choose a run-'n-gun playstyle over non-combat solutions. Combat is heavily grounded in reality, modeling minor injuries like scrapes and cuts to full dismemberment. The player's inventory is also treated as it should; each item must be either held, worn, or stored away in a container (backpack, pocket, etc,) which encourages the player to not only pick and choose between what they carry, but also how they carry it (a pistol would be stored in a holster for quicker access, for example.)

Join a faction and take over the Zone, or simply exist on your own.

Installing

Reactor 3 requires Python 2.7, Cython, Numpy, and libtcod.

git clone https://github.com/flags/Reactor-3.git
cd Reactor-3
python compile_cython_modules.py build_ext --inplace

Next, download the libtcod library and move the .so (Windows: .dll) files from the archive to the Reactor 3 directory.

Run python reactor-3.py to play.

See the section flags below for more info.

Controls

• Arrow keys - Move (4-way movement)/Navigate menus
• Numpad - Moe (8-way movement)
• Enter - Select
• e - Equip/hold item
• E (Shift-e) - Unequip item
• , - Pick up item
• d - Drop item
• r - Reload / fill mag or clip
• f - Enter targeting mode (shoot)
• F (Shift-f) - Set fire mode
• v - Enter targeting mode (talk)
• V (Shift-v) - Use radio
• Tab - Group communication
• k - Open crafting menu
• w - Open medical menu
• W (Shift-w) - Open medical menu (heal someone)
• C (Shift-c) - Stand up
• c - Crouch
• Z (Shift-z) - Prone
• P (Shift-P) - Pause
• l - Look
• O (Shift-o) - Options
• - - Debug console
• ? - Record mode (This will dump potentially hundreds of .BMP files in the game's directory)

Flags

reactor-3.py can be run with a few arguments:

• --quick - Load latest game.
• --profile - Dumps a profile to profile.dat. tools/show_profile.py can be used to view the profile (use the argument highest to show the most time consuming functions)

Credits

Reactor 3 is made possible by the libtcod library. All other work was done by flags, a member of the ASCII Worlds Collective.

reactor-3's Issues

NPC stories

Since it's possible to log character-specific events, NPC dialog can be procedurally generated.

Ex.: "I recently had a terrible fall and bruised my legs!"

Item dropping crash

1. Have backpack, wear t-shirt
2. Pick up t-shirt, place in backpack
3. Take off t-shirt, drop
4. Wear t-shirt in backpack
5. Drop backpack

Update container capacities in tick?

Double check to make sure container capacities are telling the truth about their size. All functions related to adding/removing items from containers should be handled, but just in case...

Don't add item to menu if we can't wear it?

Item name prefixes

Self-explanatory.

Better inventory menu

Items should be grouped under what container they are in.

Should the items being worn show up on this screen also? If so, where?

Clean up logging

Replace all print statements with calls to logging.

Menu rewrite

The current way of creating menus does not allow us the amount of control needed to display more complicated menus. The following changes are proposed:

• Adding a default "MENU_ITEM" dictionary that holds all data for menu items. Keys would include:
  • icon (optional)
  • menu index (where on the menu?)
  • key
  • values
• A better way to handle ACTIVE_MENU, or at least a way to get and change ACTIVE_MENU values without changing them directly

Item-throwing bug

The item's position is not updated when held.

1. Drop item
2. Pick up and hold item
3. Move somewhere else on the map
4. Throw item

Damage system (rev. 1)

Some key things to remember:

• Overall "health" is determined by the collective status of all limbs combined.
• Severe damage to vital limbs is fatal, regardless of overall health.
• The removal/damage of non-vital limbs can still be fatal if not handled properly (bleeding not stopped, etc.)
• The healing of certain injuries involves using specific items, like a bandage to stop bleeding or pair of pliers to remove a bullet.

Taking off items under another

1. Put on t-shirt
2. Put on backpack over t-shirt
3. You can take the t-shirt off without taking the backpack off

Items are stored in order, so it'd be a simple iteration through the equipped items on that part of the body. Putting those items back on is a different story.

FPS drop on loaded maps

Freshly created maps via maps.create_map() suffer no drop in FPS, while the same map loaded from disk runs 10-15 frames slower.

Thoughts: The render_map() function could be rewritten in Cython if needed, but it is clear there is some trickery happening in load_map().

Progress bar for action queue

Find bullet paths using 3D lines

Container crash

1. Place some items in a backback
2. Open equip menu to see items, close it
3. Take off backpack
4. Equip backpack from ground
5. Open equip menu, items from backpack are missing
6. Open inventory screen

I have no idea what is causing this crash. I have a feeling it involves the items not being added in from the pickupitem action.

It should also be noted that the crash can happen in different places, but the same general method is used.

What can we procedurally generate?

Character backgrounds...?

Refactor item-related functions

When referring to inventory items in argument names, use id. If the item is being addressed directly, use item.

Removing items from menus and actions

On item removal, delete any references to the item in menu/action entries.

Create readme.md

Dependencies, supported Python versions, Cython...

Start documentation

Doc strings!

Do menus need to be drawn multiple times?

Since they are each on a surface, should we only draw them once?

Hold item in hand

Size restrictions for containers

Containers can currently hold an infinite amount.

Attach equipping to action system

Refactor bodies

Current body-part system is over-complicated and slow.

Simply store all body parts in one key (body) and rewrite all limb-related functions in life.py.

Handling multiple items of the same type in menus

Precomputing heightmaps for render_map

Not entirely sure if this will speed things up or not.

1. Would the Cython-compiled render_map be sped up?
2. The pure Python implementation should see a speed increase (iterator vs. look-up.)

Random item placement in Terraform

Create an item spawner that randomly selects and places X number of items from a list on the map in a user-specified radius. This should only happen once (with new games.)

Refactor scrolling code in Terraform

Swing over to move_camera(pos).

Menu shortcuts by typing the first character of a menu item

Falling over

Not all items removed from inventory when backpack is dropped

1. Have a backpack
2. Pick up a pair of shoes and a t-shirt
3. Check equip screen (you should see both the shoes and t-shirt)
4. Drop the backpack
5. The shoes are gone but the t-shirt remains

Happens regardless of what the items are.

Drawing paths using SELECTED_TILES

See title.

Automatic Compiling of Cython Modules

Two things need to be done:

1. Automatically compiling Cython modules on able machines.
2. A way to track what version a Cython module is, so it can be recompiled when it is outdated.

Number 2 can be avoided if the compilation is done every run. Otherwise the check needs to be done via some kind of variable (VERSION, for example.)

Remove menu index from ACTIVE_MENU

Read from menu['index'] instead.

More detailed pickups

When picking up items, give the player a choice between:

1. Pick up and sort (5 ticks)
2. Pick up quickly (2 ticks)

Gun holster

Terraform "slice" mode

There should be a way to view strips of land from the side.

Weird rendering bug with the message box

After two or three entries, lines begin to disappear before finally reappearing.

Function for determining access times to various items

For use in action delays.

Enemy type: Zombie

Zombies will resurrect on death 2 or 3 times, finally dying (for good) on the the last one.

Shouldn't be able to open multiple menus

...or maybe it's a feature?

Possible item ID issue

When an item is inside a backpack and the backpack is dropped, the item keeps its ID. Will this give us an issue in the future?

Brush size in Terraform

To make it easier to draw in 3D.

Pain tolerance

Create a function that grabs the actual pain a limb is causing, taking pain tolerance, either adjusted or artificial (via meds), into account.

Relocate file-specific functions to their respective modules

Functions in graphics.py, like draw_menus(), should be moved to their related modules (menus.py in this case.)

Better tile placement in Terraform

Allow the map maker to place both individual or random tiles from a group.

Wrap all graphics calls

For portability, all graphics calls should be wrapped into functions that then point to library-specific draw calls. Benchmark.

Event system

Currently it is difficult to display messages as a result of the player's action. For example, printing "you picked up a..." in the message box involves wrapping the functions related to picking up and storing items and making calls to gfx.message. This makes attaching the player's input to the action system difficult.

Solution would be to create a logging-like function for tracking the movement of every character, then having only player-related ones print to the message window.

Item removal fixes?

Item removal feels muddy at best.

For example, life.remove_item_from_inventory needs serious examination to determine if it's the best plan of attack in terms of actually doing what it says it does. Bits like _holding['holding'].remove(id) say a lot, as they access the limb's data without going to another function first, which might be okay...?

That said, the function is a good solution if you just want an item gone. That alone might make up for its shortcomings.