Jump to content
EleTD.com

MagicalHacker

Registered
  • Content Count

    28
  • Joined

  • Last visited

About MagicalHacker

  • Rank
    Java Programmer

Recent Profile Visitors

757 profile views
  1. My apologies for not posting this earlier, last week has been busy (and me being sick didn't help either). Attached is a list of 500 tower distributions fulfilling the following requirements: - each tower has a damage element (composite isn't used) and a damage type (splash or single target); - each 4-build has a covering element pair in both single target and splash towers, as per Cisz's suggestion; - each element has exactly four towers dealing damage of that element: one single target dual, one splash dual, one single target triple, and one splash triple; - each 4-build relies on as much elements for damage as logically possible (for 9 out of 15 builds, two elements are used as a single-target covering pair, and *the other two* are used as a splash covering pair; for the remaining 6 builds like ldwn, three pairs (lw, wn, nl) are covering (at least one single target and at least one splash), with the remaining element (darkness) not relied on for damage). These last two requirements were added because Cisz's requirement on its own permits far too many valid solutions, prompting me to find the "best" solutions among them (whatever that might mean). As you can see, this problem isn't solved yet - even with these additional niceness properties, there are still over 500 solutions. (This list of 500 solutions isn't complete at all - I just stopped generating more solutions at 500, given that I have absolutely no idea how many solutions there are in total and enumerating the complete list is *slow*. There could be ten thousand more solutions for all I know.) So, if you can think of more nice properties for tower distributions to have, please tell me and I'll try to reduce the solution space further. As a general rule, hard requirements on the distributions are relatively easy to solve, but optimizations ("please select the distribution that is as close as possible to the current distribution") are hard, so avoid those until nobody can think of any more hard requirements. eletd_tower_distribution_solutions_1.txt
  2. After two extended brainstorm sessions between holepercent and me, we arrived at the following idea, as an independent alternative to holepercent's original system: Overall concept Up to 8 players, free for all, possibly with fog. The core objective is to capture the other players' elements. Income Income is fixed - players receive a certain amount of gold per time unit, the amount increasing exponentially over time like it effectively does in TD mode. Interest may or may not be active. Creep kills do not generate gold. Elements Players start with a certain set of elements (say 4 per player with 8 players in the game, up to 10 per player with 2 players), but never with all 6 elements. Elements are probably distributed equally such that all elements are equally available - or maybe not, as to introduce intentional choke points. When a player is successfully attacked (he loses enough lives in a small enough time frame - more on that below) he loses an element to the attacking player; this does not impact his current towers, but it disables him from building (or upgrading) additional towers using that element. Once a player loses all his elements, he has lost the game. Elements are lost and gained without breaking the tier system; that is, if the defending player currently has tier 1, 2, and 3 of an element while the attacker only has tier 1, after the exchange they both end up with access to tier 1 and 2 of that element, and no access to tier 3. Attacking Players can send creeps belonging to the elements they possess to any other player. Non-elemental creeps are available to anybody, but they are inferior to elemental creeps (maybe they take 125% damage from all attacks rather than 75%?) - unless the attacking player possesses all six elements, in which case non-elemental creeps are superior to elemental creeps instead. Possessing elements in tier 2 or 3 makes it possible to send tougher creeps of that element for the same cost, as well as creeps with abilities (fast, undead, healing, mechanical). How the abilities are to be distributed among the tiers remains to be seen - or maybe tier 3 enables sending creeps with multiple abilities? Attacks are sent in waves of 30, just like in TD. An attack wave can be bought with as much or as little gold as a player wants, with more gold resulting in stronger creeps. A wave has to spawn completely before a new attack against the defending player can activate; attacks sent until that point are queued. The attack queues against a player may or may not be publicly visible. When too many creeps get through a player's defenses during a sufficiently short time frame, that player loses an element. The defender loses the element he has had the longest (the starting elements are ordered randomly at the start), and the attacker gains that element. How the attacker is decided when creeps belong to multiple attackers are getting through remains to be seen, but I'm confident I can work out a fair algorithm - I'll spare the rest of you the technical details though. Arbitrary limitations There should probably be a limit on the number of attacking waves a player may be sending at any time, including the queued attacks. This keeps players from blocking the game by sending very cheap attacks by the dozens. Players may be able to cancel their current attacks (maybe only queued ones) to free up attack slots, but this does not get them any refund. Queued attack waves may be unleashed in order of strength - this makes it impossible for a player to be mostly unattackable by having lots of very weak attacks inbound. If a player loses an element, all creeps still attacking him (as well as queued waves) are destroyed. This protects a player from being completely owned by a strong attack, making it less attractive to just save money to send a single very large wave. Doubts and considerations I'm not quite sure this system provides enough incentive for players to attack each other. I suspect this system encourages players to defend only, interest farming until they are capable to send a single crushing attack that the defender won't be able to defeat. Maybe income should be tied to element ownership in some way? An alternative we're considering is to disjoin the defense budget from the offense budget, by making attacking cost lumber rather than gold or something similar. This will certainly stop people from spending everything on defense, but it also removes the tactical dilemma of balancing offense and defense. What we'd really want is a way to encourage attacking while keeping the balance issue open and delicate, but the only way we could think of to accomplish that is by connecting some immediate benefit to sending the creeps (without regard for their effectiveness) - which has the serious side effect of making sending creeps feel like buying something, rather than attacking. For instance, in line tower wars, by sending a sheep to a player I'm not attacking anything - I'm buying 1 income for 5 gold, and the fact that sheep spawn in my opponent's maze is entirely irrelevant to me. If someone can think of a way out of this paradox, please let us know.
  3. We played race mode in this game, and two players survived until the end, but neither got a message saying they won the race. Also, the game didn't finish (nobody was victorious or defeated). Only when one of the surviving players left did the remaining player (the race winner) get a "you won" message. etd_4.1_bugged_race_mode.w3g
  4. We might want to use the following rule: When claiming a rematch after a disconnect, you start with the number of lives you had when you got disconnected. This discourages 'disconnect cheating': disconnecting on purpose when your early-game performance wasn't as good as you would have liked. We'll probably need to play with a special tournament version of the map to make this rule possible. Disclaimer: this is just a random thought, i didn't think it through.
  5. I agree with holepercent. A nice feature, but not a priority. Also, I don't think the warcraft engine directly supports such a thing, so it may be a bitch to code.
  6. Which is exactly the difference between tower defense and tower wars. Tower defense is a game where you defend against units spawned by the game, whereas in tower wars the units are spawned by opposing players. Note that i was talking specifically about tower defense games in the first line of my previous post.
  7. Element TD is the only tower defense map I know that stays interesting after beating it twice. I occasionally play tower wars maps, though. The classical Tower Wars 1.9 is my favorite, along with Forbidden Element Tower Wars. I'll kick anyone who mentions either Mafarazzo TD or Line Tower Wars
  8. If your internet connection is behind a router (which is usually the case if multiple computers can use the same internet connection) than you really don't need a firewall at all. Antivirus software is still advisable though, if you use Windows that is.
  9. This may be due to the fact that eletd has a weird property: it allows both for one-on-one games, and for games with more players. Most standard tournament systems are designed for either of those game types, not for the combination. Also, never assume something doesn't work because the rest of the world never thought about it. I found that to be a rather poor assumption Of course. Well, my system isn't perfect. It's designed to be a good balance between fairness and player understandability. A system like yours may be somewhat fairer, but: [*]Harder to explain to players - "You play round 1, we do the math, based on the math you end up in some round 2 game, we do more math, and you may get in the finals."[/*:m:31lczman] [*]It scales poorly with a small number of rounds. Your system greatly depends on the number of preliminary rounds for fairness; it works wonders with 5 preliminary rounds, but poorly with only two. Mine gets slightly better with more rounds as well, but two rounds is good enough too (and arguably, so is one round, if you were desperate).[/*:m:31lczman] Random? Well, not completely random; my tool tries to keep the number of 2nd-round-1st-place players and 2nd-round-2nd-place players in a semifinal game equal.
  10. I read your discussion on IRC; too bad I couldn't be there. Note that my tool makes some assumptions specific to the ruleset I designed: specifically, that the top TWO players of the second round get through. Now, if you wish to add the absolute rule that no two players ever face each other twice in the preliminaries, we can devise the following: In each second-round game, each player in the game must have played in a different game in the first round. Which means: The number of players in a game must be smaller or equal to the number of games. Or, mathematically: Definitions: P == number of players G == number of games per round F == number of players in the finals (P / G) <= G P <= G^2 round_up(sqrt(P)) <= G The top TWO players of the second round get through. Therefore, 2 finalists per game. 2 * G = F Therefore, round_up(sqrt(P)) <= 0.5 * F F >= 2 * round_up(sqrt(P)) The number of finalists is larger than or equal to twice the square root of the number of players, rounded up. So yes, it scales poorly to the lower regions. If you want to use it with less players, you either have to loosen up the rule that no two players should battle twice, or play small games in which only ONE player gets though.
  11. Fixed. The link you posted is still broken, as you made a choice in step 3 that shouldn't have been possible at all.
  12. Actually, i suspect the lag stops when there is only one player left in each creep team (red OR blue, teal OR purple, yellow OR orange, pink OR green). I didn't test it yet though.
  13. I think the 1-element towers should be as simple as possible. Single-target or splash, mirroring arrows and cannons. Anything more complicated fits better on two- or three-element towers.
  14. Yes, it should. It is a known bug that will be fixed in the next version.
×
×
  • Create New...