Those tips are good but a lot of BYOND game developers will have trouble following them. Conveniently, this can all be traced back to the other article you linked to.

BYOND has a lot of projects that appear to be the result of someone saying "I like MMORPGs and I've always wanted to make a computer game, so I'll make one that's like an MMORPG". When "I want to make an MMORPG" is the starting point of your project it is harder to follow the tips for staying motivated:

Set tiny milestones. Having a generic goal means you'll tend to focus on the generic milestones, like creating a title screen and chat interface, not the actual gameplay (the stuff that makes your game interesting and fun). There are many BYOND games that are in development, some even for a long time, and all they appear to have done is a title screen, tile set, map, and interface.

Scale yourself back. MMORPGs happen to be games that don't easily scale back. The fun often comes from having a lot of content. Not only is the genre a bad starting point, but MMORPG is probably the worst one you can pick.

Prototype early / Playtest. This is the same as the problem with milestones. When you don't work on the gameplay there's nothing to prototype and nothing you can give people to try out. BYOND users seem to use their imagination a lot. They'll create an interface and imagine how awesome the game will be. Instead, you should prototype the gameplay first and see how awesome it actually is.

It's not just the complete newbies that have these problems. There are several projects by more respected people who have these same problems. It's not that hard to find a game that's been in development for several months and only has a title screen, tileset, and base icon to show for it. Most BYOND game developers make a mistake very early on and try to struggle through the project, thinking that the struggle they're experiencing is just the expected difficulties that come with making a computer game. The post you linked to has good advice and should be easy to follow. If you have trouble putting these things into practice, you've got some underlying problem.

What's Causing This

Often it's a lack of programming ability but sometimes it might just be a lack of confidence. People start on a game by making the interface, coding the turfs, and making a map because those are the easy parts. Sometimes people focus on these parts because they're not sure if they have the ability to implement these things - they have to prove to themselves they can make a title screen. You need to have the ability and confidence to say "I know how to make a title screen, I don't need to prove that" or the confidence to say "if I can implement the rest of the game, I can figure out how to make a title screen later", or at least the guts to say "I don't know how I'll code this game but I'll try to tackle the hardest part and hope it's a good learning experience, if nothing else".

As a result there are many BYOND game developers who make an interface, title screen, and map, then the project stalls. They might try working on it for a while but never make much progress and give up. Then they start a new project where they only create an interface, title screen, and map before that project stalls. Implementing gameplay and finding ways to tweak it to make the game more fun is a skill that takes practice, and if your projects stall before you get to that point you're not getting practice at it. Most hobby game projects don't succeed but you can still make a failed project be productive by making a good learning experience out of it.

Tips for Coming Up With Ideas

Start with an abstract idea that goes somewhere but isn't limited to going in a single direction. You want an idea that says something about the gameplay but still leaves some details to be filled in. When you say "I want to make an MMORPG", that's open-ended but doesn't go anywhere. When you say "I want to make a game where the player uses swords to attack and kill enemies", that idea goes somewhere but it's too specific. Start with an idea like "the player overcomes challenges by using things they have limited control over". That statement leaves you with some things to figure out - what challenges does the player overcome? what are the things that the player can use? how and why is their control limited?

You might decide that the player will fly an airplane and be able to select what weapons the plane has but they don't have control over when or how the weapons fire. You have to learn how to fly the plane in such a way that the weapons are used effectively. Or, you might decide that the player will place robots on a board, then activate them all and use their predictable behavior to solve puzzles or clear enemies out of the way. Or, you might decide that the player has to defeat enemies by summoning monsters. You don't have control over what the monsters do and have to figure out which monster is best to defeat a particular enemy knowing you'll have to deal with the consequences (you don't want the monster to kill you too).

In every case you can immediately start prototyping a scaled down version of what the game will be like. You can get the basic movement working for the airplane and create a few weapons. You can create a few different robots and a sample puzzle to show how they can flip switches to open doors, push boxes, or do whatever they'll need to do. You can create a monster or two and different environments to show situations where they're useful or harmful to the player. In each case there's a small amount of work that has to be done but many BYOND users would view those things as being monumental. You have to be good enough at programming that implementing the airplane's movement and making a few projectile attacks is easy. The hard part is figuring out how to make that idea as fun as possible. If you want to draw a picture of a house, drawing a single straight line has to be easy. If every straight line is a challenge, you'll have a very tough time.

Also, in every case we're eventually led to a genre (airplane game: top-down shooter, robot game: puzzle game or turn-based RPG, monster game: action RPG or platformer) but we didn't start with that. If we had said "let's make a top-down shooter", we wouldn't have thought of the robot game or monster game at all (maybe you'd like one of those ideas better) and we probably wouldn't have thought to limit the player's control over their weapons - you'd have just made a top-down shooter that works like every top-down shooter you've seen before.

When you start out this way it's easy to come up with a project you can be motivated to work on. Most game developers on BYOND make a mistake early on in their project, suffer through it for months, end up abandoning the project, and haven't learned from their failed project (they may have learned something unrelated, like "don't trust so-and-so as a pixel artist", but they didn't learn anything that'll help them avoid the same mistakes that led to the project's failure). When you do it right, making a game can be very easy.