If we're willing to keep it simple, sprite art is a hell of a lot easier than modeled 3D art. That starts to break down as soon as you want complicated/detailed animations, or to view things from more than a couple of fixed angles.
Sample number 3 with fixed cardinal-direction camera rotations is about as complicated as I would want to use a 2D engine for. For that or #2, we could just as easily use a 3D engine and get some useful structures on the side (organized scenegraph, hardware acceleration, ability to use shaders, etc). There are plenty of 3D engines that are not genre-specific, and I don't think we need a very advanced one for this.
Another option is sprite characters and objects overlaid on 3D large-scale structures (walls and the landscape). This allows you to get some of the 3D camera flexibility.
Also, I think we should do multiplayer at some point. If we made it work, we would kill. We don't have to do it right away, but we should code with future multiplayer in mind.
Well, An easy way to to it initially would be in the vein of Nethack's HEARSE system, for sharing bones files.
I have to agree on the importance of collaborative fortress playing. Although it would be very difficult, it would make for serious potential. Also, to reiterate Scott, a good interface is absolutely crucial in realising this potential.
As for the graphics engine, one thing I'd like to note is that if we do start to work on alternatives, we should keep all of them around, and perhaps even offer the opportunity to switch between them in-game, or even use combined approaches.
What I would like to see: A two player Dorf where two players play on the same map. They don't build the same fortress, but each have their own fortress a few miles apart. For a while they won't compete, but when new dorfs turn up, the one with the nicer fortress might attract them. There wouldn't be open warfare between the fortresses, just an ongoing sturggle for prestige. And survival.
Another option is sprite characters and objects overlaid on 3D large-scale structures (walls and the landscape). This allows you to get some of the 3D camera flexibility.
That might work, but could get complicated when dealing with different levels added to the equation. A 2D square grid is probably the easiest to understand when scanning around to see what's going on.
Multiplayer might have to depend on different rules than single player, given how easy it is already to mess up a fortress with just one person in charge. Add mis-communication into the mix and you've got a recipe for dwarf disaster.
A multilayer zelda/nethack style adventurers mode would rock though. You wander between people's fortresses, raiding abandoned ones for items and killing whatever's infested the place.
I really want to get into this project, but I'm busy at the moment. Hopefully, when I'm not so busy any more, the project isn't so complicated I can't understand what is going on. I hope it's possible to look back through the history of the changes to see it grow bit by bit.
Yep, you can definitely review the project history; that's what GitHub is all about - have a look at the diagram here. Things are a little messy, because of some duplication of commits we've had, but it works quite well.
Okay, I took a look through the code, and would like to experiment a bit. However, I'm really struggling to install pygraph on my macbook. I'm trying really hard, but I just can't seem to work out all the steps it takes to get it on there.
Okay, I took a look through the code, and would like to experiment a bit. However, I'm really struggling to install pygraph on my macbook. I'm trying really hard, but I just can't seem to work out all the steps it takes to get it on there.
Your Mac should come with python already installed. Just install distribute like so.
$ curl -O http://python-distribute.org/distribute_setup.py $ sudo python distribute_setup.py Then do this. $ sudo easy_install python-graph-core If you want to be fancy, you can try to do the virtualenv stuff that's in my screencasts.
If it doesn't work, that's what you get for using a Mac. You will begin to see some of the reasons I despise OSX. Once you actually try to do actual development, their evil appears. Yeah, OSX is UNIX, but it has so many non-standard things that it's effectively all its own platform. Everything is crooked slightly differently from all other *NIXes, and you always have to jump through hoops to do things that will "just work" on every Linux or BSD distro.
If you can't make it go, try installing Ubuntu in VirtualBox. I know that will work.
I just spent four hours getting the hang of the code, and then making a mover that seeks high ground. The code is as ugly as hell, but I certainly learned and relearned a lot about python!
Not a chance! Now I've got it functioning, I really need to tidy it up. Actually, what I'm going to do now is use the same idea to add something that might be useful. You can see that code, once I work out how to use git hub properly. Scott's blog post should come in handy for that, I'm sure.
I'm indifferent when it comes to getters and setters. If there's extra stuff that needs to be done other than just changing the value of a variable, then a separate function is worthwhile.
To do what you want, you would have to pass some kind of reference in when creating your mover through which you can access the terrain updating method. Considering the update_terrain_surf method is a member of the Game, the most logical approach is to pass in a reference to the main Game object when creating one of your Movers.
To do what you want, you would have to pass some kind of reference in when creating your mover through which you can access the terrain updating method. Considering the update_terrain_surf method is a member of the Game, the most logical approach is probably to pass in a reference to the Game object when creating one of your Movers.
I wouldn't give a mover a reference to the game object. I would at most give him a reference to his current location.
It's definitely not a clean way of doing it. We should probably have the grid and the terrain be more strongly tied to one another, so that modifying the grid will cause the terrain to be updated properly. The terrain surface should probably be an aspect of the grid rather than the game in the first place.
@Luke If you explain what you're trying to do, I can refactor the code so you can do it without dodgy workarounds like what I mentioned before.
I've made a river. If the water reaches a part of the map and settles for a while, it deposits silt, and raises the height of the terrain. But this isn't updated on the display.
Okay, so the way I figure it, the terrain surface should offer a method for updating a single square rather than needing to update the entire surface. To make things as clean as possible, we should move the terrain surface related functions out of the main game. Where should they go? A new class?
Comments
Sample number 3 with fixed cardinal-direction camera rotations is about as complicated as I would want to use a 2D engine for. For that or #2, we could just as easily use a 3D engine and get some useful structures on the side (organized scenegraph, hardware acceleration, ability to use shaders, etc). There are plenty of 3D engines that are not genre-specific, and I don't think we need a very advanced one for this.
Another option is sprite characters and objects overlaid on 3D large-scale structures (walls and the landscape). This allows you to get some of the 3D camera flexibility.
Edit - Fixed quote.
As for the graphics engine, one thing I'd like to note is that if we do start to work on alternatives, we should keep all of them around, and perhaps even offer the opportunity to switch between them in-game, or even use combined approaches.
@Churba:
I think you quoted the wrong post there.
That might work, but could get complicated when dealing with different levels added to the equation. A 2D square grid is probably the easiest to understand when scanning around to see what's going on.
Multiplayer might have to depend on different rules than single player, given how easy it is already to mess up a fortress with just one person in charge. Add mis-communication into the mix and you've got a recipe for dwarf disaster.
A multilayer zelda/nethack style adventurers mode would rock though. You wander between people's fortresses, raiding abandoned ones for items and killing whatever's infested the place.
Things are a little messy, because of some duplication of commits we've had, but it works quite well.
$ curl -O http://python-distribute.org/distribute_setup.py$ sudo python distribute_setup.py
Then do this.
$ sudo easy_install python-graph-coreIf you want to be fancy, you can try to do the virtualenv stuff that's in my screencasts.
If it doesn't work, that's what you get for using a Mac. You will begin to see some of the reasons I despise OSX. Once you actually try to do actual development, their evil appears. Yeah, OSX is UNIX, but it has so many non-standard things that it's effectively all its own platform. Everything is crooked slightly differently from all other *NIXes, and you always have to jump through hoops to do things that will "just work" on every Linux or BSD distro.
If you can't make it go, try installing Ubuntu in VirtualBox. I know that will work.
python easy_install.py python-graph-core
Possible version incompatibility?[...stack dump...]
File "setup.py", line 8
except ImportError as ie:
^
SyntaxError: invalid syntax
Get Python 2.6
To do what you want, you would have to pass some kind of reference in when creating your mover through which you can access the terrain updating method. Considering the update_terrain_surf method is a member of the Game, the most logical approach is to pass in a reference to the main Game object when creating one of your Movers.
@Luke
If you explain what you're trying to do, I can refactor the code so you can do it without dodgy workarounds like what I mentioned before.