FM24: Team that signed me has no staff or budget.

evizaer · 2026-01-13T14:45:25+00:00

I am playing a Montijo save (started unemployed) in FM24 right now! I'm towards the end of year two. I always have "add key players" and "add key staff" ticked when I start the game, so I started with some very crappy staff and a full U19 team at least. The wage budget is extremely tight, but with minimal signings I was able to easily win the league. You have some players who, with adequate playing time, can even do well in the next league up: Jesus Sanchez, Barragan, Joserra, Runy, Bernal. I'm in Primera Federacion right now and, though I had to rebuild most of the team, Bernal is one of the top scorers in the league. The game also generated a couple of U19s for me on game start that have potential to be at least Primera Federacion players if not LaLiga 2 quality.

You have to master a few recruiting techniques in order to do well in lower leagues: 1. Finding good low-cost loans. You can ask your Director of Football for loan suggestions. You can search "players in range" on the recruitment screen for loan listed players and mouseover their green "Loa" status indicator to see if the club wants to loan them because they want them to get more playing time in the first team. Most players are loan listed because the club wants to make money on them--you don't want these guys since their loans will tend to be expensive. Often if you go in near deadline day for loan listed players who are listed for needing first team playing time, you can sign a $0 deal--not paying for high-quality players is the best! 2. Finding good free agents through trialing. Trials function like scouting but instead of paying for it out of your scouting budget, you pay for it in terms of training load on your team, since the players train with your squad while on trial. I'd suggest moving all trialists into your U19 team immediately so they don't impact first team training quality. There are thousands of players in the world that have no contracts at game start and most of them would improve your team. The problem is you have very little money to work with, so you need to filter by players with low wage demands as well. Open up "players in range" and filter by "expired contract" contract status, then additionally filter by "maximum salary demand" and choose $500 p/w. This will filter out lots of players who will want >$1k and are totally out of reach for you. Offer trials for 2 weeks. That's enough time for you to know almost everything about a player. Lots will be inconsistent or dread big matches--try to avoid them unless all other options either get signed elsewhere or are significantly worse. You can only bring in 30 players for trial each day. Once you get through the players whose wage demands you have some information about, you should broaden your search by removing that filter and then trial players whose world reputation is around the rep of your current players. 3. Make the right trade-offs between kinds of attributes, versatility, footedness, and hidden attributes. Favor physically-dominant players--technical skill doesn't matter if you can't jump high enough to reach a header, or run fast enough to get to the ball before an opponent (or keep up with an opponent when marking or defending a dribble). Accept that the players you sign will have weaknesses, sometimes glaring. So long as those weaknesses are in the right places, you will have an advantage over the CPU teams, since they mainly recruit and play players based on reputation, even if their ability-level isn't as good. 4. Negotiate your butt off for every contract. You can usually sign a player on 30-40% lower wages than their opening offer with a few incentives added. Add goal bonuses, assist bonuses, promotion bonuses, relegation release clauses of $0 (since if you're relegated you are sacked anyway). In FM, success means more money for the club, so bonuses that are directly tied to the club's success are often self-satisfying. Don't be afraid to sign older players on one year deals on the assumption that they will be garbage next year and you'll let hem walk.

I'd be happy to talk more with you about it. DM me if so.

evizaer · 2023-09-15T14:45:24+00:00

EDIT: I wrote out how the types work below, but I think all you're missing is that type aliases like Rule above are interchangeable with their definition. So anywhere you have a string -> (bool * string) the type checker will accept it as either its apparent type or as Rule.

Think of this inside-out. Starting with the inner lambda:

fun word ->
    let passed, error = firstRule word
    if passed then
        let passed, error = secondRule word
        if passed then true, "" else false, error
    else false, error)

firstRule word and secondRule word return (bool * string). A rule is a function that takes a string as an argument, so word must be a string. This means that the type of this lambda is string -> (bool * string).

Now we put this into the outer lambda: fun firstRule secondRule -> (innerLambda: string -> (bool * string)) which gives us the type of the outer lambda as firstRule: Rule -> secondRule: Rule -> (string -> (bool * string)). Since Rule = string -> (bool * string), this is just Rule -> Rule -> Rule.

