Looking for Honest Recommendations

HawtTrash

Member
Hello all, I'm needing some sound advice here. I started roughly a year ago started "making/planning" the video game I wanted to create. To me, it feels like I have a lot done, but know I'm only half way there. I have attempted to close my game, however I am running into two problems. 1, tutorials do not directly apply and I often dont fully understand what I'm codong. 2, is that I'm nervous with the scope of my project, that i am going to be setting up elements of the game wrong, which will not be scalable. Below is a list of things I have done so far on my game.

1. I have all of my graphics/designs including but not limited to: characters, enemies, world map, menu, logos, power ups, textures, backgrounds, sprite animations

2. In a notebook, I have drawn every single level layout. i.e. each power up, enemy, coin, flag for ingame Cutscenes

3. I have an entire dialog script for each character and scene.

4. I have some music and sound fx. I have a friend who is creating these elements for me.

To help you help me, I am basically creating a game that mirrors a lot of what Super Mario World did....world map, game saves, fairly linear levels, enemies, power ups, a few small Cutscenes, slopes, moving platforms, gravity, slow acceleration, holding items/objects, timers, lives, percentage complete, and more.

I am fully dedicated to getting to the finish line on this game build. The story and time I've already put into it are pretty special to me and think the game if done right could be awesome for others too. I've taken a Udemy course, and just couldn't apply everything across like I wanted to.

Maybe explaining some key things I need to consider when building a project this big would be _________.


Or, you should code [this first] and [this second] etc etc etc. I just dont know what a game start to finish coding wise looks like and what problems I might be able to avoid by listening to your alls advice :)

thanks!!!
SZB
 

kraifpatrik

(edited)
GameMaker Dev.
Hey there, in my honest opinion, this whole Udemy and video tutorial situation is getting out of the hand. I've seen multiple posts that mention the same thing - the tutorials don't work for them. Remember from school, when the math teacher started a new topic, showed you the first example problem and how to solve it, and then you still had no idea how the stuff works? Well, it works exactly the same with programming. What they show you, is a single specific solution to a single specific instance of a problem, and you are not going to learn anything just from that. What you need to do is to try it yourself and fail as many times as it is necessary for you to learn something. Pick a small enough component of your game project and try to implement it in code and keep trying until you're satisfied with your solution. Then you can move onto another and so on and so on. At the end, there is your first game. That's how it is done. The only tutorial you actually really need for that is this - docs2.yoyogames.com - The Holy Bible of GML. You can also read up on some tools, concepts and patterns that are often used in game development - OOP and state machines could be an example for that. Good luck with your project!
 
Last edited:

2DKnights

Member
I suggest just starting with the underlying engine.
First and foremost decide on a screen resolution

Then create A simple collision map and your player object. Get it moving around and interacting correctly with your tiles, slopes, and one way platforms, etc.

Once your happy with that. Work on the camera and viewport system.

Next add a simple enemy to the game, nothing too complex. Test that the enemy also works within you system, collides correctly etc.

Create a short test level with your players and enemies.test it and have others test it and get some feed back.

By this point you should be very knowledgeable about the engine youve built. Then you can import your fancy sounds and gfx, and expand on enemy types, powerups etc.
 

HawtTrash

Member
Thanks for the feedback!

I have done some test coding on prior builds of my game. Had title screen, into level 1, with player movements and enemy collisions, parallax BG elements. But just wasn't happy with the code I had written. It's was a lot of pieces from other puzzles like a few of you have mentioned where it fit that solution but only solved mine halfway.

Another problem was I have not been consistent with learning code. So I designed about a year ago, started coded, and then went MIA on code for the year and now none of it makes sense.

Thanks. And I was digging a lot last night, and found the GMS2 blog, which seems to have some really nice content in it. I think everyone is right, build, fail, learn, build and adapt until you end up with a game :)
 

FrostyCat

Redemption Seeker
I've been on these forums for more than 15 years, and this topic has all the hallmarks of something that'll end badly, if at all.

As the resident storm cloud, here is my advice for you:

Advice #1: Starting with your big dream game is a recipe for never finishing. You've already seen what "go-big-or-go-home" has done for you. Shelve your dream, and start over with smaller practice pieces investigating individual concepts in more clarity. The ones who succeed in this line of work have all done lots of lower level work --- many small, primitive, badly built, and not even published --- and learned from them before making what they're known for.

Advice #2: Tutorials are for investigating, not for copying. Learn how to use them effectively, not the way you're basically worshipping them now. You already know what blindly porting them over does, so stop that already. And underpinning it all is the Manual's GML Overview section. It's pretty stupid trying to write a novel when you don't even know your ABCs.

