traverseda / pycraft

A fork of "Minecraft in 500 lines of python" intended to someday be used as a real engine, instead of as a learning example.

PyCraft

A community driven fork of foglemans "Minecraft" repo.

Motivation

Python is somewhat poorly suited for game development. However it is well suited to data-science. A lot of our tasks, working with large voxels sets, strongly resemble the kind of problems you encounter in data science.

The big advantage comes from limiting "real-time" state. By not relying on anything having to happen now, we can do more complicated computation. At the low-end, that means we can implement much more complicated occluding algorithms, and thus draw more complicated scenes.

This kind of split could also be used to run more complicated types of operations, like a cellular automata crudely simulating things like plant growth or water.

When possible, we would prefer to "scale-out". We don't care about outright efficiency too much, rather we care that our solutions can work for very large or very complicated operations. The exact opposite of "typical" game development methodology, which would prefer solutions that "scale-up", solutions that a very fast for the type of data they expect to deal with.

It is currently pre-alpha quality.

Screenshot

Virtual Environment (Recommended)

# create a virtual environment
virtualenv -p python3 ~/.venv/pycraft # (or wherever)
# you may need to add execute permissions
chmod -R a+x ~/.venv
# activate
. ~/.venv/pycraft/bin/activate # on mac
. ~/.venv/pycraft/Scripts/activate # on windows
# deactivate (when you're done)
deactivate

Installing

pip install -e .

option 1:

pip install -e .[dev]
# or: python3 setup.py develop
pycraft

option 2:

python -m pycraft
# or: python3 -m pycraft

Features

• Support for python 3.5
• Simple Perlin Noise terrain generator
• Object-oriented blocks system

How to Play

Moving

• W: forward
• S: back
• A: strafe left
• D: strafe right
• Mouse: look around
• Space: jump
• Tab: toggle flying mode

Building

• Selecting the type of block to create:
  • 1: brick
  • 2: grass
  • 3: sand
• Mouse left-click: remove block
• Mouse right-click: create block

Quitting

• ESC: release mouse, then close window

Contributing

We support and encourage contributions.

Attributions

The game textures "Piehole" by Alex Voelk is licensed under CC BY 3.0.

pycraft's Issues

"Object oriented" API for implementing new block types.

It should be pretty simple to create new blocks. Just define a new block, inheriting from "objects.base.block".

Off the top of my head, a few methods objects.base.block should implement.

delete() #Called when an object gets deleted
texture() #Called when the engine tries to draw a block. You can implement animated textures with it.
interact() #Called when a user tries to interact with an object
location() #returns the current blocks location.
uuid() #The unique ID of a block, if it should have one. This is for objects like chests.

Some of those should probably be attributes, then wen can make the properties.

---

Longer term, instantiating hundred of thousands of blocks is probably a bad plan.

Add support for mobs

Destroying hidden blocks causes keyerror.

If you fly into a hidden area before the blocks get shown and try removing a block, keyerror.

Installation Instructions for readme

just a quick bit for installing and running the game in the README would probably be a good addition to make the whole thing more approachable/lower the barrier to entry.

Chat of some sorts?

Do you think we could open up some sort of chat, that makes communication a bit easier?

The two places I'm in anyway:

• IRC (e.g. Freenode)
• Slack (devolio-devchat.slack.com)

Seperate "world" and "window"

Right now the world is responsible for part of the rendering. It shouldn't be. We want it to be as simple as possible to implement new worlds.

Cython optimizations

I was working on ways to speed up earlier versions of this project by way of Cython. When things stabilize a bit, I'll see about contributing some code in that vein, but if you don't want Cython to be a requirement, I can make it into a separately maintained fork.

Better define project goals

I'd like to get into what goals people have for this project a bit more.

I'd like to see this project ultimately end up being the "django" for voxel/roguelike/tile games.

I'd like it if there was only one real client, and most of the customization happened "server"-side. In the backend, whether that's network transparent or not. I think asking people to do graphics programming to make a game is asking too much. They should be able to ignore most of that, and focus on gameplay.

I'd like to look into gurps for ideas on how our default world fundamentally works. How to handle hitpoints, stamina, etc. It has a proven record of letting multiple settings work well together.

I want people to be able to implement things like dwarf fortress. Incredibly realized worlds with amazing depth.

I'd like it if eventually we got to the point were you could do something like

INSTALLED_APPS = [
    'base',
    'base_worldgen',
    'cyberpunk',
    'spellwords',
    'fantasy_races',
    'industrial_cities',
]

To get something like the shadowrun campaign settings. Or any other combination. Find the medieval base, add in steampunk. Whatever.

If I had to shorten my vision, I'd say that we need to enable fully-realized worlds, and make it easy for people to mix and match them.

---

But I'd like to hear what other people want to get out of the project as well. That's only one approach.

normalize

Is this method correct? One give it tuple of 3 floats ant it round it and return as int? Round if i am correct means 5.4 = 5 and 5.5=6 and 5.8=6. Is that correct? If yes i am repairing that test
def normalize(position): x, y, z = position x, y, z = (int(round(x)), int(round(y)), int(round(z))) return x, y, z

Better installation instructions for readme

HUGE terrain gen improvement

hey guys, was trying to mod the game so it would use defaul textures and do better terrain gen (with like caves etc) and then i found this in world.py:
self._shown[coords] = self.batch.add( 24, GL_QUADS, self.texture_group[block.identifier], ('v3f/static', vertex_data), ('c3f/static', shade_data), ('t2f/static', texture_data))
this is the drawing of the world.
notice that it says "static". the world changes every frame and it should be "stream". after i changed terrain gen was so quick i couldnt see non-generated chunks anymore.... maybe something to add for ya guys :P

Show current block

Should the currently selected block be displayed on the screen (perhaps the bottom left corner)?

Basic Work? (Finding new textures)

Hi All,

I am offering my assistance here towards this project as for a class assignment I have been tasked to contribute to an open-sourced project like this one. I have spoken with @traverseda about this and he said it would be a good idea to open an issue.

I have a short period of time to complete this (less than 4 weeks) and unfortunately I have no experience with Python coding and don't think I will have the time to learn it fluently enough to contribute in that area. I'm looking for any suggestions of basic and non-time-demanding tasks that would help this project and fulfil my requirement to contribute.

Any suggestions will be appreciated here.

Regards,
James

Define a structure for Game States

I wish to open a discussion about modifying structurally the actual project to support game states such as: GamePlay, GameMenu etc.
Game states should deal with drawing, handle button presses, mouse clicks etc.

The 'pip install -e .' command doesn't work

I'm on Windows 10 (x64) and I use Python 3.6.1. I set the directory to this project's directory and used the following command:

pip install -e .

And I got an UnicodeDecodeError. But the following command is OK for me:

python setup.py develop

After using this command I can run Pycraft successfully.

test_licences failing

Licences printed by test ( little change to the test about not failing right away but test all of them and fails after, preparing PR).
!!!(failed, licence not found or not accepted) NAME_OF_MODULE : LICENCE

I am looking for help about individual licences, check if they are OK and each module with licence UNKNOWN need to be checked manually. Put everything in comments

matplotlib:BSD
PyYAML: MIT
numpy: BSD
MarkupSafe: BSD
pwquality: BSD or GPLv2+
Jinja2: BSD
!!! python-dmidecode: GPL-2
!!! lxml: UNKNOWN
!!! sepolicy: UNKNOWN
!!! python-systemd: LGPLv2+
!!! Brlapi: LGPL 2.1
!!! pycups: GPLv2+
!!! Pillow: Standard PIL License
!!! rpm-python: UNKNOWN
!!! pyparted: GPLv2+
!!! pygobject: GNU LGPL
!!! PyIscsi: UNKNOWN
!!! pygpgme: LGPL
!!! sosreport: GPLv2+
!!! openshot-qt: GNU GPL v.3
!!! devassistant: GPLv2+
!!! langtable: GPLv3+
!!! pid: ASL
!!! blivet: UNKNOWN
!!! python-augeas: UNKNOWN
javapackages: BSD
pytz: MIT
pyinotify: MIT License
urllib3: MIT
pyglet: BSD
requests-file: Apache 2.0
ntplib: MIT
requests-ftp: Apache 2.0
six: MIT
requests: Apache 2.0
future: MIT
cssselect: BSD
Mako: MIT
humanize: MIT
decorator: BSD License
Beaker: BSD
python-dateutil: Simplified BSD
httplib2: MIT
iniparse: MIT
IPy: BSD License
pyparsing: MIT License
progress: ISC
!!! setroubleshoot: GPLv3+
!!! dnf-langpacks: GPLv2+
!!! PyGithub: UNKNOWN
!!! python-meh: UNKNOWN
!!! slip.dbus: UNKNOWN
!!! cupshelpers: UNKNOWN
!!! chardet: LGPL
!!! slip: UNKNOWN
!!! seobject: GPLv2+
!!! initial-setup: GPLv2+
!!! pykickstart: UNKNOWN
!!! SSSDConfig: GPLv3+
!!! fros: GPLv2+
!!! pyxdg: UNKNOWN
!!! pyudev: LGPL 2.1+
!!! dapp: GPLv2+

Backfill unit tests

Just thought I'd add this in here, as I'm currently working on it.

Having at least some of the more essential functionality unit tested will help immensely when we start adding more complexity.

There's still quite a lot of decoupling yet to be done that might go along with this.

Convert over to python 3.5

This should make it a lot easier to implement networking features using python3.5's async stuff.

Use a client/server architecture

Exact implementation details definitely need to be discussed. But I recommend a dead-simple implementation using python 3.5's async features, which #1 allows.

Add real map generation

There are a couple of different ways you can generate maps. The default, used for most stuff, if perlin noise.

There's also the possibility of chaining structures together to generate a city/village/dungeon/whatever.

Finally, there's custom coded generators.

We want to eventually be able to use all of them, but for now perlin noise is more then enough.

Terrible performance

Not sure why but when I run pycraft i can barely move the cursor and the game freezes every second or so.

On windows 10 if that matters.

Any ideas?

Depend on redis? (if you use a non-unix platform, please give this a read)

We would like to do the client-server thing. Redis is likely to make that easier, but for the time being is going to make deployment on platforms other than linux harder.

Personally? I'd probably just accept that. But I'd like to get some feedback from the community first.

Right click places two blocks

Last merge request (#72) seems to have messed something up.
Right click places two blocks instead of one, I don't know if that was intended or not.
Does anyone else have the same behavior?

Make textures clearly belong to blocks

Enhancement for #2

Right now, there are like 3 different places where we import/define textures.

It will involve some digging into pyglet, but we definitely need to de-duplicate that.

I'm imagining a "texture" object, that has textures for more then one block.

Blocks return coordinates and a reference to their texture in it.

I think heightmaps could lead to some very interesting effects, and in the future we might want to support dynamic textures (maps) or layered textures (signs).

But we don't need a perfect solution off the bat. Just a quick system for defining a texture in one place, and having the renderer read them.

Support for multiple "Worlds"

Placing WeakStone causes KeyError

If you switch to WeakStone and try to place the block it will causing KeyError.
I've tried debugging it, but the only solution I could come up with was not to use WeakStone at all and use Stone instead.

Decoupling view and world logic.

I'm decoupling the view (drawing to canvas) from the world logic, but I'm finding that I need to either hand a 'world reference' to view, and a 'view reference' to world in main OR call functions on both of them from window, and hand data back and forth.

I'm after clean modularity, and down the line the possibility of running the world without a view. For that I think functions called by window would be better. But they both seem kinda kludgy.

Are there any pros and cons I'm missing?

Current queue is stupid.

https://youtu.be/50fAV9bYdJQ

The current queue for showing and hiding blocks is simply adding a show and hide functions to the queue when you enter a new sector, as a result, if you walk back and forth across the edge of a sector you can rapidly grow the queue, to the point where it lags enough that you can walk over to where it is showing and hiding sectors.

I'm working on a fix that involves either keeping track of the edge sectors, or using a set. Maybe both. I'm thinking there's a way to avoid the weirdness exhibited above.

Add support for "loose" items

Items that aren't in any inventory.

We don't have to treat it like minecraft does. It might make more sense to add a "pile" chest-like object to tiles with loose objects.

Blocks are black on the bottom

Is it just me or are all blocks black on the bottom now?

Difficulty maintaining aligned crosshair

By moving the mouse, the algorithm that makes the camera drive mapping seems to have excessive acceleration when the camera is on the horizon height causing the mouse stick it in the zenith or nadir view.

Regular rather than matrix addition

The cube_vertices function in pycraft/util.py is manually doing addition to every element in a list. I'm about 60% sure that this needs to be happening in numpy or pyglet to be a reasonable speed.

If this get's fixed, the blocks could be moved over .5 and normalize swapped to using floor as described in #45 . This may cascade into other logic though, idk.

Add a gitter room for this project

It might be nice to have a gitter room to help facilitate discussion beyond issues / pull requests. Thoughts?

Travis CI and coveralls

Pending PR #28 (and #17) - we'll have some (meager) unit tests and instructions for running them. With that, it'd be nice to have some Travis CI and Coveralls integration, along with a helpful badge in the readme for each.

Improve performance

What are the Intended Target platforms for pycraft?

What are the intended target platforms for pycraft?

Are we just going to target Windows, Mac, and Linux PCs or are we going to Target smart devices powered by android and iOS as well?

Referencing #34 as this is worth talking about.

util.normalize() is rounding?

I'm working on writing some unit tests for some of the existing code and saw that the normalize() function in the util module is using round(). The documentation for the function says it returns the block containing the input position, so should this be using math.floor() instead?

Fog doesn't work on Mac

It's a little hard to see in the image below, but fog doesn't work when building this project on Mac (more specifically, El Cap). Rather, blocks are visually truncated in the distance.

Crash and error

Traceback (most recent call last): File "/usr/local/bin/pycraft", line 11, in load_entry_point('pycraft==0.1.0', 'console_scripts', 'pycraft')() File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/main.py", line 28, in main pyglet.app.run() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/init.py", line 143, in run event_loop.run() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 136, in run self._run_estimated() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 165, in _run_estimated timeout = self.idle() File "/usr/local/lib/python3.5/dist-packages/pyglet/app/base.py", line 274, in idle redraw_all = self.clock.call_scheduled_functions(dt) File "/usr/local/lib/python3.5/dist-packages/pyglet/clock.py", line 309, in call_scheduled_functions item.func(ts - item.last_ts, *item.args, **item.kwargs) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/window.py", line 127, in update self.gamestatemanager.peek().update(dt, self.ticks_per_second) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/gs_running.py", line 148, in update self.world.process_queue(ticks_per_second) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/world.py", line 172, in process_queue self._dequeue() File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/world.py", line 160, in _dequeue self._show_block(coords, self.area.get_block(coords)) File "/usr/local/lib/python3.5/dist-packages/pycraft-0.1.0-py3.5.egg/pycraft/world/area.py", line 57, in get_block return self.blocks[coords] if self.blocks[coords] else None KeyError: (134, -1, -131)

Graphics settings file

Probably yaml.

Support for saving worlds