create games to your skill level or bite through the frustration?

Niels

Member
Hi everyone,

For my current game I keep getting stuck on the same problem over and over, and I have to admit my current skills isn't good enough to pull it off without outside help dragging me through all roadblocks, rethink my game idea, or give up. (which would be a shame considering all assets I already created.

My original idea was a action/platfomer in which the level wrapped horizontally and vertically creating the illusion of a huge seamless labyrinth.
But this causes a LOT of unseen problems with enemy AI, targeting, and chasing, when the player just warped to the other side of the level.

And what started out as a nice challenge is now a big pile of frustrating/half implented buggy features...

I could change my initial idea into a fixed labyrinth structure (and ideally with some randomized content) which would be more manageble for my skill level (9 months of GML experience), but somehow it feels like giving up.

I'm probably not the only one with these problems (when starting out) and I kinda seek advice on what road I should take.
 
Z

zendraw

Guest
you shuld think 'ok now how do i manage this?'

for instance your problem with enemies and wraped player. well ask yourself the right questions. how does the enemies find the distance to the player? by x and y and what do you do with them, you wrap them. so wrap the distance also.
if distance<wrapped distance {go with distance}
else {go with wrapped distance}

also that frustration comes from you not knowing all the functions that culd be useful to you. so take your time and learn them, its more fun then you think.

each function is a door for you.
 
Q

Quailfail

Guest
I'm a beginner myself. Generally you learn more when you push yourself out of your comfort zone. However said challenges are easier to manage when it's one or two. It's harder to problem solve all by yourself when you're juggling so many ideas that you are new to and may not realize how each one may react to the other.

Also wish to add that you forgot another option beyond giving up or rethinking; you could put that project on hold and come back to it later.
 

Niels

Member
you shuld think 'ok now how do i manage this?'

for instance your problem with enemies and wraped player. well ask yourself the right questions. how does the enemies find the distance to the player? by x and y and what do you do with them, you wrap them. so wrap the distance also.
if distance<wrapped distance {go with distance}
else {go with wrapped distance}

also that frustration comes from you not knowing all the functions that culd be useful to you. so take your time and learn them, its more fun then you think.

each function is a door for you.
for a more precise example:

I have a bat enemy that has 2 states:
1. idle (in which it hangs from the ceiling and uses a collision_line and a point_distance variable to check if it's view isn't blocked by a wall/floor and the player is less than 300px away from the bat)
2.attack ( in which the bat chases the player which works fine except for when the player warps to the other end of the room)

these scripts work really well and I could just implent them in a regular action/platformer games, but with the wrapping it complicates stuff a lot

Ofcourse that will have it's own challenges but at least I can keep building on my game that way
 

Genetix

Member
My honest thoughts - Ditch the project if it doesn't seem to be going anywhere. Don't ditch the idea. Work on something else, and maybe in a few months take another look at the old project or start building from scratch with the same idea. The point here is that you probably have learned somethings and also have a better idea about how to design the foundation of the project itself, but may be a bit painted into the corner. I just commented on another post about how I have wanted to make a TCG (Trading Card Game) for years now. I've started many of them, but always got caught with some serious problems that stop the project dead. Each iteration improves, and now I feel very confident in my ability to design and code a TCG.

Walk away from it, try something else, come back later with more experience, knowledge, and fresh motivation!
 
Z

zendraw

Guest
another option for you is to make the most simple version that you feel you can make, of your project. like for instance if im correct, you wrap perfectly in your level or atleast youve achived what you wanted for the wrapping, and your only setback is the enemies? well make it with basic enemies, start with a ghost that has no restrictions, just moves constantly slowly towards the player, and work on it following correctle the warped player. then go with an enemy that moves on horizontal platforms and bounces off walls changin its direction. then make some enemy that shoots projectiles and use the wraping on the projectile. so go from the most simple, upwards. never go with a more complicated thing. make the ghost, master it untill your comfortable with the wraping and go on. learning may be faster when your new, but it gets more slower the more you know, ditchin the project may not be a good idea cus you will get a habbit of ditchin when things get out of your league, and its more important to finish a project. so put your ambition aside and do things slowly and steadily like i suggested.
 

