huin / chunkymonkey Goto Github PK

The plan is to run one master goroutine per "shard" of chunks.

Player state currently includes:

• Position
• Inventory

Later on it will include health, being on fire, etc.

This must be made compatible with how the Notchian SMP server does its storage.

See http://mc.kev009.com/Authentication

The current design makes use of both synchronous locking mechanisms, and also passing functions via channels. This could likely stand some improvement. I don't have clear ideas about what shape it should take, but I'd like to foster some discussion about how to:

• Achieve a design that is easy to understand and to add features into.
• Avoid race conditions and deadlock.
• Enables movement towards a decentralized server architecture that can run a world across multiple hosts.

Go should provide some very good concurrency patterns that can be utilized, but I feel that it's being used in a very cludgy way.

Release 57 brings in channel-read time checking for if a channel is closed. The current use of channels should be checked to see if there are places where this could benefit the codebase.

http://golang.org/doc/devel/release.html#r57

My proposal:

src/chunkymonkey:
*block
*chunk
*chunkstore
*inventory
*itemtype
*mob
*nbt
*player
*recipe
entity.go
game.go
gamerules.go
interfaces.go
item.go
physics.go
physics_test.go
proto.go
proto_test.go
record.go
server_auth.go
slot.go
slot_test.go
types.go
types_test.go
worldstore.go

src/main:
chunkymonkey.go

src/util:
*datatests
*dumpblockdefs
*inspectlevel
*intercept

You can see a preview here:
https://github.com/nictuku/chunkymonkey/tree/directories-fix

I think this looks much better. Are you folks OK with this layout? Then I'll spend more time on this. Just FYI there are two problems with my current change:

1. for some reason godag is only being able to compile the whole tree, not individual pieces.
   gd # works
   gd src # works
   gd src/chunkymonkey # does not work, even if I see various -L and -I parameters

2. before running tests (gd -t) I always have to do gd -c.

gd -c ; gd -t ; works
gd -c ; gd ; gd -t # does not work

I'll contact godag folks about this later.

The record and playback package is a useful tool, but is currently used only in the server code, which also restricts its usefulness. It would be useful to place the recorder into a proxy relay (perhaps the intercept program, selected by command line flag), and playback into yet another program.

This could aid some automated/repetitive testing of the server, and allow for more flexible testing of client interactions.

Only basic definitions for now, no need to add any specialised logic for them.

fmt.Errorf doesn't do what the code thinks it does. See http://golang.org/pkg/fmt/#Errorf

$ grep -nr fmt.Errorf src/
src/inspectlevel/inspectlevel.go:70: fmt.Errorf("Error loading world: %s\n", err)
src/inspectlevel/inspectlevel.go:79: fmt.Errorf("Error loading chunk: %s\n", err)

Items should be ejected from the workbench inventory into the chunk when no players have a connected crafting window open.

Clients can be crashed if sent malformed color codes or over-long messages via chat. This should be prevented.

