Entangled - 1.0.0
Make the longest chain in this challenging puzzle game.
Game comes with source code. The game idea is not mine, I got it from a game that comes embedded in google chrome with a similar name.
Your goal is to get as many points as possible. Points are awarded by placing tiles and creating large paths. The more paths you chain in one tile placement, the more points you get. There is a spare tile you can swap out at the bottom left if you're in a pickle (just click on it to swap).
- Left Click - Places the tile as shown
- Right Click - Rotates the tile
The exe to play is in the folder EV1.0.0 and it is called run.exe.
If you want, make a shortcut outside of the EV1.0.0 folder that points to run.exe.
Pygame.org account Comments
Mekire 2013-08-02 02:48:03
Wow... you have certainly been busy. A few comments: firstly the game is pretty neat. I had never played or heard of the original so I did enjoy it. No offense intended however, but your coding needs a little attention. Firstly you are using way too many star imports (the preferred number would be zero, though some people (not I) would forgive you if you used one). Also there is way too much flying around in the global scope. These two habits combined will make it impossible in a program even slightly bigger than this to tell where variable names are coming from. You should never need to hunt down a variable. The main game loop should be refactored into several functions (this alone would clean up your namespace tremendously). There also appear to be a number of large inefficient if blocks that could likely be refactored into more concise, better performing loops.
Criticism aside, very nice work,
Jeremy Gagnier 2013-08-06 03:06:27
I made this game two years ago. More recent games use much less global variables and more useful functions for the main loop.
I will however defend my use of star imports. When memory isn't an issue, I don't really care about having more functions than I need. I would hate to make a giant list of imports so that I get all of the functions I need. I understand that it seems like bad practise, but python has a really ugly importing system to begin with (from my knowledge).
Also, if blocks are just as efficient as loops achieving the same effects in terms of run speed right? I mean if you break it down to assembly the only difference is that the loop takes up less memory.
Mekire 2013-08-06 07:14:23
You wouldn't need to have a huge list of imports. You just need to import normally and qualify variables properly. The pain of this can be mitigated by doing things like `import pygame as pg`. The issue here is not memory; it is code readability (not to mention the chance of accidentally overwriting a name). In multi-module programs it becomes impossible to know what module a name came from if there are multiple star imports. `from pygame import *` alone introduces 314 names to the global scope. As for huge if blocks it is a matter of code readability and "don't repeat yourself." You can code much more generalized "switch cases" using dictionaries than long bulky if/elif/else blocks. Yes, the speed differences are probably negligible. I'm not saying don't use if/elif/else blocks; just that when they start to get long it is often time to reevaluate the approach.
Jeremy Gagnier 2013-08-06 23:16:59
I see what you mean now. I use import * on pygame because I hate how ugly pygame.anything looks, plus there's the obvious inconvenience of having to use pygame. everywhere. It seems like python having import * increases readability when you don't care where the function came from. I have had to deal with overwriting function names in the past, but it was hardly a detriment.
Daniel Monteiro Basso 2013-08-12 20:38:27
Hey Jeremy, nice work. I took your code and made some improvements, as the ones suggested by Mekire. There is still plenty of room for more clean-ups, but I did what my time allowed. I hope you find it instructive. You can follow the history of the changes in this repository: https://github.com/dmbasso/ent...