What kind of games should made by a new developer to understand fundamentals of game developing?

Discussion in 'Programming' started by cokmakbulegecti, Jul 1, 2019.

  1. cokmakbulegecti

    cokmakbulegecti Member

    Joined:
    Jul 7, 2018
    Posts:
    2
    Like "you should make pacman-like game to learn/understand enemy AI". What's the list that makes you say "if a new developer made these games he's/she's not a newbie anymore.". And if your list games have priority, please specify it by numbers.
     
    Sabnock likes this.
  2. samspade

    samspade Member

    Joined:
    Feb 26, 2017
    Posts:
    1,965
    My answer for this question has changed over time. I would say it depends on several things.
    • What type of games do you want to make once you get a little more experienced?
    • How do you like to learn/what motivates you?
    • What level of difficulty are you looking for?
    You can learn the fundamentals of how GML works a variety of different ways and there's a big difference between what you would need to know to make a platformer, a real time strategy game, and a match 3 mobile game.

    Also, you have to figure out how you're going to learn. If you want to follow a GML specific tutorial, then you're a little limited by what is out there. In that case, I would recommend the official YoYo First game tutorial. If you wanted a more structured approach, you could look on Udemy.

    Difficulty is also a factor.

    Here are some other thoughts on the same topic:

    Extra Credits
    Old Forum Post

    Also, I would say that there is a very big difference between learning to make games and learning to program. And you can learn either without learning the other and there's no guarantee that learning one will teach you the other. In general I would say that in fact you will not learn one while learning the other. So at some point, not at the start, you might want to think about how you will learn other things about programming as well.

    For the moment, I would just say find something you're motivated enough to do and do that. You can see the last link in my signature for more ideas on the subject as well.
     
    Toque and Catan like this.
  3. curato

    curato Member

    Joined:
    Jun 30, 2016
    Posts:
    319
    That would be an interesting tutorial series. Learning to program but in gamemaker. I would say if you don't already know how to program, I would look at some of the drag and drop tutorials they are made with non programmers in mind. If you want to do more than what you can drag and drop then you may want to look at an intro programing class if you are looking to be the programmer.
     
  4. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,313
    First, learn the language and the environment. At the very least, commit the events and the basic syntax of GML to memory. None of the work you claim to be under your belt counts unless you can read every line of it. You can learn this while doing tutorials by having the Manual beside you, but you may not under any circumstance finish a tutorial until you can trace out the execution flow of everything covered by it, and derive from it lessons that can be applied elsewhere.

    Then you should start independent work away from tutorials and hands-on help. Rather than going for specific titles, a better idea is to choose your own projects, but with representation in several specializations. The simplest model for game development, in my opinion, is these three categories:
    • An action-driven game (e.g. most arcade games, platformers and shooters)
    • A data-driven game (e.g. board games, match-3, turn-based strategy games)
    • An extension (e.g. UI engine, parsing library, etc.)
    If you can do at least one sizable project in each of the above without any tutorials or in-person help, then I'd say that's a basic mark of graduating from novicehood. A journeyman has to know how to make things act, manage abstract data, reuse work effectively and stand alone in an authoritative capacity.

    One of the reasons why I get riled up about the current state of GM education is its near-exclusive focus on action-driven games and supervised usage. The end result is a whole bunch of morons who could copy an entire platforming engine from a tutorial, but can't even loop through an array or model an inventory on their own. The GMC is now filled with rookies who have only done action-driven games, but have never worked on a data-driven game, made an extension or flown solo. Worse yet, most of these rookies have convinced themselves that they're experts, and the laurels they rest on are basically a scrapheap of plagiarized or overdone content.
     
    Forgeio and RefresherTowel like this.
  5. zircher

    zircher Member

    Joined:
    Jun 21, 2016
    Posts:
    379
    Over the years I've made a crap ton of simple games, mainly as a programming challenge. Snake games, word games, maze games, dungeon crawlers, shooters, all kinds of 3D stuff, each one gives you new insights and also helps to build confidence and programming mastery. If I was doing it over again, I would make a to-do list of game type and game technology that I want to learn and start adding a couple from column A and a few from column B until I got all the listed milestone done. Game jams are also another good way to challenge yourself to learn new things and do them under a time crunch. That will motivate you to learn about polish and 'juiciness' as well. It's perfectly okay to hit a bunch of tutorials to learn the logic and techniques that you need.
     
    Forgeio likes this.
  6. RefresherTowel

    RefresherTowel Member

    Joined:
    Jul 13, 2016
    Posts:
    1,180
    As usual, frosty comes in with a definitive answer. I'd also add in programming challenges as zircher mentioned. Include abstract and non-game related things in this, like math problems/database work/etc (for instance, something I often do is when I'm watching an episode of Numberphile on youtube and they mention some type of numbers that other people are searching for, I'll often write up a little GML program that does that search to prove to myself that I can).

    Also don't be afraid to look up non-GML related resources. Once you can read GML somewhat efficiently, start looking at programming resources for other languages. This is because the education for other languages is usually a bit more formal and definitive than it is for GML and a for loop in GML is basically the same as a for loop in C++ or Python or whatever really. This'll broaden your understanding of programming on a deeper level and also give you access to resources that don't exist within the GML community. For instance, the majority of the procedural generation/pathfinding/data driven frameworks that I've learnt to use have come from examples in C++, Java, etc, that I've then adapted to GML. A lot of deeper level abstract code work like that doesn't exist within the GMS learning community.

    Learn to use the debugger. Like, REALLY use it. It's the most important tool you have and the most common suggestion that comes from this community (the infamous "put a show_debug_message() at this point") is a pale shadow of what you can achieve from really learning to use the debugger properly. Learn how to set breakpoints and step through your code, checking variable values in the Variables tab and seeing what instances exist (and what variables they are holding) in the Instances tab. Learn to use the Watch section of the Variables tab to keep track of the variables that are important to the moment. If everyone on the board learnt to use the debugger effectively, 80% of questions would be eliminated straight up I think.

    Learn to read the "flow" of code as well. Understanding how the code itself is going to execute from moment to moment is really important, especially when it comes to things like loops and data-driven designs. It won't come immediately, but you should, with a bit of time and effort, be able to look at a screen of code and understand what the end state is going to be without having to run the code (that doesn't mean you won't ever make mistakes, but just that those mistakes should be minimal and you should be having the old "duh!" moment when they DO pop up, instead of the "what?" moment). A ton of users seem unable to visually process what their code is doing, so as they code, every line they write is literally a gamble as to whether it does what they want it to do or not.

    Apart from that, remember to have fun. Coding is complicated, there's a lot to learn and it's all related in a way that can make it feel opaque, overwhelming and nigh impossible to find a place to truly "start", but as long as the things you are working on are enjoyable on a personal level, you'll be able to persevere through the pain and come out the other side with skills that only deepen over time.
     
    zircher and Forgeio like this.
  7. IndianaBones

    IndianaBones Member

    Joined:
    Jul 5, 2016
    Posts:
    2,155
    First of all, I was preparing a reply, but the above posters have pretty much covered the topic well. I'll still include my suggestions in case you find any of it useful.

    Second, just to comment on the previous replies, the above advice is spot on.

    To grab a small number of key points from above:
    A) Make sure you understand the basics of GML, there are common concepts to most programming languages like loops, conditionals, expressions, variables etc...

    B) Learn to use the debugger!

    C) Find a small project that interests you and attempt to make that, following the guidelines mentioned above.

    ---=== My suggestions follow ===---

    Read the GML Overview section in the manual as often as you can until you understand all of it. (Everyday if you have time, once a week at least).

    Especially learn how to use:

    Conditionals : if / else statements
    Loops : while() loops / for() loops
    Control : switch () statements

    Understand what the keywords continue / break / return do.

    Learn what an array is and how to use it.
    Learn what a ds_list is and how to use it.

    Suggested Projects in this order:

    1) Basics [ Time to complete : 1 - 2 days ]
    Learning Goals : [ Just to get your hands dirty and start to get to know the ins and outs of Game Maker and its workings. ]

    - Draw something to the screen, have it change based on user keyboard input.
    - Draw the users exact input to the screen.
    - Take the users input and change it in some way, and output that to a different part of the screen simultaneously

    2) Blackjack [ Time to complete : 1 - 2 weeks ]
    Learning Goals : [ User input / Output, managing game state, basic AI, using data structures ( an array or ds_list to handle the deck of cards) ]

    - Create a game of one player blackjack against an AI dealer. You can use a simple text based display. (Don't worry about graphics for now).

    3) Choose a very early arcade game and re-create it from scratch. For example, Asteroids / Pong / Breakout. [ Time to complete : 3 - 4 weeks ]
    Learning Goals : [ Real-time reaction to player inputs, collisions, drawing graphics to screen, managing multiple game objects in play ]

    4) Modify your project from 3 by adding Intro Screens, Menus, High Scores, Game Over, if you haven't already. [ Time to complete : 1 - 2 weeks ]
    Learning Goals : [ Game polish and making a game into a complete package for the player ]

    4a) Stretch Challenge - Add local multiplayer to your game from above. [ Time to complete : 1 - 2 weeks ]
    Learning Goal [ Handling more than one player input at a time, abstracting game logic so it can handle multiple players ]

    NOTE : Whenever you get stuck (i.e., something is not working right in your game, you are getting compile errors, game crashes etc ) - locate the line of code causing the issue and immediately read the manual entry for whatever code you are using. Make sure you are using it correctly.

    Whenever you feel like you want to make something happen in your game, but you're not sure how to code/implement it in your game - have a search through the manual to see if there isn't already a function to help you do it.

    For example, say you need to know the distance from the player to the enemy - if you check the manual, you will find there is a function (or multiple functions) that will do exactly this for you. ( point_distance() / distance_to_object() are two that you could use depending on what you are trying to achieve exactly )

    Actually skim through the entire manual at least once so you are at least familiar with what is available.
     
    zircher likes this.
  8. JackTurbo

    JackTurbo Member

    Joined:
    Oct 19, 2016
    Posts:
    821
    Bunch of great replies here.

    Id also say learning how the various events work and interact is really important.

    Read up on all the events.

    Do some basic tutorials on a handful of basic game clones. Pacman, asteroids, space invaders that sort of thing. Thisll teach basics of building a game and get the user more comfortable with the various functions etc.

    If it hasn't been touched yet learn data structures.

    Next try and make a similar game without using tutorials, just the manual.

    Once you've learnt the events, have a good grasp of the functions available, state machines, scripts, data structures etc and can make basic arcade style games without tutorials your probably ready to start learning more about patterns and programming principles outside of gms.

    At that point I'd suggest reading Game Programming Patterns and looking at tutorials that are more about teaching principles rather than specific features (like GMWolfs dependency injection tut for eg).

    Only at this point would I suggest trying any project of medium scope or above.
     
    Last edited: Jul 2, 2019
    zircher likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice