76
MegaGlest / Re: New beta very soon! Any known showstopper ?
« on: 25 November 2014, 14:19:39 »
il be hiding in IRC for testing Titi, So let's get some games going.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
77
Closed feature requests / Re: [done please test]health bars (old topic relaunch!)
« on: 24 November 2014, 10:25:49 »
I agree,Numbers of commands would reduce game clarity, and good players should have a sense of how many units are being produced anyways.
I tried the latest git out, it looks really great now!, Loves this feature. Still need to test it some more.
PS:Titi , Have you forgotten to turn on IRC again?
I tried the latest git out, it looks really great now!, Loves this feature. Still need to test it some more.
PS:Titi , Have you forgotten to turn on IRC again?
78
Closed feature requests / Re: [partly done]health bars (old topic relaunch!)
« on: 22 November 2014, 02:59:02 »
I just Tried this today looking SOOO good!, It is really food for the eyes, But the version i just built 03:55 22-11-14 There is still healthbars on the ground, is this because it is not changed yet? or is it still in suggestion mode?.
79
Closed feature requests / Re: Better health bars.
« on: 21 November 2014, 14:03:46 »
Awesome, Just awesome!
80
MegaGlest / Re: The idea Going to change history MG
« on: 10 November 2014, 19:38:03 »The main difficulty comes from cheat prevention. It's very difficult because someone can modify the source code to cheat.
With that said, cheating is an issue for even large closed source games. I think it's reasonable to simply ignore the cheating (there's already systems in place that would prevent the easiest methods of cheating) and simply remove any cheating accounts that might show up.
So in summary, we'd need to
- Create ranking server that stores rankings online and provides the means to communicate with this server to authorized master servers.
- Master server must have some private key to show that it is trustworthy.
- After completion of games, master server sends the score change for all registered players. Alternatively, master server sends the data it already sends but with account information and the play.mg site calculates scoring and ranking.
- Change in scoring depends on factors such as game configuration and other player's ranks. Ranks are simply obtained by getting certain scores (like how the ranks on this forum depend on posts).
The security of this is important to keep in mind, since if the system gets easily and uncontrollably gamed, then the entire ranking system becomes worthless.
Sample scoring system
- Use score from games (and the game's scoring system can/should be adjusted to better reflect skill). I implicitly refer to this score from now on.
- Games against AI where there are no humans on the AI's team are divided by 2h where h is the number of humans played against the AI and multiplied by the number of AI and the multiplier of the AI. So 2 humans versus 2 AIs with a 1.5 multiplier (CPU-ultra) is a score multiplier of (2 AI * 1.5 multiplier) / 22 humans = 0.75.
- Games where the human has AI on their team are further divided by the multiplier of that AI plus one. The plus one is to prevent increasing the score when humans have weaker AI on their team. So stronger AI teammate = score penalty. This effect stacks. For example, if you have a two normal AIs on your team (1.0 multiplier), your score is divided by 2 twice, resulting in a score multiplier of 0.25.
- Teams get the average AI-on-your-team score penalty of all other teams + 1. So if the above example of a team with two normal AIs was playing against a different team with no AIs, then the team with no AIs gets the 0.25 plus 1 = 1.25.
- Games against humans are ultimately going to depend on how hard it is to get ranks, but something like multiplying by the difference in your ranks divided by the number of ranks plus one seems like a quick approach. Thus, it's beneficial to play against higher ranked players and worse to play against lower ranked players. For example, if a rank 2 player plays against a rank 5 player and there are 10 ranks, that player gets a score multiplier of (5 - 2) / 10 + 1 = 1.3. On the other hand, the rank 5 player gets (2 - 5) / 10 + 1 = 0.7.
- To handle the case of teams of humans versus teams of humans, we use the algorithm from the above point and apply it against all other players. For your team, we take the average of comparing you against players not on your team and divide that by the average of comparing you against other players on your team. So if your team average compared to you is 0.5 (implying that your teammates are a lower rank than you) and the averages of players not on your team compared to you is 1.5 (implying they're a higher rank than you), you'll get 1.5 / 0.5 = 3.
- To make up for mismatched team sizes, if one team has less players than any other team, they get an added bonus of 0.25 * team size difference. For example, if there's game of 3 on 1, the player who is on the solo team gets a bonus of 0.25 * 2 = 0.5 added to his score multiplier.
- And of course, most importantly, winning doubles your score multiplier. Losing halves it. So all else equal, winners get 4 times the points that losers get. Big benefit for winning, but not too bad for losers. To increase the dependence on the multipliers and game score, this difference could be increased.
Example game with this scoring:
Player Rank Team Game score Alice 2 1 10,000 Bob 3 1 12,000 Carol 4 2 20,000 AI (0.5 multiplier) N/A 2 Doesn't matter
Assume that Carol beat Alice and Bob. Assume there is 10 ranks.
Carol's score: Since Carol has an AI on her team, her score is divided by the AI multiplier + 1. So her score multiplier is now 0.66 (1/ (0.5 multiplier + 1)). The difference in her score from Alice is (2 - 4) / 10 + 1 = 0.8 and the difference in her score from Bob is (2 - 3) / 10 + 1 = 0.9. Average of this is 0.85. So now her cumulative score multiplier is 0.66 * 0.85 = 0.56. She won, so her multiplier is doubled, making it 1.12. She gets 1.12 * 20,000 = 22,400 rank points.
Alice's score: The difference in Alice's score from Bob is (3 - 2) / 10 + 1 = 1.1. The difference from Carol's score is (4 - 2) / 10 + 1 = 1.2. The average of players on her team is obviously 1.1 and the obvious of players not on her team is 1.2. We then divide the players not on her team by those on her team, 1.2 / 1.1 = 1.09. Alice's team doesn't have an AI. The AI penalty of the only other team was 0.66, so this team gets a multiplier of 1.66 making the cumulative score multiplier 1.09 * 1.66 = 1.81. Alice lost, so her multiplier is halved to 0.91. She gets 0.91 * 10,000 = 9,100 rank points.
Bob's calculation is similar, so won't be shown here.
Points to ponder
- Good thing about a system like this is that fair games will result in getting the same number of rank points as the number of game points. Multipliers only come into play when the game is unbalanced (or when we play against the CPU, since the CPU is so brain dead).
- Lots of potential for cool features such as achievements, where performing certain tasks gets more points (pre-multiplier). This is very difficult because achievements feel like something that should be moddable, yet we'd need to be able to approve achievements to prevent people from creating mods that have easy to obtain achievements that give a ton of points. Alternatively, achievements would be mod-neutral and be dependent on things like killing multiple enemies in a short period of time, killing enemies with a variety of different attacks (ie, using a variance of attacks), or killing enemies with an effective attack type for the target's armor type.
- Rank size and number of points required to reach is is going to depend heavily on the kinds of scores players easily get. Eyeballing past games, it looks like around 20,000 points is common for winners of medium length games. Something like 20,000 * 1.5rank + 1 creates a nice curve for 10 ranks. That creates an achievable first rank for new players. First rank needs 60,000, which is only 2 wins for a good player in medium length games (recall that wins get double points), but more for a novice -- new players will probably have multipliers due to their low rank, though. Achieving the top rank (rank 10) needs 1,729,951 points (about 45 wins at 20,000 game points per win).
- However, having such small ranks would inflate the rank difference multipliers. Perhaps better to have fewer large ranks. Perhaps also increase the loss penalty so that you have to win to rank up (and thus must be a good player to get a higher rank).
- Perhaps size difference should use a multiplier and not add a percentage to our running multiplier.
- Penalty/bonus from having AI teammates seems too severe.
For anti cheating only accept a mastersever hardcoded value (fx latest stable CRC code (defined in The master server).
Since registering and stats regristation only happens when you logged in this solves the cheating problem. (also record what tech tree was played).
Also since Archivement would be saved on the master server you would need to set uo your own master server to define archivements.. Not a unfair requirement imo.
81
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 29 October 2014, 10:35:24 »
okay, Firsly i would like to add my personal opinion.
GO AWAY WITH RINGS! I HATE RINGS/CIRCLE!, They are Clumsy Feels like you are playing a board games and plain do not WORK!.
<------------> this part was removed by titi
Now, For the Health bars filling up space, we could maek a option for showing only unit health witch is not 100% and we could hold down Alt key to show All unit healthbars. Options like that is nice!
And i really like what ive seen so far, is it in GIT?. Id like to test these changes and see how it feels ingame!
GO AWAY WITH RINGS! I HATE RINGS/CIRCLE!, They are Clumsy Feels like you are playing a board games and plain do not WORK!.
<------------> this part was removed by titi
Now, For the Health bars filling up space, we could maek a option for showing only unit health witch is not 100% and we could hold down Alt key to show All unit healthbars. Options like that is nice!
And i really like what ive seen so far, is it in GIT?. Id like to test these changes and see how it feels ingame!
82
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 27 October 2014, 05:07:34 »
Awesome, is this in GIT?, This looks really nice, Screenshot two is really good.
83
MegaGlest / Re: General view on new features
« on: 31 July 2014, 16:01:49 »
Sure it all sounds like a good idea, but im so afraid of breaking anything in git that i avoid using it because i will not be able to fix it. Im willing to do work on this by forking the MG pack this way i could keep it updated with new features a mod that is based on the megapack (if titi is okay with this).
Downloadable from the modcenter.
The Goal of MegaPackAdvanced is as follows.
1.Getting new features implemented in use.
2.Game balanceing
Id really like to do this. but as i don't play alot of MG myself it's useless if other people dont at least support the idea.
Downloadable from the modcenter.
The Goal of MegaPackAdvanced is as follows.
1.Getting new features implemented in use.
2.Game balanceing
Id really like to do this. but as i don't play alot of MG myself it's useless if other people dont at least support the idea.
84
MegaGlest / Re: General view on new features
« on: 30 July 2014, 22:20:01 »I like the idea of an improved megapack (with the new visual features). Would require no balancing if its just visual.
It will also still be borring as s'**
85
MegaGlest / Re: General view on new features
« on: 29 July 2014, 22:30:36 »
I agree, I think that is a too strict policy here, We have wished for more developers for such a long time and now that we are getting contributions you already think its too much?.
No. This is good and for now we should let most stable clean additions in, this is good. And to be honest, Megaglest is kinda borring now, Just long range units shooting at eachother techincally the engine is moving forward, but we need MORE momentum, we need to praise each and everyone addition we get. Im not saying we should not value quality and the line needs to be drawn somewhere but not here.
And since the codebase is pretty stable right now we should let all additions get in (except the worst coded).
No. This is good and for now we should let most stable clean additions in, this is good. And to be honest, Megaglest is kinda borring now, Just long range units shooting at eachother techincally the engine is moving forward, but we need MORE momentum, we need to praise each and everyone addition we get. Im not saying we should not value quality and the line needs to be drawn somewhere but not here.
And since the codebase is pretty stable right now we should let all additions get in (except the worst coded).
86
MegaGlest / Re: Angle and Vectors of standard camera.
« on: 29 July 2014, 17:20:21 »Angle: 30° (-60° of parallel to ground)
Height:20 (cells) (but this can be changed in the map editor)
offset from starting position: 8 (cells)
or what do you want to know?
This was it, Thanks, You helped me immensely with this!. Really Really thanks a bunch!
87
Feature requests / Re: Tags
« on: 29 July 2014, 15:45:02 »What John.d.h says is the first thing that convinces me. I am just not sure how many changes this will need.
The sad thing is that what i said was the exact same thing as Jhon.D, Just in another way...
Im happy Jhon. D got the point across but im a little sad it's so difficult to communicate in general.
88
Feature requests / Re: Tags
« on: 28 July 2014, 00:47:20 »
and not creating the function in the first place is suposed to help?. Classifying a unit based on unit-type is important.
I will bet you money that this function is going to be worth GOLD.
i know that as a creator it feels good to have control with what's going on but dont strangle this man, Just because you can't see the need or use for it, others can, and we can use it.
I will bet you money that this function is going to be worth GOLD.
i know that as a creator it feels good to have control with what's going on but dont strangle this man, Just because you can't see the need or use for it, others can, and we can use it.
89
Feature requests / Re: Tags
« on: 28 July 2014, 00:33:03 »
No, They can work like that, but the purpose is classifying units.
90
Feature requests / Re: Tags
« on: 23 July 2014, 10:45:49 »
I thought this would be for attack boosts or upgrades and not for attacks because the things your descripe there can be done already. Its called attack-multiplier and uses the armor of the units. You can also say that the unit will only take half the damage or something. Maybe we could add that you can upgrade all units with a specific armor-type. Or can tags and attack-multiplier exists at once? This is not that simple I think, because we need to plan exactly for which things we use those tags.
I think having both could be possible but would confuse players.
This is NOT The same. This makes unit's untargetable by the unit and the damage is simply not applied to units with tags.
Armor is for migation of damage across different units and making some units stronger even tho they have different health portions.
Basically Armor makes a unit Tougher
What i suggest makes you unable to hit a unit.
Again it is NOT the same
91
Feature requests / Re: [testing] Allow to join matches (faction controlled by AI when no player)
« on: 22 July 2014, 16:01:05 »
the 1 option is good. And please do not base the key or require a IP adress for connection purposes. It's most likely you are getting a new ip-adress if you get a full disconnect.
93
Feature requests / Re: Tags
« on: 22 July 2014, 15:24:20 »
im not sure it's entirely the same, but basically, removing and adding targets to a skill, for example. a skill that does acid damage does not effect Buildings but does effect biological units, but not fx mechanical units. so 3 tags named "Building" "Mechanical" "biological"
a attack skill.
<valid-targets target"=biological">
<non-valid-targets target="building""mechanical">
Does this makes sense.
a attack skill.
<valid-targets target"=biological">
<non-valid-targets target="building""mechanical">
Does this makes sense.
94
Feature requests / Re: Tags
« on: 22 July 2014, 14:45:21 »
I *** LOVE IT!.
I miss this! This feature is so nessesary, and should work for targeting too.
i vote yes.
A way to show what tags a Building has would be nice too.(optionable on a per Building per tag basis). so you can chose only to show some tags. so you can create mechanics that rely on tags and use tags for show and hidden mechanics.
I miss this! This feature is so nessesary, and should work for targeting too.
i vote yes.
A way to show what tags a Building has would be nice too.(optionable on a per Building per tag basis). so you can chose only to show some tags. so you can create mechanics that rely on tags and use tags for show and hidden mechanics.
95
Feature requests / Re: Rename attack boosts
« on: 22 July 2014, 14:38:26 »
i would have to agree on this, This is a oddity that it's called like this in it's current form.
I vote yes
on a rename
I vote yes
on a rename
96
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 21 July 2014, 13:38:00 »I think that health bars would be better off as a *player* option, not a mod option.
At least make it both then, so that a mod can specify the default style of selection in the glest.ini file.
97
Closed feature requests / Re: Multi shots
« on: 12 July 2014, 01:21:52 »
Super interesting Topic, Il look inhere, and perhaps sneak in a thought or two later. (it's late right now).
98
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 12 July 2014, 01:19:39 »
A interesting idea, but what exactly would you mod in a health bar?. The colours?, That could be added in the tag/health tag options file.
Anyhow, Yes for now just a basic floating healthbar over units (buildings are also units btw).( i still like the bars inside be chopped up like in the video in small healthblocks).
Thanks for working on this FreshDumbledore
Anyhow, Yes for now just a basic floating healthbar over units (buildings are also units btw).( i still like the bars inside be chopped up like in the video in small healthblocks).
Thanks for working on this FreshDumbledore
99
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 11 July 2014, 23:14:09 »
I agree, It's also a good starting point for adjusting how it should look "baseline" i recommend a bar like in the videos with small fractions of hp.
100
Closed feature requests / Re: health bars (old topic relaunch!)
« on: 9 July 2014, 19:51:22 »
These are mana and shield for these paticular units.
but yes, Im just starting with a Vision, Then we can take the implementation one step at a time.
but yes, Im just starting with a Vision, Then we can take the implementation one step at a time
.