Niels

Member
another option for you is to make the most simple version that you feel you can make, of your project. like for instance if im correct, you wrap perfectly in your level or atleast youve achived what you wanted for the wrapping, and your only setback is the enemies? well make it with basic enemies, start with a ghost that has no restrictions, just moves constantly slowly towards the player, and work on it following correctle the warped player. then go with an enemy that moves on horizontal platforms and bounces off walls changin its direction. then make some enemy that shoots projectiles and use the wraping on the projectile. so go from the most simple, upwards. never go with a more complicated thing. make the ghost, master it untill your comfortable with the wraping and go on. learning may be faster when your new, but it gets more slower the more you know, ditchin the project may not be a good idea cus you will get a habbit of ditchin when things get out of your league, and its more important to finish a project. so put your ambition aside and do things slowly and steadily like i suggested.
This might be a good idea, will give it a try tonight :)
 

Genetix

Member
Honestly if you quit working on something everytime it was challenging... you'd never get anything done. Not to rant about it... and I know that's not exactly how you're framing this. There is value in determing whether or not it is worth the time and resources to stick with a project.
 

FrostyCat

Redemption Seeker
The best course of action for you at this point is to take a course in computer science, online or in-person.

Whenever I see people ask for complete engines or genre-specific help, that implies their inability to analyze needs. As popular as tutorials and examples are among rookies, they often fail to help with future needs, and one might not exist at all if the need is too broadly scoped or project-specific. Having an eye for data structures and algorithms underlying a need is the only genuine long-term solution, and that can only be developed through a background in computer science. It's easier to get help with a specific data structure or algorithm than a whole project.

I almost always get things my way because I know how to decompose problems properly. A lot of novices get frustrated and whiny because they don't.
 

NazGhuL

NazTaiL
create games to your skill level or bite through the frustration?

Bite through the frustration!!! The biggest mistake is to build a large game with too much features.
You can't create a perfect coded game if you don't have enough experience. What is enough? I don't know. It depends of each person.
Split your project into smaller game/project/test. Fail, destroy and rebuild. Never copy/paste code/examples.
I believe tutorials and engine can be good but it won't help you if you can't reproduce what you are using.

Now for your AI problem, it may be simpler than you think. If a bat can 'see' at 300px. If the bat is 100px away from the end of the room you know how much left for the other side. (200 ;) )
 
V

V-Toad

Guest
Hi everyone,

For my current game I keep getting stuck on the same problem over and over, and I have to admit my current skills isn't good enough to pull it off without outside help dragging me through all roadblocks, rethink my game idea, or give up. (which would be a shame considering all assets I already created.

My original idea was a action/platfomer in which the level wrapped horizontally and vertically creating the illusion of a huge seamless labyrinth.
But this causes a LOT of unseen problems with enemy AI, targeting, and chasing, when the player just warped to the other side of the level.

And what started out as a nice challenge is now a big pile of frustrating/half implented buggy features...

I could change my initial idea into a fixed labyrinth structure (and ideally with some randomized content) which would be more manageble for my skill level (9 months of GML experience), but somehow it feels like giving up.

I'm probably not the only one with these problems (when starting out) and I kinda seek advice on what road I should take.
I think it's best not to look at a scaling down as,"giving up," rather than just, "setting it aside for later."

Just the other day, I watched a series of videos on YouTube created by a user called 2kliksphilip - he has a playlist called, "The Game Making Journey."

Not having a computer growing up, Philip began his game making journey by making and selling paper games to his classmates. Eventually, he inherited his father's old Atari ST, and later on his first PC. Philip had spent years dreaming up ideas for video games without having the means to make them. Even then, it was many years (and hundreds of unfinished projects) later before he managed to complete his first game.