In order to be able to increase unit test coverage, a mocking library is required. GoMock ( https://code.google.com/p/gomock/ - not to be confused with the package of the same name that I [huin] wrote) should be fit for this purpose. It is hoped that GoMock will compile against the latest stable "release" tags of the official Go toolchain.

Please add comments to this issue if there are any concerns about this choice.

This design work should naturally happen before anything else in this milestone (even if not in detail). Work on this should help make clear how the multiple servers architecture will look.

This isn't important for the core server, but potentially useful for anyone using the chunkymonkey/proto package for a client.

When two players use the same workbench at the same time, they should see the items in the workbench crafting area that the other has placed, and be able to take items (both crafted and input).

This bug overlaps somewhat with the workbench not dropping items when the window is closed. The items should drop when the last player closes the window.

Put player data like inventory into the shard (allowing for atomic inventory transactions)

To reproduce:

• Place a torch (or use an existing placed torch)
• Place a block against the torch

Expected:

• The block should not be placeable against the torch

This might be a simple case of making the torch non-attachable (if it isn't already), but there seems to be some quirks around how the placed block acts after being placed when it is subsequently dug. The client acts as if the server has told it that the block has been placed, but upon digging, the server acts as if it has not.

I'd like to add basic mobs support - that is, have the ability to spawn mobs, but initially without any strong AI, which of course we should also add later.

If anybody else wants to work on this, please contact me via github so we can sync up and avoid duplicating work.

Since we don't have a mailing list (not saying we need one) I'd like to discuss here a few style changes:

• when naming a method that simply returns Foo, name it Foo() instead of GetFoo().
  ~ GetFoo() is currently common in the code, but one example: item.GetPosition()
• interfaces should be named ISomething, as is the case in interface.go
  ~ there are a few exceptions, but we should probably normalize this.
• should we have a guideline for when a method should return a reference or a value? It feels a bit confusing at the moment. We could be tempted at always returning references, but that's unsafe. Literature like "Code Complete" point out that this is a common source of bugs, since the caller obviously can change the value and this is not always what we want. At the same time, it's argued that the possible performance gains are hard to notice.
  ~ an option is to always return by value unless not possible. But I feel a bit bad in copying values around, so I honestly don't know what's best. I just miss having some consistency.
  ~ All that said, if we settle down with some kind of pure-channel design where only a single goroutine has access to an object, we could stick to a "always return by reference" rule.

Block interaction currently only allows for block placement. This needs to be extended to allow for 3x3 crafting, furnace operation and other special block interactions.

I've made a change in my fork that removes the dependency on the 'godag' program for building chunkymonkey. Instead we will be using gb, which has the advantage that it can produce scripts and Makefiles that allow anyone to build the software without installing additional software.

The structure is a bit more stringent, with everything that is a package under pkg and everything that produces a command under cmd. This also makes it a bit more obvious when looking at the source where in the package hierarchy something lies. I've included a script that will update the build scripts.

Basic usage (all commands run in src)

 # clean everything
 gb -c
 # clean then build
 gb -cb
 # build only pkg
 gb -Pb
 # build only cmd
 gb -Cb

The scripts included work as well without using gb:

 # clean everything
 ./build.sh clean
 # build everything
 ./build.sh
 # build only pkg
 ./build-pkg.sh
 # build only cmd
 ./build-cmd.sh

Take a look at master on my fork and see what you think. I think its an improvement, hopefully I'm not the only one. Don't bother trying to pull, just let me know and I'll push it to the main repository if its okay.

The master Makefile at the root needs to be updated or removed, it likely will not work any longer but I wasn't sure where we wanted those targets to end up.

This might need basic inventory management completed first.

• Separate block specific behaviour behind an interface.
• Store block data in external files.

This might need inventory management completed first.

Implement a recipe system that can be defined by an external data file.

(this is more like a note to self)

I didn't actually test this, but unless this is handled client-side we are probably destroying all items from chunks as soon as they are unsubscribed. I didn't confirm but I believe we unsubscribe right after a player moves away from that chunk.

The desired behavior is that dropped items remain spawned for at least 5 minutes, so the player is able to recover them.

The minecraft community needs a way to bring a notchian server down for maintenance.

While it doesn't make sense currently to bring chunkymonkey down for maintenance (no permanent storage), it might be useful for admins of notchian servers to run a chunkymonkey server on the same port, so that users are kicked with a helpful message when they try to login to the server.

Initially, a command line flag would be sufficient.

Putting a live server under maintenance without a restart would be a bit trickier, but doable. That's much lower priority though, at least until we have a commands system.

I have a candidate change for this already.

Implement all recipes in Beta 1.5 (or at least, those known on the wiki).

Probably worth working on the recipe stuff first, as this might use some of the same concepts/code.

In a notchian server, pressing Q with a item in hand results in the item being dropped - or more properly, thrown.

This currently doesn't work in chunkymonkey.

This includes mobs, items, inventory contents etc.

At the very least a seed value should be read from configuration.

At some point chunkymonkey needs modding capabilities.
I write this down to consider this in the issue #30 about concurrency design.

I am just writing down some ideas and information.

Here is a list of possible language bindings for Go;
https://bitbucket.org/rj/golang-javascriptcore/ - This is a wrapper for WebKit's javascript engine for Go
http://github.com/afitz/golua - Go wrapper for LUA's C API cgo
https://bitbucket.org/binet/go-python - go bindings for CPython C-API lib

Pure Go can only be supported if the end-user compiles Go and chunkymonkey by himself.
This way he could patch the source code.

Another idea is to have modules which run independent from chunkymonkey and communicate over network with chunkymonkey. With this idea all languages are supported if they have network support. The downside is probably execution speed.

Item position, velocity etc. needs to be simulated server-side. For now it should be enough to simply simulate simple friction and gravity. Water movement effects can wait.

For value in doing this, it's specifically important to move physics into the chunk layer. Chunks will need to receive "tick" messages from the game loop.

Chunk access to data that changes will have to be isolated to be thread-safe. For this reason things like physics that need to access the changeable chunk data need to be run inside the chunk goroutine. Small messages from players digging etc. can happily be sent to the chunk goroutine for action.

The eventual aim is to have the current game loop serve as:

• multiplexer for talking to clients
• synchronisation clock messages
• single entry point for looking up chunks, item types, block types

for the chunk loop to serve:

• physics
• mob AI
• item pickup, etc.

Interactions between the game loop, chunks and players should be kept to smallish async messages as much as possible - avoiding cases where a goroutine should block for a reply.

The notchian client doesn't send a "finished digging" packet for these block types. They should be destroyed on first hit.

The chunk module addresses blocks in multiple ways (BlockXyz, ChunkXz+SubChunkXyz, index, shift), depending on context. These get passed as separate parameters a lot, and should be consolidated (including when passed to block aspects).

When blocks are added or removed, the lighting needs to be updated.

Minecraft presents several views onto "inventories" via windows that combine several inventories together.