Advice #3: Success in programming comes from pulling up your own bootstraps, not someone else pulling up yours. In this line of work, it won't take long before you do something nobody else has also exactly done, in which case only basic theory will save you: basic language syntax, algorithms, organization patterns. Tutorials and Q&A responders can show you some of them, but you have to dig for the basic theory and drag it home yourself. If being led from beginning to end and not having to "dig" are non-negotiable for you, you should have bought a paint-by-numbers book, not game development software.

Advice #4: Use money to buy what you won't put effort into. Knowing what this means is something money can't buy, and you aren't acting like you fully understand it.
 

HawtTrash

Member
I've been on these forums for more than 15 years, and this topic has all the hallmarks of something that'll end badly, if at all.

As the resident storm cloud, here is my advice for you:

Advice #1: Starting with your big dream game is a recipe for never finishing. You've already seen what "go-big-or-go-home" has done for you. Shelve your dream, and start over with smaller practice pieces investigating individual concepts in more clarity. The ones who succeed in this line of work have all done lots of lower level work --- many small, primitive, badly built, and not even published --- and learned from them before making what they're known for.

Advice #2: Tutorials are for investigating, not for copying. Learn how to use them effectively, not the way you're basically worshipping them now. You already know what blindly porting them over does, so stop that already. And underpinning it all is the Manual's GML Overview section. It's pretty stupid trying to write a novel when you don't even know your ABCs.

Advice #3: Success in programming comes from pulling up your own bootstraps, not someone else pulling up yours. In this line of work, it won't take long before you do something nobody else has also exactly done, in which case only basic theory will save you: basic language syntax, algorithms, organization patterns. Tutorials and Q&A responders can show you some of them, but you have to dig for the basic theory and drag it home yourself. If being led from beginning to end and not having to "dig" are non-negotiable for you, you should have bought a paint-by-numbers book, not game development software.

Advice #4: Use money to buy what you won't put effort into. Knowing what this means is something money can't buy, and you aren't acting like you fully understand it.
I appreciate the feedback honestly. Hopefully I can prove you wrong. I don't feel the need to waste my time not building this game. The good thing is, the scope of the game is the scope of the game. It won't really grow outside of that. I wouldn't exactly call this go-big-or-go-home. To me, it seems hard yes, but I mean learning something new is never easy. I would assume "dream games" are given up on or fail bc people won't follow through. I've had failures already on this, but I'm still going and don't plan on stopping. I have no interest in building a different game per say, which is sometimes where creatives find it easy to disengage bc they have a "more fun project".

Nevertheless, I will keep grinding, learning and failing until I have the game complete, and since you've been on here for 15 years, I'll try and find you when I'm all done so you can enjoy :D
 
The advice to start small is not because creatives flit around making half built "more fun projects" 24/7. It's because making games is insanely hard. Starting with your dream game is, as FrostyCat put it brilliantly: like trying to write a novel before you know your ABC's. Unless your dream game is literally Pong, it's going to present problems that you simply don't have the skills to tackle. The advice is not "Don't ever program your dream game" but instead it is "learn how to program -before- approaching your dream game". Starting an incredibly small-scoped project is the most effective way to learn when you are new, instead of trying to piece together code you don't understand into a behemoth of a project while floundering about trying to figure out bits and pieces that never work effectively together.

Honestly, we're not trying to rain on your parade, but both Frosty and I have been visiting the forums for -years- and we see posts exactly like this -all- the time. And the correct advice is always: Start small, learn the basics, work your way up to your dream project.
 

BQubed

Member
I appreciate the feedback honestly. Hopefully I can prove you wrong. I don't feel the need to waste my time not building this game. The good thing is, the scope of the game is the scope of the game. It won't really grow outside of that. I wouldn't exactly call this go-big-or-go-home. To me, it seems hard yes, but I mean learning something new is never easy. I would assume "dream games" are given up on or fail bc people won't follow through. I've had failures already on this, but I'm still going and don't plan on stopping. I have no interest in building a different game per say, which is sometimes where creatives find it easy to disengage bc they have a "more fun project".

Nevertheless, I will keep grinding, learning and failing until I have the game complete, and since you've been on here for 15 years, I'll try and find you when I'm all done so you can enjoy :D
I would very strongly advise you to listen to FrostyCat, because I can tell you from my own recent personal experience that he's giving you good advice. If you've never coded a game start to finish and you're still learning coding (we're both in the same boat) then make some small games that are fun to play and distribute them for free. They don't have to be epics. Just Ludum Dare style games. What you'll learn from that and from the feedback you get will be extremely valuable when you start work on your larger project. You seem to be quite passionate about creating a good game, but just as in any occupation, experience makes you work faster, better, and more efficiently.