When he ran into problems like what you're describing, he often walked away from them and came back hours, even years later with a fresh perspective. My advice? Table your idea for scrolling levels and try something more conventional for now. Finish what you're working on, then try to make a brand new prototype and get the core concept of your wrapping levels working. From there, add just one thing at a time, and test, test, test! Keep at it and you'll get there!
 

Yal

🐧 *penguin noises*
GMC Elder
If we'd try the idea decomposing thing that's been mentioned above on your problem...
  1. Distance and direction doesn't make sense when target objects can move around.
  2. We need another system that can allow for new ways to compute distance and direction.
    1. You could check all possible wraparound points rather than the player's current position, then go for whichever one of those is the nearest.
    2. You could switch your current checks for a new system that keeps track of what parts of the room are connected to each other in each direction, then handle movement from one such cell to another.
    3. You could move everything EXCEPT the player to fake wrapping, wrapping them at the edges of the screen.
 

Niels

Member
I think it's best not to look at a scaling down as,"giving up," rather than just, "setting it aside for later."

Just the other day, I watched a series of videos on YouTube created by a user called 2kliksphilip - he has a playlist called, "The Game Making Journey."

Not having a computer growing up, Philip began his game making journey by making and selling paper games to his classmates. Eventually, he inherited his father's old Atari ST, and later on his first PC. Philip had spent years dreaming up ideas for video games without having the means to make them. Even then, it was many years (and hundreds of unfinished projects) later before he managed to complete his first game.

When he ran into problems like what you're describing, he often walked away from them and came back hours, even years later with a fresh perspective. My advice? Table your idea for scrolling levels and try something more conventional for now. Finish what you're working on, then try to make a brand new prototype and get the core concept of your wrapping levels working. From there, add just one thing at a time, and test, test, test! Keep at it and you'll get there!
thanks for your motivating answer!

I have watched that video series by 2klikphilip in the past, I really enjoyed them:)
 

Yal

🐧 *penguin noises*
GMC Elder
By the way, you should be aware (and wary!) of Feature Creep... just because you can add something new in doesn't mean it's a good idea to do it... it's much easier to cause bugs just by making your game more complex (when different systems interact with each other the most recent system can end up breaking the earlier system that worked perfectly before, and now you need to fix that AGAIN) and if you keep adding to a project you will add a point where it collapses because you don't know how to proceed. Just trust me on this, I've got personal experience from way too many big projects that collapsed under their own weight because I just couldn't stop :p
 

RangerX

Member
In any case, you current project, cancelled or not, serve as experience for better project.
Here's a couple of things you're supposed to have learned my now:

1- Making your graphical assets first is a waste of time.
2- Better to design your game first and then code the main systems. You will evaluate better "what you can do" and "what you can't do".
3- Generally speaking, your first game shouldn't be you "my baby" beloved projects. You should create smaller projects and prototypes for learing your way around and THEN you create your "awesome dream game".
 
V

V-Toad

Guest
@Niels - the important part is to stick with it. Don't get discouraged by setbacks - just because you're having trouble now doesn't mean you won't work it out later. Be patient with yourself, and get a few small victories under your belt!

If we'd try the idea decomposing thing that's been mentioned above on your problem...
  1. Distance and direction doesn't make sense when target objects can move around.
  2. We need another system that can allow for new ways to compute distance and direction.
    1. You could check all possible wraparound points rather than the player's current position, then go for whichever one of those is the nearest.
    2. You could switch your current checks for a new system that keeps track of what parts of the room are connected to each other in each direction, then handle movement from one such cell to another.
    3. You could move everything EXCEPT the player to fake wrapping, wrapping them at the edges of the screen.
What you might try (in a separate or future project) is to work building a system like Yal is describing here. It sounds fun and challenging!


