-Paix-

I'm not sure I'm allowed to say this? But you could use the decompiler on your own work?

Mods, correct me if I'm wrong, I don't mean to stir trouble. I just know what it's like to lose a gmk and not be able to do anything besides remake it.

EDIT: Besides that...you don't seem to interested in your own game... I'd recommend if you're not interested anymore, don't even bother. Make a game you want to play, otherwise you're not really going to get very far.

Here's why using sprite_index as a state variable is not helpful in the long run.

Say you have a system that works like this:

You have two enemies. One that is red and one that is blue. So you have two separate sprites:

sprEnemyBlueWalk
sprEnemyRedWalk

(obviously there's ways around this by changing the color in game, but this is just as an example as it won't just be color difference in the sprites most of the time)

Suddenly your states have to double in their code.

if (sprite_index == sprEnemyBlueWalk || sprite_index = sprEnemyRedWalk){}

What if you have 5 enemies that allll walk the same but have different sprites? 20?

Theoretically you could still do this:

mySpriteWalk = sprEnemyBlueWalk; (in the creation code of the room instance)

And then:

if (sprite_index == mySpriteWalk){/*walk*/;}

But...this is just messy code in my opinion.

If all you want to be is a hobbyist game developer, you can program however you like... but if you ever want to get into game dev as a career, start programming professionally *now* rather than later.

Also I just remembered an issue this will bring up.

If you have a character that can move and jump at the same time, then you have to separate the actual sprite movement from the walking code or separate the sprite movement from the jumping code. Here's why:

This sprite_index can only ever be one value. Which means it cannot have both a walking sprite and a jumping sprite at the same time. You could have a sprite designated as a walking and jumping sprite, but this is ridiculous and just creates more work when it's not necessary at all.

With states on the other hand. You can have several states active at once that do different things at the same time.

if (walking == true){
//walk
}

if (jumping == true){
//jump
}

With the sprite_index way:

if (sprite_index == mySpriteWalk){
//walk
}

if (sprite_index == mySpriteJump){
//Jump
}

if (sprite_index == mySpriteWalkJump){
//WalkJump
}

if (sprite_index == mySpriteWalkShoot){
//WalkShoot
}

if (sprite_index == mySpriteJumpShoot){
//JumpShoot
}

//and as a final encore:

if (sprite_index == mySpriteWalkJumpShoot){
//WalkJumpShoot
}

As you can see from the above code snippets using sprite_index as a state variable causes your code to exponentially grow as you add states. Whereas by just using states properly you will always only need to add the code for the new state not all the combinations it then would require in the sprite_index method.

Make sense?

According to the screenshot (I haven't tested the actual program) I don't see how it would be useful to have a minimap that shows the contents of the view in smaller form... Is this the case in the actual program? If not, I would recommend making a screenshot that actually shows what it is capable of. I'm not inclined to check out the program because of it.

It's actually a quite common game. I don't know what the original game that all the versions are based on... but here's a version... not made with GM:

http://www.mp3rocket...lcon/Galcon.htm

There are few game ideas I've literally given up on permanently. The only ones I did that with were ones that I simply wasn't interested in (one or two).

I currently have

1 game engine project on the back burner
1 (small-medium action/arcade) game that is 100% conceptually completed but I need to reprogram it (lost the gmk file).
1 (large strategy) game that is probably 5% concept completed (largest project, currently no programming). This is my current project.
1 (medium strategy) game that is about 90% concept completed and no programming.
1 (small puzzle) game that is 100% concept completed and completed, prototype programming with no actual production programming.
3 Retro remakes that are 90% game-play programming complete but just require polishing, which I probably won't get around to since they were simply meant as warm-ups.
2 other concepts that are only 5% that I'll keep but probably not get around to messing with further.
1 concept that is about 50% concept complete with no programming. Good chance of being revived.

I don't really give up on projects completely unless they are small and random. I've been working with GM since GMv5 and have only permanently dropped probably 2-3 concepts. The above ones have been started in the past 2 years except for the "action/arcade" game which was my first real project with GM.

Sadly to say...I haven't finished anything. The closest I've gotten to "finishing" is retro remakes and those weren't even fully completed or polished. I do believe that perfection has caused me to get frustrated with my concepts since I love my concepts. I wonder if working on a smaller game that I don't care about as much and completing it would help?

Thoughts on ways to reach completion? Common distractions? Common pitfalls to avoid?