I was working on my game 10 Days to Jupiter up until recently, but I've since shelved it to work on a smaller game that is essentially a remake of a game I used to play as a child. I felt that game had a small scope, and its systems would teach me a lot about coding in my main project. Nobody will tell you to just give up on your project, but you do need to prepare for it and experience is part of that preparation. Best of luck.
 

HawtTrash

Member
I would very strongly advise you to listen to FrostyCat, because I can tell you from my own recent personal experience that he's giving you good advice. If you've never coded a game start to finish and you're still learning coding (we're both in the same boat) then make some small games that are fun to play and distribute them for free. They don't have to be epics. Just Ludum Dare style games. What you'll learn from that and from the feedback you get will be extremely valuable when you start work on your larger project. You seem to be quite passionate about creating a good game, but just as in any occupation, experience makes you work faster, better, and more efficiently.

I was working on my game 10 Days to Jupiter up until recently, but I've since shelved it to work on a smaller game that is essentially a remake of a game I used to play as a child. I felt that game had a small scope, and its systems would teach me a lot about coding in my main project. Nobody will tell you to just give up on your project, but you do need to prepare for it and experience is part of that preparation. Best of luck.
I mean technically I have coded a small game through my udemy course ;) I understand what you all are saying. I know it's easy for people to be naive, ignore advice, and think they can just waltz in and do EXACTLY what they want to do, when in reality it very rarely works that way. That's not to say, that it's impossible, and I think that's sort of what I'm getting at. I know what I want, I am passionate about it, and I am willing to put in the time and effort to learn, fail, and repeat every step through the process.

Here's where I think I'm different from your typical, "hey I want to make an awesome game, let's go! Fails soon after starting and gives up"......I have spent a significant amount of time (just over a year), not only designing, but scripting, and a lot of planning for functionality of the game. I have started coding a few times and had some decent stuff going, but decided the foundation of how I was coding was shaky, so I restarted, which I think is a testament that I am not afraid to scrap what I've done in order to do it right.

Nevertheless, I am working now from start the finish on the game. Focusing on the full functionality and coding of the title screen + menu, and then working through the world map functionality, into levels, and how data is passed from a level to world map, saved/stored, and all of pathing a player may take in or out of the game.... i.e. pause menus, exit, save, etc etc.

If you have specific advice for me continuing forward, it's greatly appreciated :)

Again, thanks for all of the advice so far everyone.
 

chamaeleon

Member
Don't ignore fundamental computer science theory and programming methodologies. Read the manual and get very well acquainted with the available tools and building blocks at your disposal (objects, events, instances, sprites, scripts, functions) and get used to looking things up in it over and over (we all do for various reasons). Learn to use the debugger, and how to trace your program and how to add meaningful debugging statements that help pinpoint root causes of problems.
 

pixeltroid

Member
It's GREAT that you're planning everything out in a notebook. But be advised: if your first game is going to be really big and epic, you'll suffer from fatigue trying to implement everything.

I suggest you start making a smaller version of your dream game just and to test out things. Once you get the hang of it, then you can start working on your dream game slowly and incrementally.
 

HawtTrash

Member
It's GREAT that you're planning everything out in a notebook. But be advised: if your first game is going to be really big and epic, you'll suffer from fatigue trying to implement everything.

I suggest you start making a smaller version of your dream game just and to test out things. Once you get the hang of it, then you can start working on your dream game slowly and incrementally.

Yea, and the planning has shifted a few times in the sense of, was a notebook, then switched to a Google Doc, and now it's a combo in an effort to document everything needed, as well as draw out some what I call flow charts, and user pathing. I would add, I don't think it's a big or epic project. I would say it's big for a new coder which I am, but I think half the battle is understanding that it's not an easy win. How do you eat an elephant....one bite at a time ;)

I have hit some fatigue a few different times, whether it was with level designs, or character animations, but the nice thing about doing everything by myself is that I can swap in and out of coding to design a new character or particles. Although I will note, I think for me personally, I need to buckle down and only focus on coding for quite some time and not worry about "polishing graphics". That way I can retain my coding knowledge better, and easily navigate the code when I encounter problems. <--- navigating the code prior was a problem bc I couldn't remember what did what. So being more dedicated, and ingrained in the process of coding I personally think will help me quite a bit.

Really appreciate the advice and encouragement!
 

HawtTrash

Member
Don't ignore fundamental computer science theory and programming methodologies. Read the manual and get very well acquainted with the available tools and building blocks at your disposal (objects, events, instances, sprites, scripts, functions) and get used to looking things up in it over and over (we all do for various reasons). Learn to use the debugger, and how to trace your program and how to add meaningful debugging statements that help pinpoint root causes of problems.
Absolutely. I have been referring to the GMS2 bible doc quite a bit lately in an effort to not just learn about the specific thing I am working on, but more importantly, the foundation of those elements, and the different ways they can be used.