By the way, you should be aware (and wary!) of Feature Creep... just because you can add something new in doesn't mean it's a good idea to do it... it's much easier to cause bugs just by making your game more complex (when different systems interact with each other the most recent system can end up breaking the earlier system that worked perfectly before, and now you need to fix that AGAIN) and if you keep adding to a project you will add a point where it collapses because you don't know how to proceed. Just trust me on this, I've got personal experience from way too many big projects that collapsed under their own weight because I just couldn't stop :p
Scope Creep (as we call it in Project Management) certainly applies to games as well! You will always be able to make a game "better" by adding this or that feature. The trick is to have the courage to save them for the next project! John Carmack programmed 21 games before he created the engine for Doom (the 1993 original). Everything happens in baby steps, so try to think as each finished game as one step further :).
 

Niels

Member
I'm very aware of feature creep :)

at the moment I brought my game back to its core where I want to finish all my main characters states/moves and add 2 types of enemies (1 flying and 1 moving on the ground).
With those enemy types I work on the combat till i'm satisfied.

Then my next step will be making a test level and release a demo for play testing/feedback.

btw I know I shouldn't work on the game art before I have everything programmed, but for me half of the fun is drawing the art assets, and it's a nice break from scripting
 
Last edited:
Z

zendraw

Guest
In any case, you current project, cancelled or not, serve as experience for better project.
Here's a couple of things you're supposed to have learned my now:

1- Making your graphical assets first is a waste of time.
2- Better to design your game first and then code the main systems. You will evaluate better "what you can do" and "what you can't do".
3- Generally speaking, your first game shouldn't be you "my baby" beloved projects. You should create smaller projects and prototypes for learing your way around and THEN you create your "awesome dream game".
1-actually making assets and coding at the same time is simply a conflict situation and impairs the process. if you know the game you want to make and you know how to make it, make a cheap version of the assets first, and then code without worrying that 'oh i have to make this and this now in order to continue'. after youve actually made the game, you can polish all you want. codin and making assets work only when your testing stuff.
 

RangerX

Member
Well, that's basically what I mean.
The guy sound like he made all or many assets before even knowing how he will code all the behavior. This is not good. It is better to work with placeholders first (as you suggest) and then you create your final assets later.
 

Yal

🐧 *penguin noises*
GMC Elder
Well, that's basically what I mean.
The guy sound like he made all or many assets before even knowing how he will code all the behavior. This is not good. It is better to work with placeholders first (as you suggest) and then you create your final assets later.
I usually do something completely different, making all assets as soon as I have the behavior done (or sometimes before, if I have a clear concept). I find that the polish work takes a lot of time, especially if you do all the polish at the same time in the end, so I'd recommend doing it continuously over the entire project duration. Things like tells before an enemy attack are easy to flub completely if you debug everything with single-color rectangles.
 
Well, that's basically what I mean.
The guy sound like he made all or many assets before even knowing how he will code all the behavior. This is not good. It is better to work with placeholders first (as you suggest) and then you create your final assets later.
I disagree. Art and gameplay work together. It's best to have a perfectly clear idea of how an enemy, weapon or what have you will look, sound, and behave before starting any work on it. I then create whatever's in my head in whatever order will be easiest to get just right. Usually that means starting with the art, not the code.

If you don't have a clear enough image in your head to start in any order you want, there's a good chance whatever you're making is going to turn out uninspired, in my opinion. In the best games, art, sound, music, theme, and gameplay all work perfectly together. I don't start making anything new until I have a very strong image in my head. At that point, it doesn't matter much what order I do things in.

So, in my advice, the first step is "think until you've thought whatever you're making completely through!" =)

Also, the game I'm working on now is my first real game, besides a tutorial edit or two I made years ago when I was a little kid. Nothing wrong with starting with your dream game. Worst case is you find out you don't have the skills necessary yet, and try again later. Best case, you save a lot of time you would've wasted making games you didn't really want to make, haha!
 
Last edited:

Niels

Member
Well, that's basically what I mean.
The guy sound like he made all or many assets before even knowing how he will code all the behavior. This is not good. It is better to work with placeholders first (as you suggest) and then you create your final assets later.
I didn't make all assets first, but I prefer to alternate between drawing and coding.

for me it's easier to stay motivated when my project looks somewhat like I imagined in my head instead for working for months on rectangle shaped solid colored objects
 
M

