This forum is in permanent archive mode. Our new active community can be found here.

Geeknights Coding Club: Project D.O.R.F.

1356713

Comments

  • No, there isn't. There was meant to be, though, according to Rym's shit-talking.
  • Grid.get_node is rather strange, and it doesn't really make sense to have a method like that in the first place.
    Something like node_at(location) is required, and it needs to have constant-time access.
  • Grid.get_node is rather strange, and it doesn't really make sense to have a method like that in the first place.
    Something like node_at(location) is required, and it needs to have constant-time access.
    Yeah, I basically did the minimum code to not shit talk. The next step is to actually try to build an actual game feature. Once I have that, then the correct architecture will reveal itself.
  • Nonetheless, congrats on not shit-talking.
  • Nonetheless, congrats on not being Rym.
    Fixed it for you.
  • And I SHALL LEARN VISUAL BASIC!

    What? Dorf Fortress Project? Fuck it. Good Luck.
  • edited May 2010
    I'm working on some world-generation code. Right now, it's nothing more than a heightmap made by (poorly) simulated meteor strikes. This may expand with time.

    It's in my github fork of the project; if I understand how this works correctly, it's up to Scott to pull it into the main one.

    EDIT: Oh yeah, I also gave lackofcheese his constant-time location lookup (just a dictionary with whatever the default tuple hash is), made the grid larger than the viewable area, and enabled scrolling the viewable area with the arrow keys
    Post edited by Alex on
  • Unfortunately I'm not familiar with git or any other similar software. I'll can read and learn your code and see if there's anything I can do.

    We also need some way of organizing ourselves. What do we need first? Who will do what?
  • Such things will sort themselves out. I know I want to work on the more complex algorithms such as the pathfinding, though.
  • I'm working on some world-generation code. Right now, it's nothing more than a heightmap made by (poorly) simulated meteor strikes. This may expand with time.
    I was planning on using a Diamond-Square algorithm to do a fractal heightmap.
  • My ultimate goal re: world generation would be to have a series of filters that can be applied in sequence to generate height and other cell variables (temperature, moisture, iron content, whatever). The meteor mode is one. Diamond-square would be another. A river generator would be a third that could be applied on top of either (or both), and so on.

    So, yeah, go nuts.


  • It's in my github fork of the project; if I understand how this works correctly, it's up to Scott to pull it into the main one.
    This is correct, but first you have to give me a pull request. Then it goes in the queue from where I can merge it. It's not so important now, but it is necessary when there are multiple patches to merge from multiple sources.
  • Unfortunately I'm not familiar with git or any other similar software.
    There are plenty of web sites to teach you. If you want to keep it simple, and not get any fancy features of git, here's what you do.

    Go on Github, get a free account. Then fork the project.

    Next, go to your computer and do

    git clone git@github.com:whateverurltheygiveyou

    Then you'll have the code locally to work on. Work on it however you want.

    git add newfiles
    git commit
    git push

    That is the simplest workflow. However, you will need to learn more when it is time to merge new changes from the upstream and such and such.
    It's in my github fork of the project; if I understand how this works correctly, it's up to Scott to pull it into the main one.
    Yes, your changes are in the fork queue, I have to merge them, and such.

    I am going to write a blog post today explaining how to fancily setup the python dev environment using this project as an example, so that should help a lot of people.
  • Ok, I merged Alex's patches this morning, and then did a bunch of stuff like adding zooming and allowing you to change which elevation you are looking at and such.

    Some notes for people, Python is whitespace-sensitive. Everyone should be using 4 spaces as their indentation. No tab characters. If you want to make sure you are doing it right my vim configuration is also on GitHub for you to copy.
  • Fixed the coordinate system so the viewport behaves correctly and also some minor code cleaning (using constants instead of just the values, etc.)
  • edited May 2010
    I do prefer tabs on principle (one character equals one logical unit of indentation), but it's your project.
    Post edited by Alex on
  • edited May 2010
    I do prefer tabs on principle (one character == one logical unit of indentation), but it's your project.
    I think we decided that the project will follow PEP 8 (the industry standard on pythonic styling). Most python code is written using spacings because tabs, while they technically work, are rendered with different spacing on various editors. Usually when in doubt, one references PEP 8 for the proper format. Here is a pretty good article on the subject.
    Post edited by Andrew on
  • edited May 2010
    Looks like I've got a lot to learn. Time to hit the books. If I can get LwPy down in a week, I should be good to do some basics.

    On Ubuntu I need: Gedit , Python, Pygame, Python-Graph and what else?

    This is going to be like learning HTML all over again.
    Post edited by Omnutia on
  • Looks like I've got a lot to learn. Time to hit the books. If I can get LwPy down in a week, I should be good to do some basics.

    On Ubuntu I need: Vim, Python, Pygame, Python-Graph and what else?

    This is going to be like learning HTML all over again.
  • This might be a stupid question, but why are we not using Pygame for some of this stuff, or are we not at that stage? I honestly understand nothing right now, so pardon my somewhat below-basic level questions.
  • This might be a stupid question, but why are we not using Pygame for some of this stuff, or are we not at that stage? I honestly understand nothing right now, so pardon my somewhat below-basic level questions.
    Pygame is already being used to render all of our graphics (just some different shaded squares in a grid) and keyboard inputs.
  • Pygame is already being used to render all of our graphics (just some different shaded squares in a grid) and keyboard inputs.
    Ah, cool. In that case, apologies for my stupid question, and those in the future while I'm still learning things.
  • On Ubuntu I need:GEdit, Python, Pygame, Python-Graph and what else?
    One thing at a time.
  • I do prefer tabs on principle (one character equals one logical unit of indentation), but it's your project.
    Yeah, I like tabs better also for the same reason. However, pretty much every Python developer everywhere uses the four spaces, so I've learned to live with the spaces. The solution is to just configure your editor such that you don't even realize it's four spaces due to soft tabs.
  • edited May 2010
    Okay, here's a couple of basics I think would be handy:
    1) Improving Scrolling/Zooming - the scroll distance should scale with the level of zoom, and zooming should zoom into the center of the game and not into the corner. Key repeating is probably in order as well.
    2) Random mover - Something basic that will randomly traverse the grid squares in order to verify the graph structure.
    Post edited by lackofcheese on
  • edited May 2010
    Okay, here's a couple of basics I think would be handy:
    1) Improving Scrolling/Zooming - the scroll distance should scale with the level of zoom, and zooming should zoom into the center of the game and not into the corner. Key repeating is probably in order as well.
    2) Random mover - Something basic that will randomly traverse the grid squares in order to verify the graph structure.
    Stuff like this should probably start being placed on the issues tracker for the project. Generally they should be more detailed that what is currently presented though.
    Post edited by Andrew on
  • 2) isn't exactly an issue, but I do intend to code a basic random mover.
    1) requires some discussion as to how zoom and scroll ought to work. I've posted it in the issues now.
  • Good call cheese. I'll work on those next. I'm also going to update all the meta-files like README, TODO, COPYING, etc.

    Also, maybe I'll put in the docutils and such to auto-generate documentation.

    Django actually does a cool thing where the django website, djangoproject.com is actually included in django. I think we should make a web site for the project, doesn't have to be fancy, and put the code of that web site into the project itself. It's cool because, for example, you will update some code then update the documentation on the web site simultaneously. And if someone reverts to an old version, they will see the old web site with the old instructions.

    Everyone is cool with MIT License, right?
Sign In or Register to comment.