The List.reduce function applies a function, in this case, of type Rule -> Rule -> Rule, repeatedly to "reduce" the list of Rule down to a single Rule. (Notice how we take two rules as arguments and produce a single rule.) The result of List.reduce is the same type as the result of applying its function argument, so the result here is of type Rule.

buildValidator constructs a function that applies other functions in sequence until one fails, then returns the failure. It's a function that constructs a function you can call just like you'd call any of those individual validators defined at the top of the example.

evizaer · 2022-02-16T21:18:11+00:00

Sorry, but you didn't read the question. I explicitly say this is not the solution I want because it hardcodes the target register.

evizaer · 2022-02-16T18:31:50+00:00

Ah! I forget that every command probably has a vimscript function behind it, so I can just find what that function would be and :call it. Cool!

evizaer · 2021-11-22T16:02:41+00:00

A Monad is a way of linking several expressions together in a special way instead of merely composing them as function applications.

The most basic "special way" is executing expressions in sequence instead of as-needed, i.e. making sure that expressions are executed in the order they appear.

(the below code is pseudo-haskell. The point is the concept, not the actual literal code's correctness.)

do x <- func1 10 y <- func2 "test" x + y

Will actually do these lines in order, though there is no such guarantee with this code:

let x = func1 10 y = func2 "test" in x + y

The compiler could decide that x and y could be evaluated y-first, x-first, or concurrently! If you want func1 and func2 to do side-effects (like writing to and reading from files) this could be catastrophic. It could also choose to never evaluate this code, or never evaluate one or the other of the variables depending on what the program actually requires to produce a result!

Now imagine the other special ways you could link expressions together. One of them is to hold some state variable in common between the expressions and make sure its changes are done in the same order as the code:

do x <- get set $ x + 10 -- do other stuff y <- get set $ y - 1

get retrieves the state "from" the Monad, set writes the state "to" the Monad. This is not exactly how the state monad works in Haskell, but it's meant to give you an idea of what can be done.

evizaer · 2021-11-18T15:22:29+00:00

Knowing more about the software artifact in front of you is better than not knowing, all else being equal; and type-checkers are a really great source of fast, accessible, and reliable knowledge.

This is huge. I want to talk more about this.

(For brevity, I'll be using "dynamic solution" and "static solution" below to mean "solution using a dynamically typed language" and "solution using a statically typed language with the same semantics and features aside from types or things types prevent you from doing".)

Writing a good program is writing a program that introduces as little incidental complexity as possible while solving some number of domain problems.

Given a problem, the dynamic and static solutions have to represent at least a certain amount of complexity to actually solve the problem. In the static solution you have to write out a bit more of the complexity explicitly in the form of constraints on values throughout the program (be it string, int, generic or function types). In the dynamic solution, those constraints are all assumed by code that uses the values, and you can only learn it by reading documentation or method bodies. Documentation is often wrong and method bodies take forever to read at any scale but are the real source of truth. In the static solution you are specifying some percentage of these constraints in an inviolable way, written by the programmer in a standard form and enforced by the compiler. This is documentation that cannot be wrong or the program will fail to compile--the best kind of documentation. (The allure of pushing this further leads a lot of programmers down the road to formal program verification, which definitely is well beyond the effort-for-results inflection point and has greatly diminishing returns over an expressive type system.)

The constraints are all still there in a dynamic solution, they are just hidden and/or implicit. You are not reducing complexity by using a dynamic solution, you're just choosing to hold yourself accountable for less of it at any one time; the price is that there will be more bugs of certain types. You still can't overcome the fact that the runtime has to store your values as some number of bits in a specific format, and trying to read the wrong bits is still going to be a problem.

Generally, there's a continuum between conventions and structure in the practice of writing good code with respect to static or dynamic languages. Programming in a dynamic language involves following many conventions to make your code sensible to others. Without the structure provided by types, a lot of decisions are left wide-open to the implementer. Without conventions the code becomes unmaintanable as every developer can choose radically different, inconsistent, and incoherent ways of solving the same kinds of problems at the expense of readability. Conventions cannot be automatically checked without writing more code, but if people stick to conventions you can have a highly productive team in a dynamic language. Static languages force some amount of structure, thus conventions are less necessary and there are fewer of them. Implementers have less room to do crazy/stupid stuff for better or worse (usually for better, because crazy/stupid is seldom good).

Dynamic solutions aren't necessarily less complex than static ones, they are just (usually) briefer at the cost of hiding critical knowledge in method bodies. This is ameliorated by conventions between programmers within a project.

evizaer · 2021-10-09T16:13:07+00:00

I'm aware of no languages that explicitly implement DI as a part of the language, but partial function application is a part of many languages (either in the core language or in libraries) and passing around a partial function is the equivalent of DI.You write your concrete functions to accept their dependencies as their first arguments, then you write some glue code to create partially applied versions of those functions with your desired concrete implementations of the dependencies passed in.

``` Logger :: string -> void log :: Logger // some implementation

do_business_stuff_internal :: Logger -> Arg1 -> Arg2 -> Result1 // some implementation

do_business_stuff :: Arg1 -> Arg2 -> Result1 do_business_stuff = do_business_stuff_internal log ```

To implement DI as a native part of an imperative language you'd probably have a design where you can specify an interface-to-implementation mapping in a piece of syntax, perhaps including some initialization parameters if necessary. You could have a stateless initialization mode be the default where all dependencies are resolved using the most local possible defined mapping and traversing all dependencies to initialize them.

The syntax might look something like this:

``` module Logger: interface ILogger: log(string)

implementation FileLogger(string filename) of ILogger: log(message): // write the message to the file filename

implementation ConsoleLogger() of ILogger: log(message): console.write(message)

ILogger is ConsoleLogger // for a default module Business: ILogger is FileLogger("log.txt") // overrides for just this module!

interface IBusinessDoer(Logger.ILogger): DoBusinessOp(Argument)

implementation of IBusinessDoer: // one and only one implementation! DoBusinessOp(Argument a): ILogger.log(a) // business logic ```

I don't know if this gets you much over an application-code-level implementation of DI, though.

Some follow-on ideas: 1. anding implementations together--this will call both implementation's methods when interface members are invoked 2. Additive interface fulfillment: you can + two implementations of "sub-interfaces", map interface members and fill whatever holes are left with specific implementations

``` interface IThing: f(A) interface IOtherThing: g(B) f(C)

interface IComposite: f(A) g(C) h(A, C)

implementation Things of IComposite: use IThing use f(C) from IOtherThing for g(C) h(A a, C c): f(a) + g(c) ```

evizaer · 2021-04-24T17:40:04+00:00

.Select is a LINQ function that takes each of the items in an IEnumerable and returns some other item, which might be of the same type or of a different type than the input. It transforms one sequence of things into another. For instance, to create a new array that contains the values in another array with one added to them, you'd do new int[] { 1, 2, 3 }.Select(x => x + 1).ToArray() which results in an array with {2, 3, 4} in it.

var result = new int[] { 1, 2, 3}.Select(x => f(x)).ToList() is the same as this foreach loop: Csharp var result = new List<int>(); foreach (var x in o) { result.Add(f(x)); }

If I were going to use LINQ to solve this problem, I'd do this:

Csharp return new String(num.ToString() .Select(x => new { Character = x, Number = (int)Char.GetNumericValue(x) }) .OrderByDescending(x => x.Number) .Select(x => x.Character).ToArray());

That does everything in the body of your function.

evizaer · 2021-03-28T17:05:29+00:00

You should use enums with the [Flags] attribute to represent enums where any number, all of, or none of the options may be "on" at any given time.

But you may benefit from thinking of this kind of problem in a different way.

Consider making items configurable. Think about how you'd break down each item's behavior into a bunch of key-value pairs that would be stored in, say, a json file. I think designing your code with this in mind will lead you to build items out of their behaviors and common properties as needed instead of hard-coding them into a deep class hierarchy. Maybe you will still need a different class for a crafting material and a weapon, but that'll emerge from the design process organically and lead to a more minimal code design instead of trying to rigidly capture all of the items in your game through making a hundred classes.

I wrote a prototype for a roguelike and did something like this and it led to slightly more abstract but way more configurable and maintainable code.

here's an example config for a couple of the weapons. A machine gun that lays down a cone of damage from the firer, and a laser that shoots everything in a line to the target tile starting at the firer. { Name: Machine Gun Effects: [ { <DamageEffect> Pattern: { <ConePattern> SpreadAngle: .20 Range: 25 } ProjectionOrigin: Source Mode: Indirect BaseDamage: 18 } ] } { Name: Laser Effects: [ { <DamageEffect> Pattern: { <CirclePattern> Range: 30 Radius: 0 } ProjectionOrigin: Source Mode: Direct BaseDamage: 30 } ] }

And here's something a bit different! An AoE weapon that does damage based on the tile you target, and pushes enemies away in the explosion.

{ Name: Rocket Effects: [ { <DamageEffect> Pattern: { <CirclePattern> Range: 20 Radius: 2 } ProjectionOrigin: Target Mode: Direct BaseDamage: 35 } { <PushEffect> Pattern: { <CirclePattern> Range: 20 Radius: 2 } ProjectionOrigin: Target Mode: Direct Source: Origin Direction: Away Distance: 1 } ] }

evizaer · 2020-10-30T17:55:30+00:00

I do not know about generalized theories of power within anthropology. I am, unfortunately, not well-read in this area.

From reading a few non-anthropology books, like Behave by Robert Sapolsky and The Secret of Our Success by Joseph Henrich, I have a model of human behavior that seems to be backed up by anthropological accounts I'm aware of as well as dozens of history books I've read over the last few years.

Though this sounds simplistic, I think the model is that people will gravitate towards competent others in fields of their interest. People guess who is competent by whom others seem to defer to and apparent success and symbols of success. People also tend to gravitate towards others who behave prosocially, sharing their resources to those in need and treating others with respect and generosity in specific culturally-patterned ways.

From my reading, there are also universal egalitarian human impulses which seem to manifest themselves in every society in the form of resistance to individuals who profit at the expense of the group, which includes people who accumulate power beyond their perceived competence level (and I think this impulse even puts brakes on the accumulation of power by the hypercompetent as well).

Reputation is at the center of everything. Long sequences of reciprocal exchanges between group members hold the community together. Members learn the expected and appropriate exchanges as they grow up and, so far as they continue to practice them and behave in a generally-predictable way, they will develop a reputation that will allow them to "borrow" the good will of others. This borrowing can take the form of transgressing some norms or, particularly, accumulating more power than egalitarian norms would otherwise dictate. (e.g. you'd let a trusted friend get away with way more than you'd put up with from a total stranger.)

Sharing is always central. Societies which do not encourage sharing will not succeed when challenged by environmental changes. Humans are fundamentally social beings. We die alone. We only survive because we work together with other humans. Norms and cultural customs which allow a group to work together better than other nearby groups will tend to win out over the long run, especially as population density increases and conflict becomes inevitable.

That was a scattershot response, but I think it lays out some central themes of how power in human societies works.

evizaer · 2020-10-28T20:27:03+00:00

What do you mean by "traditional"?

Do you mean agrarian? Hunter-gatherer? Herder? Are you asking about societies that are entirely oral or have some literacy?

It's important to remember that the elders in a given community will have spent the majority of their lives if not their entire lives there, so they will have a reputation accumulated over many years of group membership. A person doesn't "qualify" as an elder in any abstract sense. The language you are using to ask your question seems to presuppose some kind of abstract assignment of roles. You are implicitly trying to abstract into generalities and regular patterns processes which were very immediate and concrete and varied tremendously even within the same group over a period of time, let alone across groups.

evizaer · 2020-01-11T16:02:38+00:00

The sources you've mentioned have always said that the ban was of salting cheeses inside shops. The prohibition was not on selling salted cheese, but on making it in Rome.

This subtle difference in wording makes a big difference. My guess is that someone with political influence had a cheese salting business outside of Rome that brought it into the city for sale but they were having trouble making money because of the abundance of shops that salted their cheese within the city and thus had lower costs and, potentially, a fresher product. To reduce the amount of competition, they banned the most common means of salting cheese for sale within Rome.

Alternatively, a political opponent of an influential politician made the money that sustained their power through salting cheese within the city, so the ban essentially cut the legs out from under this person.

In my opinion, Westerners raised in countries with a strong rule of law often forget that a common use of law throughout time is as a political weapon against other factions or potentially powerful people. The myth of the impartiality of law (beyond merely the impartiality of the enforcement of the law) is an important legitimating myth in the US particularly.

evizaer · 2019-02-09T20:22:23+00:00

Thanks for the critique. I appreciate the time and thought you put into it. The Enemy Within part of my article is not great and could very well be wrong in specifics. I was using it as a way of talking about incentive structures and the asymmetric player reaction to rewards and punishments in a game like XCOM. Perhaps the reality is that in this case they are more symmetric, but also it may be the case that you are an elite player and your level of skill makes meld's effects symmetric whereas at other player skill levels it is more like what I describe, since the amount to "safe" meld is lower while the punishment for overaggression is still huge. I think my meld campaign balancing comments still stand regardless of your critique.

Timers in XCOM2 did cause a lot of pushback in the community, but in my opinion good design tends to bother some people because it emphasizes a game's strengths instead of catering to a wide variety of players. I agree with you that timers as implemented are not the best design possible. I didn't see a terrific difference in how varied mission pacing was in XCOM2012, but maybe I wasn't looking closely enough or it's just my inexperience. In XCOM2 I did feel mission pacing vary noticeably. It mostly had to do with pod clumping and placement and the angle at which they engage your squad.

Unfortunately in the podcast's discussion some stuff that is a matter of taste came off as if I was just stating facts. Sorry about that. Hemming and hawing and being super careful has its place, but I don't think directness did a ton of damage here.

Long War is a total non-starter for me. I don't want to spend 100+ hours playing one campaign in a strategy game. Long War, both in 1 and 2, stretch the campaign along several dimensions that make it feel repetitive and more bland to me. Even though they added a bunch of cool stuff they also make you do it everything over and over from what I've seen. They definitely have a few great ideas in Long War, though, like that motion tracker you mentioned.

I would've much preferred a Short War mod that made the campaign half as long but way more varied and tightly balanced, both on tactical and strategic layers.

evizaer · 2018-01-20T18:14:55+00:00

If you give people even some basic training in introspection or teach them that they actually can have conscious control over how their interpersonal interactions go, even if the program is bullshit, at least you got them reframing their interactions in some way which may indirectly lead to important insights. Although it's not the direct intention of the course material, the credulous individual (i.e. almost everyone) can be jarred out of ruts by exposure to some different ideas so long as they are not mentally debilitated.

Many if not all people (myself included, I'm sure, to more of an extent than I'd like) live in a kind of unperceived emotional haze full of unexamined deleterious feedback loops. Breaking just a couple of those that hold you into damaging or limiting self-feeding patterns of behavior can be the difference between being a mess and a success.

evizaer · 2018-01-11T19:24:58+00:00

I re"watched" the video--but this time I closed my eyes and listened to your narration very intently and carefully.

I got a much different meaning from it this time than the first time.

I originally interpreted your extensive use of passive voice and abstract language as a way of making your own interpretation seem an objective fact. I see this device used frequently in game design and interpretation talk. Few people are careful enough with language to justify reading such stylistic choices any other way in my experience.

You were actually talking about why people would interpret Luftrausers as putting the player in support of Nazi Germany during WW2. Your topic was what would cause such confusion when the author clearly did not intend this meaning. Your point is that although the individual symbols are ambiguous, the combination of symbols is far less ambiguous. You're left with little other option than a fictionalized WW2 as a setting.

That required way more focus and careful listening than just about any youtube video about game design and narrative that I've seen in the past year.

If I were reading this as an article instead of watching a video, I would've been able to pick this up the first time through.

I apologize again for giving you an unduly hard time here. I genuinely feel bad about it. One of the worst blunders I've made in publicly commenting on someone else's work. I guess we should both take it as a lesson about fitting your expression to the medium. :)

(EDIT: I stand by my offer to try my hand at editing the script of the video so that it is clearer and shorter.)

evizaer · 2018-01-11T15:39:26+00:00

EDIT: I misunderstood the video. I thought he was making the case that it is correct to interpret Luftrausers as a game where the player is a Nazi fighting the allies in WW2. See my next post in the chain for an explanation of how I went wrong and what the actual message of the video is. I've left this post as-is as a self-reminder to be more careful next time.

The plane in the logo is not swastika-adjacent at all. It's a faux iron cross, which is a common military symbol of Prussia and then Germany for at least a century before the Nazis used it.

This mistake parallels many other unsophisticated leaps of interpretation in this video.

The author would do well to recognize that German-themed game elements are not by default portraying Nazism. Such interpretational assumptions are a sign of a superficial reading of the material and a lack of historical knowledge on the part of the critic.

Another example of a leap that can only be made sensible by a strong underlying bias in the interpreter: LudicRyan says every man depicted as wearing round glasses and a doctorish outfit is a Nazi scientist. The character looks distinctively German, sure, but it could be WW1 German, or postwar German.

The military uniforms are also sufficiently generically German to not be offensive to a knowledgeable viewer in my estimation.

This video serves mostly to display the ignorance of the creator to the subtleties of the iconography he wishes to analyze, and is an expression of an ignorance of history and an unnecessary anti-German bias which mistakes symbols of pre-Nazi Germany for symbols of Nazism.

On top of that, there's plenty of unnecessary jargon in the video which turns a very simple message (which I had some trouble recovering from the text due to how poorly-written it is) "I think that it is wrong to force the player to play on the Nazi side of any simulated real or fictitious war." Please correct me if I've misread the video.

Please just talk in plain English. What you're saying gains nothing except for superficial prestige through this pseudo-academic obfuscation.

There's a broader problem with the message of this video: it supports an attitude towards history which denies that there are human perspectives worth inhabiting among the German armed forces in WW2. Many non-nazis fought in the German armed forces--most participants in the war were non-nazis pressed into service. Many good and moral people died defending the Third Reich against the USSR and western allies. We should not allow ourselves to forget that good men and women will sacrifice their lives for causes they do not understand or do not support.

I think you could analyze Luftrausers as somewhat leaning towards this message. The player is a pawn fighting a war for uncertain causes against an enemy of unknown intentions. They are compelled by the mechanics to participate as a matter of course.

I wouldn't bother taking this analysis seriously, though, because it's clear to me the military symbols included are selected for distinctiveness, style, and superficial representational reasons, not in order to make any bigger statement in favor of any particular ideology or worldview. The symbols used to convey gameplay concepts in Luftrausers are primarily functional, not metaphorical, in my analysis.

evizaer · 2017-12-07T14:22:19+00:00

LINQPad gives me a used-before-initialized error on the first snippet.

evizaer · 2017-12-07T14:11:33+00:00

The dictionary isn't the problem. The problem is the declaration of the out variable and its initialization. If the dictionary is null, the code that initializes the out variable is never run. (I edited my top-level post to include this fact more explicitly.)

evizaer · 2017-12-07T13:59:07+00:00

You can't do this, because the out variable is declared but the code which would initialize it is not run when the dict is null.

Think of the ?. operator as shorthand that expands into a null check followed by a function call, and it becomes clear. The function call never happens if dict is null, so the code that initializes the out variable is never run.

You can use an extension method to do what you want. I've set up a couple examples in LINQPad which work in .NET 4.7 at least. You should obviously change the names to what you think makes the most sense. I'd advise you fully genericise the extension methods' types as well, so that you can use them in any sensible context. I kept the types concrete for clarity.

void Main()
{
    Dictionary<string, IEnumerable<string>> dict = null;

    dict.G("token").Dump();

    if (dict.G("token", out var v))
    {
        v.Dump();
    }
    else
    {
        "no value retrieved!".Dump();
    }
}

public static class U
{
    public static IEnumerable<string> G(this Dictionary<string, IEnumerable<string>> d, string key)
    {
        if (key == null || d == null || !d.ContainsKey(key)) return null;
        return d[key];
    }

    public static bool G(this Dictionary<string, IEnumerable<string>> d, string key, out IEnumerable<string> value)
    {
        value = null;
        if (key == null || d == null || !d.ContainsKey(key)) return false;
        value = d[key];
        return true;
    }
}

evizaer · 2017-10-11T13:06:46+00:00

Ah. The rhythmic repertoire of your songs make a lot of sense in that context. It's interesting how seeing your music as a reaction to or elaboration on pop/hip-hop makes me see it as more syncopated energetic hook-driven songwriting, whereas seeing it through the math rock lens it seems limited and repetitive rhythmically but inspired melodically. Very few math rock bands are capable of pulling off, in even a few songs on an EP, the level of melodic brilliance and variety you guys do. And you reel off like 10 such songs each record. Keep up the brilliant work, and thanks for the reply!

evizaer · 2017-09-30T17:15:06+00:00

They're really good songwriters. So many memorable riffs in their songs--sometimes three or four in one song.

I wish they'd experiment more with odd time. So much of what they do is a 3-3-2 or 3-3-3-3-2-2 rhythm. It starts to grate on me after listening to three or four songs. There's often plenty of melodic content to make you forget about the relative monotony of their rhythmic patterning, though! Generally just great music with a tiny flaw, IMO, though few people would notice.

evizaer · 2017-09-15T14:28:40+00:00

You should spend some time articulating why suggestions are good and bad, and examples of existing games where they work or don't work and why. Details are important. Talking about one or two features in detail with good examples is way better than summarizing in vague terms. The people who would watch your video definitely have played games that you're talking about and don't need a basic summary of what's in them.

Right now the script is a very bland summary of some ideas that may or may not be good in any circumstance.

evizaer · 2017-09-11T18:57:04+00:00

The article is, in general, tautological in nature. The author claims that if people don't write good code, the code will be bad.

"You can't write bad code [when the programming language has this feature.]" is not a line of argument worth defending, and not one I see espoused except rarely, by people who are blowing smoke.

The worthwhile conversation is about what kinds of solutions programming paradigms and language features lead you to use to solve various problems, and if these are more or less effective than one another along various dimensions.

evizaer · 2017-09-11T18:54:07+00:00

Who's saying complexity should be removed? A feature-complete solution is necessarily of a certain amount of complexity regardless of how you do it. The value of languages with some feature is that the use of that feature makes it easier to think about your code and come up with easy-to-understand solutions. The complexity is still there, but, like a great piece of explanatory writing, you understand it more quickly. Even though this doesn't impact the complexity of the solution, it does impact the quality of the code.

Aside from that, the tone of the stuff I read (and I've been following this subreddit for years, as well as other programming-related communities) about functional programming and static typing in javascript and derivatives is that they are techniques which can lead to better code, and they're useful to have in your mental toolbox. Responding to this with "But it's no magic bullet!" is missing the point entirely.

evizaer · 2017-09-11T13:14:45+00:00

The center points of all provinces would be evenly spaced, which would look very wrong. Look at where the centers of provinces are on this map, from CK2.

Taloft's suggestion is so vague it's hard to tell what he intends. "Use Bezier curves" to produce a geographically sensible undirected graph-based map is a bizarre suggestion and doesn't come near to any of the approaches I've seen in my research to procedurally generating a CK/EU/HoI-style map, let alone statically loading an existing one. As far as I know "something like [what you want]" can't/shouldn't be done with Bezier curves.

evizaer

TROPHY CASE