Misty

Guest
A programmer refusing to use Google is like a Scientist refusing to use an Encyclopedia or research peer-reviewed experience and data.

If the code works and it doesn't glitch, it's good. Do what ever you have to do to get the code to run. That being said, some degree of programmer competence is necessary. That being said, I copy and paste a lot of my old scripts from years ago, since I am not going to spend days of effort trying to relearn how to build things I forgot how to build. Similarly, as long as someone's code is not copyrighted, and it does what it should, there is no reason you have to build everything from scratch.
 
Z

zendraw

Guest
yes, i support the idea of a game maker to have a catalogue with scripts. afterall, the codin part is just the technical part of the game. the essential part is the artistic and fun aspect. if you dont have those 2, your just a programmer.
 
B

Blazing

Guest
I've always made assets as I coded. I work in chunks, so when one feature has been fully thought out, drawn, programmed, and debugged, I move on to the next.

Generally, I come up with a concept, work out on paper exactly how the programming will look, make resources that are close to completion, then finally start using Gamemaker itself.

I have yet to abandon a project because resources were a hindrance. Rather, it's just me losing interest or falling into a creative rut.
 
Z

zendraw

Guest
blazing, you will lie if you say that you will abandon a project that has some nice looking graphics just lyin there waiting for you to give them juice. if i have all assets ready and waitin, god have mercy, i wont sleep until ive coded everything.
 
C

Chungsie

Guest
man good luck. every time I sit down to learn GML my mind feels like thousands of needles, and it's 10 times worse than what I went through to learn ruby. and actually I think having an engine that I "need" to learn with, makes me think it's not worth it because I don't know the nuts and bolts of the engine. we after all, can only do babysteps, which will (in my experience) annoy more professional programmers of a language, and often involve them offering feedback that negates from whatever you were learning to begin with.
does that make any sense?
 

Niels

Member
man good luck. every time I sit down to learn GML my mind feels like thousands of needles, and it's 10 times worse than what I went through to learn ruby. and actually I think having an engine that I "need" to learn with, makes me think it's not worth it because I don't know the nuts and bolts of the engine. we after all, can only do babysteps, which will (in my experience) annoy more professional programmers of a language, and often involve them offering feedback that negates from whatever you were learning to begin with.
does that make any sense?
prior to GML I haven't had any coding experience at all except for html and css, while I did study design and have drawn for most of my life... so in a perfect world I need to team up with someone that has coding skills but no artistic skills:)

BUT I do like the idea of being able to code my own games and are willing to learn.
 
C

Chungsie

Guest
prior to GML I haven't had any coding experience at all except for html and css, while I did study design and have drawn for most of my life... so in a perfect world I need to team up with someone that has coding skills but no artistic skills:)

BUT I do like the idea of being able to code my own games and are willing to learn.
when I was in middle school I taught a class at a battered woman and child shelter on HTML. never learned CSS tho. I though about learning Pearl or XML but neither were as easy. QBASIC was something I could do wonders with at one point in my life, til the lawsuit destroyed DOS forever.
 
B

Blazing

Guest
blazing, you will lie if you say that you will abandon a project that has some nice looking graphics just lyin there waiting for you to give them juice. if i have all assets ready and waitin, god have mercy, i wont sleep until ive coded everything.
As an artist, there is so much art/sketches/doodles that I make and then just leave to collect dust in a notebook or throw out on a regular basis.

If you're drawing something every day, it's not that hard to look at a folder of a game's worth of resources and go "meh" and forget about it for five years until it looks like total garbage to you because your skill level has improved.

I have several complete arcade games' worth of resources that are collecting dust as I type. And many more I have deleted in the past when I had a tiny hard drive.

I'm more of an artist than a coder, so like I said, resources were never an issue for me...It's more just sticking it out with a project.
 
A

ajan-ko

Guest
I'm not smart or artistic.. but...
I'm the type that learning by doing, until I screw up again and again...

this is me by the way...

joke aside... this is pretty helpful.

 
Last edited:
Top