6 posts
Posted 06 March 2013 - 10:43 PM
Turtle Real Time Strategy - The legacy of an abandoned project
Command turtles like in startcraft, warcraft, etc…
Some of this project is definitely cool and usable. It's just that it will probably never become (by my hand at least) the insanely awesome thing that it was once fated to be. I had big ideas for this project, and I was planning on keeping them super-secret until the project's glorious release… uuuuntil I decided to stop spending my time developing a game within a game, and just develop a game instead.
Anyway, the least I can do is share what I've already got with the rest of the community and make a contribution.
What it does: AKA why it's cool
The Frontend
The front-end is cool. It gets turtles to automatically register on the server and it shows you a map and you can select the turtles and tell them where to go. The map scrolls. Also, if the turtle runs into a barrier, it will note that the barrier exists. It's good for a mess about if you like. The server keeps track of where the turtles are, etc, etc.
I think it's wasd to move the screen, arrows to move the cursor, and space to tell the turtle to go there.
Put all four files on a turtle and on a server, and boot them up (in whatever order you like ;)/>. It only works with one server/one turtle at a time, but it would be soooo easy to make it work for several turtles once you grok the code. I only made it one turtle for convenience really. There's nothing much new to write, just a few variables to shuffle about.
The backend
The backend, however, is much more cool and potentially very powerful, if you understand a bit more about lua.
It's basically a networking interface that creates packets and triggers callback functions. There is no packet forwarding, but from the sounds of things, that might come as part of the core functionality before too long.
Anyway, Turtles register on the server. You create a packet (with the provided functions, which wraps up a table you have created - template functions are also provided), and send it to the server. The packet always has a msgtype.
Now, on the server there are a bunch of trigger functions. When the server receives a packet, it checks the msgtype against a list (or several different lists, so you can create permissions, different groups, etc), and then calls the corresponding trigger function registered for that msgtype. So the trigger function could be registerturtle, turtlemoved (so the server knows if a turtle has moves), turtleoutoffuel (so the server knows if a turtle is out of fuel), etc, etc.
Then there is the same setup on the turtle, so it has a list of trigger functions, and can receive messages from servers. I've commented the source code so it shoudn't be too difficult to figure out what is going on. First read the server, then the turtle. easy3 might just need a little skim over.
The utility library
There's also a utility library called easy3 that I used for turtle movement. It's the first thing that I wrote and it has it's faults but it gets the job done. It keeps track of turtle location somehow, too I think. Lots of people probably write a file like this, though. You need it cause i use it for includes.
What could happen next?
It shouldn't be too hard to extend this so turtles can do more than just move. You could easily write a 'mine' trigger function or a 'build staircase' trigger function for example, and link it in to the fullfuncs function list in the turtle code. Make sure to use the easy3 move commands because they update the server with the turtle's movements. Making it work with multiple turtles should be easy, too.
My ideas about properly extending it were to implement packet forwarding, so turtles don't go out of range. Then I had some ideas about saving turtles positions to file every time it moves, so that if a chunk gets unloaded it isn't a problem. After that, build in a mining function, and create an interface that designates a section of land as 'mining area'. Then code in building functions: Have buildings to automate different processes, such as smelting, item sorting, mob farming, railway building, whatever. And if, say, all the chests of a item sorting place got full, the central server would be alerted and would schedule a new one to be created. That kind of stuff were my long-term goals.
Anyway, this code is yours. Use it as you see fit.
The code
Make sure to give the files the names below:
beserver http://pastebin.com/Sw6VBuqC
beturtle http://pastebin.com/B5fLtVq7
easy3 http://pastebin.com/j3CEQEzg
startup http://pastebin.com/UfxD2rcx
Put all the files in a server & all the files in a turtle. As it is, the program expects the turtle to be 2 spaces right of the server when it's spawned(i had a disk drive in-between them). The terminal and turtle should be facing opposite directions. The turtle should be facing 'past' the terminal.
To customise this, look for the easy3.init_values(x,y,z,dir) function in the server and turtle.
Command turtles like in startcraft, warcraft, etc…
Some of this project is definitely cool and usable. It's just that it will probably never become (by my hand at least) the insanely awesome thing that it was once fated to be. I had big ideas for this project, and I was planning on keeping them super-secret until the project's glorious release… uuuuntil I decided to stop spending my time developing a game within a game, and just develop a game instead.
Anyway, the least I can do is share what I've already got with the rest of the community and make a contribution.
What it does: AKA why it's cool
The Frontend
The front-end is cool. It gets turtles to automatically register on the server and it shows you a map and you can select the turtles and tell them where to go. The map scrolls. Also, if the turtle runs into a barrier, it will note that the barrier exists. It's good for a mess about if you like. The server keeps track of where the turtles are, etc, etc.
I think it's wasd to move the screen, arrows to move the cursor, and space to tell the turtle to go there.
Put all four files on a turtle and on a server, and boot them up (in whatever order you like ;)/>. It only works with one server/one turtle at a time, but it would be soooo easy to make it work for several turtles once you grok the code. I only made it one turtle for convenience really. There's nothing much new to write, just a few variables to shuffle about.
The backend
The backend, however, is much more cool and potentially very powerful, if you understand a bit more about lua.
It's basically a networking interface that creates packets and triggers callback functions. There is no packet forwarding, but from the sounds of things, that might come as part of the core functionality before too long.
Anyway, Turtles register on the server. You create a packet (with the provided functions, which wraps up a table you have created - template functions are also provided), and send it to the server. The packet always has a msgtype.
Now, on the server there are a bunch of trigger functions. When the server receives a packet, it checks the msgtype against a list (or several different lists, so you can create permissions, different groups, etc), and then calls the corresponding trigger function registered for that msgtype. So the trigger function could be registerturtle, turtlemoved (so the server knows if a turtle has moves), turtleoutoffuel (so the server knows if a turtle is out of fuel), etc, etc.
Then there is the same setup on the turtle, so it has a list of trigger functions, and can receive messages from servers. I've commented the source code so it shoudn't be too difficult to figure out what is going on. First read the server, then the turtle. easy3 might just need a little skim over.
The utility library
There's also a utility library called easy3 that I used for turtle movement. It's the first thing that I wrote and it has it's faults but it gets the job done. It keeps track of turtle location somehow, too I think. Lots of people probably write a file like this, though. You need it cause i use it for includes.
What could happen next?
It shouldn't be too hard to extend this so turtles can do more than just move. You could easily write a 'mine' trigger function or a 'build staircase' trigger function for example, and link it in to the fullfuncs function list in the turtle code. Make sure to use the easy3 move commands because they update the server with the turtle's movements. Making it work with multiple turtles should be easy, too.
My ideas about properly extending it were to implement packet forwarding, so turtles don't go out of range. Then I had some ideas about saving turtles positions to file every time it moves, so that if a chunk gets unloaded it isn't a problem. After that, build in a mining function, and create an interface that designates a section of land as 'mining area'. Then code in building functions: Have buildings to automate different processes, such as smelting, item sorting, mob farming, railway building, whatever. And if, say, all the chests of a item sorting place got full, the central server would be alerted and would schedule a new one to be created. That kind of stuff were my long-term goals.
Anyway, this code is yours. Use it as you see fit.
The code
Make sure to give the files the names below:
beserver http://pastebin.com/Sw6VBuqC
beturtle http://pastebin.com/B5fLtVq7
easy3 http://pastebin.com/j3CEQEzg
startup http://pastebin.com/UfxD2rcx
Put all the files in a server & all the files in a turtle. As it is, the program expects the turtle to be 2 spaces right of the server when it's spawned(i had a disk drive in-between them). The terminal and turtle should be facing opposite directions. The turtle should be facing 'past' the terminal.
To customise this, look for the easy3.init_values(x,y,z,dir) function in the server and turtle.