Great point on the debugging. I have not experimented with that quite yet. But I can see how that will be a huge benefit as the game starts to come to fruition. The amount of code, elements, sprites, unique objects will be pretty large in scale and managing them all will be a task in itself. I think I copied over 2k graphic elements the other day into my new project folder lol. Fun stuff.

Thanks for the advice!
 

Joh

Member
Don't want to be a downer, but I'm gonna go along with the common wisdom of don't start with your dream game, Hell I'd go a step further and say don't start with a challenging game. Start with something you feel confident you should be able to do (at your current level!). There's a reason pretty much everyone said not to do that, and no you are not the first " I know what I want, I am passionate about it, and I am willing to put in the time and effort to learn, fail, and repeat every step through the process. ". It actually sounds a lot like everyone who ended up giving up.
But its pretty obvious you'll go for it, and in a few years you'll take frosty cat position warning newcomers from doing their dream game to start. (even if you do succeed)

@RefresherTowel put it well, its not that its easy to get distracted by "better" ideas (and it is), its just hard, really hard and it kind of takes experience to realize how hard it is. ever seen a professional athlete and think it cant be that hard? only to realize that "hey this is hard" when you try it. and then realize that they compete against other top pros.
that's gamedev, it's harder than it looks and the better you are, the better you HAVE to be.

I recently stopped working on a game after 3 years, 3 YEARS and no, not to jump on a new idea, I still don't have my next project, just because I was realizing it wasn't working and I didn't have the ability to deliver it. Part of why I think I stuck so long is because I, like you had taken a lot of time to plan everything and indeed i followed my plan and everything was going according to plan until the game was no fun.(if theres one thing plan cant tell you its: is the game fun) so then I have to start deviating from the plan, make small changes that leads to needing to change a lot of things until you're no longer progressing you're just fixing/salvaging. Then sunk cost fallacy hits you and the harder you try, the less you can give up. Imagine if it was your dream project. It wasn't mine, it was supposed to be a small project and i still couldn't let go.

I knew I shouldn't work on something too ambitious and I was still defeated while I built experience toward my dream game which I'm still not willing to tackle. And that wasn't me starting out, had been making small games for years and was quite at ease with GM. I like to think that was the case of the next level failure: once you no longer feel like a beginner and think you can step it up a notch. Learned a lot from the experience, but I wish I didn't have "nothing" to show for it.

Got carried away a bit, all this to reiterate:it's not a good idea to start with your dream/ambitious project. Hoping my experience can add a bit of "concreteness" to that reality, but if it rings hollow and feels like "just a story" then it just adds credence to my earlier point: "it kind of takes experience to realize how hard it is"

Remember your idea isn't going anywhere and with all your passion, it will still be there by the time you build the skill needed for it. your future self will thank you for it!
If you do go through with your game, I can only wish you best success!
 

Yal

šŸ§ *penguin noises*
GMC Elder
2. In a notebook, I have drawn every single level layout. i.e. each power up, enemy, coin, flag for ingame Cutscenes
I'd say doing this kind of stuff on paper is a waste of time - it's much harder to correct mistakes like making a jump one block too high on paper than in your game's level editor (e.g. GM's room editor) and you can't test play on paper to make sure it flows right. Just doodle down the general idea on paper and flesh it out in the room editor so you don't need to do the exact same work twice and ensure you did it 100% accurate in the in-game version.

Overall, there's a lot of danger in over-planning, where planning itself takes more time than being well-prepared saves when doing the actual work. The more solid your plans are, the harder it is to adjust them to new things happening, which is bad whether those new things are bad (people being sick and not delivering their new music on time) or good (you found a bug in collision checking that lets you juggle enemies and it's SO MUCH FUN and you're tempted to make it a major gameplay feature) in nature. Any big project will have unexpected things happen partway through, and if you're making a big blob of code you will have code that doesn't behave as you planned it to, whether it's regularly or only in certain edge cases. The key to finishing a project without going insane is getting good at damage control: making bugs features if they're fun, hiding them out of the way if they aren't and they're too hard to actually fix. (Fun fact: the notion of a difficulty curve is because Space Invaders lagged when the entire alien army was rendered, and gradually sped up to the intended speed as you had fewer enemies on screen. One of the core ideas used in the basis of all game design was a bug.)

Make gaseous plans if possible, and try to stop yourself at liquid plans if you absolutely need to make them more dense than necessary.
 
Top