xor

Members
  • Content count

    724
  • Joined

  • Last visited

Community Reputation

516 Good

About xor

  • Rank
    Advanced Member
  1. Python Hello World...

    In Python 2.x print is a statement, in Python 3.x print is now a function. That code works with 2.x, and doesn't with 3.x, and to make it work you need the ()'s. ref: http://docs.python.org/release/3.0.1/whatsnew/3.0.html
  2. Worms server logic?

    Quote:Original post by Klapaucius The responses so far are all reasonable, but I recommend that you do whichever gets the game working with the least amount of *time* and *effort*. That probably means mostly client side, which has the additional advantage of making the logic easier to change and update later. Yes, this allows players to cheat with trivial effort, but if you get enough players for this to be an issue then you have already surpassed 99% of indie multiplayer projects. I think your biggest concern should be getting your game playable and released, and building enough of a user base so your servers don't stay completely empty. You can always worry about cheating later, once your game becomes a smashing success. I agree in principle. Polishing the game too soon is useless, it's just really necessary when the game becomes popular. However in this particular instance, I'd disagree. First a game's ascension to fame can be severely hampered by cheaters, and this particular form of cheating would be really nasty because given map control the client can just make a hole in it under the adversary until it hits water, it's an instant win, and it'd be very frustrating for the victims. Then there is the fact that by the time the game becomes popular, the core server code is buried under several layers of all the other protocols used to get the game off the ground, so it's going to be a significant bit more difficult to correct it then. If you really don't want to do this now, you can always mass ban ips of cheaters to mitigate this problem (this comes with it's own set of challenges though), and later on just sub-contract the work to fix the server.
  3. Worms server logic?

    The server must be in control of it, otherwise your going to get people cheating in your game. However, the server doesn't need to do all the work, just the one that affects gameplay. In the original worms the terrain was basically just used to calculate terrain collisions. This means you can use a monochromatic bitmap to do that on the server, and any other cosmetic changes can be calculated on the client side only (like charring the terrain for instance).
  4. This little demo seems to be getting popular, someone just came up with a port to flash with source code. http://wonderfl.net/c/yxe9
  5. Quote:Original post by LancerSolurus Great work! How long did it take you to make it? This isn't my work. I edited the OP the clear that up.
  6. You might not want to click this if you're working right now, it has the potential to waste a significant amount of your precious time. =) http://grantkot.com/MPM/Liquid.html <edit>PS: This isn't my work.</edit> http://wonderfl.net/c/yxe9 <edit2>Added flash port</edit2> [Edited by - xor on December 15, 2010 8:27:34 PM]
  7. [Python] Binary Manipulation

    You might find the module struct helpful.
  8. http://www.pygame.org/projects/9 Search here for "isometric", you'll find some libraries. http://www.pygame.org/tags/isometric Here you'll find isometric games made with pygame, maybe some of them were made with a library that might be of use to you. Also for higher requirements you might want to try out Panda3D, it's a general purpose engine but really easy to pick up.
  9. You're both right, I was under the impression the diagonals didn't need to be sorted that way. It's in the OP though, I missed it.
  10. A portrayal of heroism

    Quote:Original post by Wai What is the minimum design that achieves the purpose? How would you go about designing such a game? Start from the design goals that are more important and that have the largest scope, and progressively try conciliating the less important and with smaller scope ones without breaking the previous. The design goal at the very root of this graph, the one with the largest scope, and of the utmost importance, should be "Entertaining". Since everyone is giving game ideas, I'll go ahead and give one too. =) A small tactical robot with two projectile hooks on each harm (think spiderman), for rescue missions, sabotage, intelligence gathering, etc. Control the hooks with left and right mouse buttons, add in physically accurate movement in a 3d environment, add some more tools(camera, blowtorch, pliers, etc, no guns), give it a witty personality and you got yourself a hero.
  11. n = 5 0: 01234 1: 34012 2: 12340 3: 40123 4: 23401 Grid is generated by rotating the first line two spaces to the right on each following line. n = 6 0: 012345 1: 450123 2: 234501 3: 501234 <- 4: 345012 5: 123450 Grid is generated by using the same algorithm but line n/2 is rotated one extra space. Line n/2 always needs an extra rotation, where n/2 isn't integer this operation isn't necessary. An example: 0: 0123456 1: 5601234 2: 3456012 3: 1234560 4: 6012345 5: 4560123 6: 2345601 n/2 = 3.5 An extra rotation isn't necessary. Another example: 0: 01234567 1: 67012345 2: 45670123 3: 23456701 4: 70123456 <- 5: 56701234 6: 34567012 7: 12345670 n/2 = 4 Extra rotation necessary on line 4
  12. Since there are only half a dozen players you can just keep a table of all the players with a score. This score is calculated by the client himself when it joins the server, the score is the sum of all the pings to all current players, the smaller the value the better. That score is stored in the server, each time a player enters the player calculates his score, sends it to the server and receives the full scores list from the server. When the server leaves whomever is on top becomes the new server and starts managing the scores list himself. Notes: There is the possibility for abuse since the score is calculated client-side. If you want to avoid this you have to settle for an approximation for the best server, you won't be able to calculate the client with the best overall latency for the reasons Matias Goldberg specified.
  13. Short answer: A bit of both might be best. In strategy games makes more sense to have all the decisions point towards a common goal. So, if you add independent AI for each unit, it would seem reasonable for the AI at times to consider it's own best interest rather then the interest of the CPU player, for instance, retreating before dying when it's death would produce a better outcome. And this behaviour alone doesn't make much sense. It would make more sense to have a single AI entity decide what each unit does in order to achieve this common goal. You might however spice things up a bit. For instance, you might introduce the concept of fearful units that will retreat if they face a particularly scary opponent. This would play out more like a characteristic of that particular unit, rather then an individual decision, and the CPU player would just have to make it's decisions bearing that characteristic in mind.
  14. Recruiters stop reading your resume on the third page not because they're lazy but because it shows you either don't know what skills are required/relevant for the job, or you don't care. You can summarize the skills you have that are required/relevant for almost every job in a single page, any other unnecessary skills mentioned are just there showing you don't know what the job is about. It also shows you can't decrease the size of the fonts on a word processor, which is always a bad sign.
  15. A* for multiple units

    Given that tower defense maps are usually small and are most of the time static, it may pay off to create a table of paths from each point in the map to the end. Each time a gamer places a new tower you'll need to update the paths on the table that use that tile, and you won't be able to have moving towers (or any other path blocking object for that matter) in your game, but you'll be able to add has many creatures as you want to the map without worrying about performance.