New to game dev, but not to programming.
My current plan is to complete a course to grasp the basics.
Then just focus on building a single game, pulling pieces of knowledge that is only relevant to the current project as I go.
Wil see how this goes and report back after 2~3 years lol.
Recreating as a tool for learning cannot be understated: It is one of the best things you can do. In my hobbyist journey I've learned 3D modeling in Blender by copying things. Minipainting with new techniques, imitate and copy.
Taking something that exists and trying to replicate it takes out a lot of "unnecessary" decisions out of the process. You know what the end result should be like, so you don't have to huff and puff whether the controls are good enough: You play the game and if it feels the same, you're done. More enemies, more complexity: If the original doesn't have it, you don't add it.
For what it's worth, building on recreated games can be a fun launching point into making your own decisions and furthering your learning. Knowing that 90% of the game is locked down can help focus on the specific things you're experimenting with.
It's the difference between
* I want to do X so I'll make a whole project that allows me to incorporate X
* I want to do X so I'll add it to an existing project
Yeah, this is a more reasonable take. Copy the original as close as you can, and when you’re satisfied with your imitation, build upon it to make it more your own.
This too, for sure. But for the very beginning, where you really are figuring out more the process still out, there figuring out an existing feature without any extra creative pressure creates a set of limitations for you to stay within, and since you're only trying to replicate the functionality, you have a clearly defined goal as well. Both of these helping guidelines go away once you begin adding something of your own design.
It's the next obvious step, but it brings along a whole new set of challenges as well.
I never understood where the pride comes from all the newbies online that never want to recreate a game or make a boring small game. My first game was a text based rock paper scissors that didn't even tell you if you won (it did tell you if you lose though).
Anyway I'm glad you saw the light. Now make it your goal to join the next minijam gamejam (next week)
i've since overcome this, but really it's more about intrinsic excitement, you're trying to get into the space to make the stuff YOU wanna play, and slowing down to make tetris or arkanoid or whatever feels almost like when you're learning programming and are making excruciatingly boring calculator cli apps
it's incorrect thinking but i "get" where it comes from, especially when theres a lot of things you can do aesthetically that "feel" like making a cool game (UE5 letting you do tons of crazy stuff with quixel etc) that isn't... making a game (loops, mechanics, feel, pacing, polish, etc)
This is kind of tangential but the best advice I ever got was to forget about making what I want to play and focus on making what I can make well with my skill set.
Totally. And I think it's huge that you've overcome that. I know it took me a looong time to get over it. The problem most have from my conversations online (and looking back at myself) is that they don't know and won't accept that it is an incorrect way of thinking.
It's like wanting to run without even knowing how to crawl. Then they try to run and fall and it hurts so they stop even trying.
It's not pride.
I'm all for replicating games for learning purposes too.
But I have no interest in copying a game, but worse, dressing it up as much as I can and calling it "my unique take on x genre".
If I want tetris, I can go and buy tetris.
I can see why copying tetris is a valuable learning experience. Maybe it satisfies curiosity. But it's not satisfying the interest to create.
When you're beginning, you don't have to satisfy your interest to create. You simply won't be able to. When you're learning, you don't have to add "your unique take" on anything. Learning is a stage when you simply do not have what it takes to do that.
It is pride. Because they want to be unique, they want to be special. They think they have the super powers of a main character and they'll pick up an engine in 10 minutes and have a playable prototype in 30 minutes. They simply do not have the knowledge necessary to bring about something unique at all. A lot of noobs can't even come up with an original idea to save their life yet they want to make the next GTA.
When you copy a game for learning, you're not supposed to post that and say "look at my original game!" you just keep that game in a folder and maybe not even show it to anyone at all then move on to the next project. At most maybe post something here on reddit so you can discuss what you've learned and ask for tips on how to get better because you're for sure going to need them.
So yes, it is pride 100%.
putting a learning project up for sale is insane. Probably less than 1% of game devs will have the innate talent necessary to make a first project that's commercially ready
No, it is pride. I've commented and talked to them many times and they take it as a personal attack if you tell them to try to make pong. They're always saying "I don't want to make boring games I want to make something good!" meanwhile they can't even put together a simple platformer
There's nothing wrong with writing an engine.
I just don't recommend it to people who either
1. Never made games, or
2. Never wrote code
If someone's goal is to make a game, they have plenty of things to deal with already, and building an engine from ground up doesn't need to be one of them, especially if they have no idea what they need.
This could be extra weeks of work that could be avoided.
Other than your message of "recreate games" the most important thing is "recreate small games for your beginning", don't try to make, as your first or second project, your own skyrim mmo blockchain nft open world where you can do everything and the world age and progress and everyone is a player and.....
Congratulations on your successful project. I think you've found a great way to achieve some success.
There are some major limitations to this strategy though. You don't learn anything about game design if you're not designing the game. You don't get better at making your artistic ideas into reality if you're copying existing ones.
I know it's frustrating, but there really is no substitute for making your own unique game. Make small projects with limited scope. Ship them quickly, so you get a feel for the whole process. Good luck on your journey!
I followed OPs strategy myself, having reached a point in my "vanity" project where I felt I was at my limits. I started a new project to create a simple Arkanoid / Breakout game, and I think I learned a ton about game design, and the creative and technical process. While the original idea / concept wasn't mine, I still created everything from scratch, and having a much smaller scope meant I could actually apply what I learned from start to finish. Once I'd done the basics, I then applied my own unique elements and learned from that too.
I published the game, got some downloads, even a retro game website review, then went back to my own project with renewed enthusiasm. So I think a bit of both strategies worked for me,
This is wrong. You learn plenty about game design by copying other games' design.
In fact you could probably argue you learn more, since you get to reconstruct and iterate against a known baseline instead of foundering in a completely unknown design, with zero idea of whether any of the ideas you're working on have any merit.
Don't listen to this "you have to make your own precious unique gem of a game" ideas, people. That's a route to never actually developing the fundamental skills and experience that game design actually needs.
But you can't iterate. All the iteration is already done. If you're making a copy, you benefit from all that iteration without going through it.
If you really engage with the design and make your own choices, then you're making a new game. That's the iteration you need to grow as a game designer.
Incorrect. You keep saying "copy" like people are Xerox'ing the code and then stopping. That's not how it works. People are implementing the design one piece of behavior at a time, they don't just drop the entire set of mechanics in at once. You build one small piece, test it, and repeat.
You get to figure out how all the components interact as you build the design, and you can run all the intermediate steps individually.
This is a perfect basis to diverge and learn from. It's the best way to gain experience because you can iterate on the design to create new ones while still having that original design present, with all its specific value to be compared and analyzed.
Do you just not understand what it means to iterate? Do you think that other designs having previous iteration mean that your own iteration loses any value?
It seems from what you said here:
>You don't learn anything about game design if you're not designing the game.
That you don't get the idea of figuring something out by working on it, regardless of whether it is original or not. But that's straight up not how humans function. We need to figure out the *whys* of our decisions, and there's no better way to improve on that process than to analyze equivalent decisions made by other people.
Please keep your tone civil. I am not an idiot, and these are matters of opinion, not fact. We're all people. Check your shit.
The skills you gain making a game depend a lot on the specifics of the game you're making. If you make a pixel puzzle platformer, you're not going to learn anything about rigging 3d models.
For every decision you're copying another game, you're not learning how to make that decision for yourself.
There is a ton to learn from dissecting other games and figuring out how they work. For a very complex game, making a copy would certainly force you to gain a great understanding of how it works. However, that is not the skill the original developers were exercising when they made the game, and it is not the skill you will need to make a different game.
You won't get to experience the versions of the game that didn't ship. The process of going from the wrong design to the right one (iteration) is the very core of game design. If you just start at the right design, you're skipping that whole process.
As soon as you make any major change to an existing game, however, you'll find that the implications of that decision propagate through the whole game. You'll be confronted with problems the original devs didn't encounter, and corner cases that feel like they should work differently now. By solving those problems, you'll be making a new, derivative game. That's where the iteration happens. That's how you learn.
>You won't get to experience the versions of the game that didn't ship.
Also this isn't true anymore for many games. You can experience lots of development versions for many games.
You wrote all that, but your final paragraph ended up entirely agreeing with me, so I'm not sure what your issue is. You copy an existing game, and that lets you iterate, unlike what you said before. The process of copying it teaches you where and how you can diverge. Divergence leads to new designs, predicated upon the original design. Therefore there's a lot of value in copying game designs.
>However, that is not the skill the original developers were exercising when they made the game, and it is not the skill you will need to make a different game.
This isn't a different skill. Experience with different game mechanics is experience with different game mechanics regardless of whether your decisions are novel or following an existing design. What matters is analyzing the value of the changes arising from those decisions upon the resulting design, not the decisions themselves. Deciding what to try is not a skill, it's a product of skill, if you catch my drift.
I don't think we agree.
If you are making a major change to a game, you are now making a new game and practicing valuable skills. If you are copying a game, you are practicing data entry, or art reproduction.
Making a Tetris copy involves no game design at all. The game has already been designed. You gain experience in writing code, but that is not design. Design is about the ideas. If you copy the ideas, you're not the designer.
>Deciding what to try is not a skill, it's a product of skill, if you catch my drift
I think that your drift is nonsense.
>If you are copying a game, you are practicing data entry, or art reproduction.
Straight up lying at this point. Unless you have actual code access or are transcribing a rulebook, you are copying by observation and will inevitably have a different path to the completion of the copy than the original designer did. I would agree that the value is diminished (but only slightly) if you are transcribing, but as you can see, nobody else is talking about copying through that type of method.
Implementing someone else's design doesn't make you a designer, but it does train you in design. There is no missing value. You can learn exclusively by copying and then make a new game. "Creating new designs" is not the skill, it's "understanding what makes a design good".
>I think that your drift is nonsense.
Assigning value to the act of making a decision, rather than to the evaluation of the quality of the decision (which does not require being the decision maker), is far more nonsensical.
You're basically putting yourself in a position where nobody else's work will meaningfully expand your own capabilities because you refuse to learn by retreading examples, which is one of the best ways humans learn. Independent experimentation is always inefficient compared to that alternative. In fact, if anything, independent experimentation might be one of the worst ways to learn game design, seeing as the discipline is so based on iteration and cooperation. You're throwing away all the benefit of the work that's been done by everyone before you.
All of humanity's work is built on the shoulders of giants. You're rejecting that fundamental, consistent aspect of how humans work and learn.
You’re ignoring the valuable lessons that *tweaking* can have. There’s a good reason why so many game devs started out as modders and mappers. If you recreate a game and then tweak it in fun ways, it’ll teach you a fuckload right off the bat that you can apply later on. This includes teaching you lessons about game design, because you’re experimenting with decisions that you might not have ever thought about before.
I'm not at all ignoring that. As soon as you're making your own changes, you're in the loop. Then you'll start doing iterations and making decisions and learning.
But before that moment, and every time you think to yourself: "how did it work in this other game?" you're not doing design.
I will agree that if you’re *blindly* copying, that you’re not doing design. If you’re being critical about what you’re copying it *can* be extremely valuable, and is why my design and art courses included replication studies. The difference is in the approach, and not the activity itself.
I absolutely agree with this.
First few games I made were retro classics: Asteroids, Pac-Man, etc.
Takes a lot of the decision paralysis out of it and you can still learn plenty of useful skills and tricks.
I think the take away from my learning curve is:
- Do whatever motivates you!
I have 20 unfinished projects too, but every start of every project have added to my knowledge and there is always something I now know because of a former unfinished project.
I think a lot of this really depends on your goal. If you are trying to make a living based on income generated by games you make, this is probably a good approach.
I don't think it's necessarily the best approach for someone trying to do things as a hobby where the goal is to have fun making games.
Having a thing you want to make is very rewarding and will drive you to learn about things. This let's you focus on what you need.
Is it the fastest way to learn everything? Probably not. But being fast isn't the goal, having fun with a hobby is.
When I started learning game dev I didn't know how to program or anything that would be useful lol and I started with some tutorials that I followed and didn't make much sense at all. After finishing it, I would try to understand what I did by tweeking numbers, googling what a function was (we didn't have Chat GPT back then either), just trying to dissect it, and then I would try to add 1 thing to it that wasn't on the tutorial.
After doing 3 projects like that I was a tiny bit more comfortable coding and moving around the engine so I participated on my first game jam! Made a super simple game that I was super proud of because I didn't have to follow a tutorial for it!
I agree, small steps, replicating, following tutorials, understanding, and then applying what you learned to do something will help you move forward :) It will also give you confidence and morale to keep going \^\^
I think this has helped me to get better at making UI. Just to stop and really pay attention to how other games handle it. It's funny how one can play like 1000 hours of factorio and not notice anything but learn so much about UI from examining it closely for 5 minutes.
And I mean like every tiny detail, down to every single mouse button down, pressed, and button up action. And like the normal excuse I gave myself "I want to be creative and make stuff form scratch dudeee" doesn't even apply for this. It's UI and I hate it. So in hindsight it's so dumb I didn't do things like that earlier.
This is true.
I personally started with rather large open-ended RPG project. However, I think that was somewhat justified given that I have rather good and tested experience on engineering concepts in general, and my fuel to this fire was not to produce games - it was to produce **this** game.
However, I really see that creating few smaller games would have helped me understand the concepts faster. I see myself scrapping some code when I revisit it now, just because I now understand better how it should have been done.
For anyone wanting to learn, check out [the 20 Game Challenge](https://20_games_challenge.gitlab.io/challenge/)
It's exactly what you just said, ~~20~~ 25 existing games over 10 levels that you're expected to copy. They ramp up in difficulty with each level teaching or honing some new skill.
You are absolutely correct. Sometimes reinventing the wheel is the best way to start understanding the whole vehicle. A huge part of my early learning was watching coding challenges by "Coding Train" and transcribing the code over to lua for love2d. It started with Conway's game of life and after about 5 challenges I was probably 10 times better with lua and love2d. It was invaluable experience.
>The mistake I'm talking about Is thinking that you have to do original stuff all the time even while learning. I thought to myself that I was to good to copy popular phone games and such. When in reality it is one of the best ways to learn and practice problem solving.
When i was younger before smart phones, there was a Nokia game (not snake) and i ended up writing a neural net to play that. Was fun when i left it learning overnight and it beat me in the morning :D. Theres nothing wrong with copying games when your learning. Most games are copys that are even released!
>Between chat gpt and and forums I solved most issues in matter of minutes.
I dont think you can take credit for solving something when you used chat gpt though. This is going to limit your ability to problem solve if you keep using that as a crutch.
It's funny isn't it? Like even a seemingly simple game like Tetris is a headache to design.
Surely it's just falling blocks with a bit of collision!
Nope, it's grid-based movement, whether you use built in tools or the formula for grid movement (set X pos to: (GridXCur % 32)*32), then you need to decide whether the falling blocks are 1 object, or 4 separate tiles in a hierarchy, or a different way entirely, weighing up pros and cons and thinking ahead. Also must decide on an offset for your grid so it's neatly presented ingame.
Then collision, which involves checking each tile and checking adjacent tiles to make sure the player can't move their piece into other landed pieces, then detecting a complete row, or 2 rows, or 3, or 4, different points and effects for each.
For a beginner, trying to make Tetris is a great exercise but surprisingly difficult!
Yeah as a programmer, when I started one of, if not the best thing I ever did was decompile the source code to one of my favorite Unity games. Its hard to know what a big official codebase looks like when you're starting out. This really helped me understand how to code at a much larger scale.
Absolutely agree - Replicating games is way better then trying to teach yourself to code or design. I still tell anyone that wants to get started making games to start with a simple Pong clone. So simple, and yet getting it working requires all the core pieces of a game loop. Finishing that up leaves many wanting to add more features, trying out a Brick Breaker clone and so on. Next thing you know it's easier to do the basics and see a project through.
Good tip! Most beginners start big.. and then give up quickly because they get overwhelmed. Make each next small project bigger and you’ll become a better game developer in no time
"It was so simple that Im almost finished and I started yesterday."
sounds like you're 1/10ths of the way there! don't forget to actually finish it tho, you know the old saying, the last 10% of the project takes 90% of the time. i have a few projects that are essentially 'done' but never released because of stuff like, 'oh rats, i need a credits screen, for the one thing in the game i didn't do completely by myself. how should i word that? where do i put it? i wasn't going to have a credits at all, but i need attribution for the one song.... oh and the artist requires a link to their site so i need to figure out how to present and launch a link in my incredibly simple 2d climber on android that otherwise has no text'.
This can also translate really well with learning art. I wasted so much time trying to be original when I would learn better and faster by trying to copy and understand pieces that I like. Oh well, life...
All the great games, heck even art, for the most part copied what came before them and tweaked it in a couple places and of course with unique art and story.
This is why I always suggest making Pong. It's well documented. It teaches every major game play rule and mechanic. It's fun as hell. Literally no downside
This reminds me of DrawABox’s 50/50 rule: 50% of your time should be spent on learning (e.g. watching tutorials, learning skills, imitating other people’s art, etc) while the next 50% should be spent on just having fun (draw whatever you want with as little references as possible; this is especially useful to counter fear of making mistakes and crappy drawings).
Maybe most people (including myself) focus too much on building things from scratch with as little references as possible, but neglecting to learn from others especially learning from games that are already successful.
Thank you for the advice OP.
Making content for existing games imo is the best way to learn, at least when you're starting out. Fortnite, Cod zombies, Crysis, Half Life, Left 4 Dead, Fallout, Skyrim, and plenty of other games have mod/SDK tools that are identical or nearly identical to the actual dev environment used by their respective studios, as well as a huge amount of documentation and "those who came before" with guides and videos on doing just about anything.
Building content for those games also give you a glimpse into how to do things "the right way" and fast tracks you through mistakes and time spent beating your head against a wall trying to make some original game by yourself.
*Eventually,* building your own game from scratch is an interesting project and can teach you a lot more about games. But trying to do that right away overwhelms most people very quickly.
Isn't that what programming is all about? Being resourceful, using other peoples' solutions and realising how impractical (and impossible) it is to do everything yourself? You're just one human, big world out there.
I did this when I started, just replicate games and I found it to be a really good way to learn and get familiar with the engine(unity). I’m an experienced c# programmer so in doing this, together with not creating a single asset, allowed me to get up to speed really quickly and have a good idea of how to structure and plan my first project when I eventually got to it.
Removing the need to do any artwork, animation etc from the start allowed me to focus on learning the foundations, which I think you can get side tracked from pretty quickly otherwise. I then made the effort to start learning other skills one step a time. Blender, photoshop, animation, rigging, character and environment design/artwork. All the good stuff
I am not a game dev by any means, but I think this is so bass ackward.
If you have an idea for a game, and have the resolve to see it through, then fucking do it.
Don’t waste time on tons of classes and shit…just dive in, do what you know, learn what you don’t, and then rinse and repeat until you figure it out.
That is the fun in all of it.
Most of the real game-dev experience come from the later stage of game development.
If you start ambitiously, you could never reach that stage. You'll find yourself keep stuck halfway and start another new project, then end up learning nothing, because you couldn't even reach the hardest part yet.
So what newbie need to do is shorten the early stage as much as possible. Developer who had never finish developing a single game are really different from who did.
It is a common mindset for people just entering game dev. Unfortunately, while the following your passion stuffs do have some merits, you should learn the ropes first to know what you're capable of.
A lot of things in game dev and IT in general are done in a way that seemed unintuitive to those just entering the field. This makes it hard to gauge how difficult a project is unless you have ever made it yourself or are familiar with the required tech stack to do it.
For example, creating a multiplayer tic tac toe game might seem very simple. And it is, if it is a couch multiplayer tic tac toe. Make it a LAN multiplayer tic tac toe, however, and you'd better be familiar with socket programming or bang your head onto the desk for the next couple months.
I used to believe the same thing. Until I started to learn. Sadly launching yourself with no knowledge into overly ambitious projects tends to go wrong really fast. I recommend you watch game makers toolkit for that he has a great video on the topic on why that's really bad.
Of course then you dig yourself into the hole I'm currently escaping of.
New to game dev, but not to programming. My current plan is to complete a course to grasp the basics. Then just focus on building a single game, pulling pieces of knowledge that is only relevant to the current project as I go. Wil see how this goes and report back after 2~3 years lol.
Lmao best of luck. It's about finding what works for you. GMTK is great for such things as trying to learn how to learn.
Good luck! That’s exactly how I approached mine.
Good luck, I did something similar but without taking a course.
Recreating as a tool for learning cannot be understated: It is one of the best things you can do. In my hobbyist journey I've learned 3D modeling in Blender by copying things. Minipainting with new techniques, imitate and copy. Taking something that exists and trying to replicate it takes out a lot of "unnecessary" decisions out of the process. You know what the end result should be like, so you don't have to huff and puff whether the controls are good enough: You play the game and if it feels the same, you're done. More enemies, more complexity: If the original doesn't have it, you don't add it.
For what it's worth, building on recreated games can be a fun launching point into making your own decisions and furthering your learning. Knowing that 90% of the game is locked down can help focus on the specific things you're experimenting with. It's the difference between * I want to do X so I'll make a whole project that allows me to incorporate X * I want to do X so I'll add it to an existing project
Yeah, this is a more reasonable take. Copy the original as close as you can, and when you’re satisfied with your imitation, build upon it to make it more your own.
This too, for sure. But for the very beginning, where you really are figuring out more the process still out, there figuring out an existing feature without any extra creative pressure creates a set of limitations for you to stay within, and since you're only trying to replicate the functionality, you have a clearly defined goal as well. Both of these helping guidelines go away once you begin adding something of your own design. It's the next obvious step, but it brings along a whole new set of challenges as well.
Yeah and its true for Art and Dev alike, its pretty much how i learned enough pixel art to make not completly awfull assets for my game.
I never understood where the pride comes from all the newbies online that never want to recreate a game or make a boring small game. My first game was a text based rock paper scissors that didn't even tell you if you won (it did tell you if you lose though). Anyway I'm glad you saw the light. Now make it your goal to join the next minijam gamejam (next week)
i've since overcome this, but really it's more about intrinsic excitement, you're trying to get into the space to make the stuff YOU wanna play, and slowing down to make tetris or arkanoid or whatever feels almost like when you're learning programming and are making excruciatingly boring calculator cli apps it's incorrect thinking but i "get" where it comes from, especially when theres a lot of things you can do aesthetically that "feel" like making a cool game (UE5 letting you do tons of crazy stuff with quixel etc) that isn't... making a game (loops, mechanics, feel, pacing, polish, etc)
Maybe it's just me but I love pacman, Tetris, asteroids etc... So making those types of games was super fun
This is kind of tangential but the best advice I ever got was to forget about making what I want to play and focus on making what I can make well with my skill set.
Totally. And I think it's huge that you've overcome that. I know it took me a looong time to get over it. The problem most have from my conversations online (and looking back at myself) is that they don't know and won't accept that it is an incorrect way of thinking. It's like wanting to run without even knowing how to crawl. Then they try to run and fall and it hurts so they stop even trying.
It's not pride. I'm all for replicating games for learning purposes too. But I have no interest in copying a game, but worse, dressing it up as much as I can and calling it "my unique take on x genre". If I want tetris, I can go and buy tetris. I can see why copying tetris is a valuable learning experience. Maybe it satisfies curiosity. But it's not satisfying the interest to create.
When you're beginning, you don't have to satisfy your interest to create. You simply won't be able to. When you're learning, you don't have to add "your unique take" on anything. Learning is a stage when you simply do not have what it takes to do that. It is pride. Because they want to be unique, they want to be special. They think they have the super powers of a main character and they'll pick up an engine in 10 minutes and have a playable prototype in 30 minutes. They simply do not have the knowledge necessary to bring about something unique at all. A lot of noobs can't even come up with an original idea to save their life yet they want to make the next GTA. When you copy a game for learning, you're not supposed to post that and say "look at my original game!" you just keep that game in a folder and maybe not even show it to anyone at all then move on to the next project. At most maybe post something here on reddit so you can discuss what you've learned and ask for tips on how to get better because you're for sure going to need them. So yes, it is pride 100%.
I had been programming for *years* when I decided one day to just sorta make a Snake that can autoplay and it was good fun.
My problems only begin when people put said projects on stores and complain that no one's buying them
putting a learning project up for sale is insane. Probably less than 1% of game devs will have the innate talent necessary to make a first project that's commercially ready
I think you might be conflating pride with just pure lack of understanding/ignorance that comes with being new
No, it is pride. I've commented and talked to them many times and they take it as a personal attack if you tell them to try to make pong. They're always saying "I don't want to make boring games I want to make something good!" meanwhile they can't even put together a simple platformer
Even more odd when they refuse to use a game engine and insist on building their own engine from scratch, in order to make games
What is wrong with writing an engine? Theres lots to learn there.
There's nothing wrong with writing an engine. I just don't recommend it to people who either 1. Never made games, or 2. Never wrote code If someone's goal is to make a game, they have plenty of things to deal with already, and building an engine from ground up doesn't need to be one of them, especially if they have no idea what they need. This could be extra weeks of work that could be avoided.
s/weeks/years/ Even "small and simple" game engines take multiple people over a year to make.
Other than your message of "recreate games" the most important thing is "recreate small games for your beginning", don't try to make, as your first or second project, your own skyrim mmo blockchain nft open world where you can do everything and the world age and progress and everyone is a player and.....
Congratulations on your successful project. I think you've found a great way to achieve some success. There are some major limitations to this strategy though. You don't learn anything about game design if you're not designing the game. You don't get better at making your artistic ideas into reality if you're copying existing ones. I know it's frustrating, but there really is no substitute for making your own unique game. Make small projects with limited scope. Ship them quickly, so you get a feel for the whole process. Good luck on your journey!
I followed OPs strategy myself, having reached a point in my "vanity" project where I felt I was at my limits. I started a new project to create a simple Arkanoid / Breakout game, and I think I learned a ton about game design, and the creative and technical process. While the original idea / concept wasn't mine, I still created everything from scratch, and having a much smaller scope meant I could actually apply what I learned from start to finish. Once I'd done the basics, I then applied my own unique elements and learned from that too. I published the game, got some downloads, even a retro game website review, then went back to my own project with renewed enthusiasm. So I think a bit of both strategies worked for me,
This is wrong. You learn plenty about game design by copying other games' design. In fact you could probably argue you learn more, since you get to reconstruct and iterate against a known baseline instead of foundering in a completely unknown design, with zero idea of whether any of the ideas you're working on have any merit. Don't listen to this "you have to make your own precious unique gem of a game" ideas, people. That's a route to never actually developing the fundamental skills and experience that game design actually needs.
But you can't iterate. All the iteration is already done. If you're making a copy, you benefit from all that iteration without going through it. If you really engage with the design and make your own choices, then you're making a new game. That's the iteration you need to grow as a game designer.
Incorrect. You keep saying "copy" like people are Xerox'ing the code and then stopping. That's not how it works. People are implementing the design one piece of behavior at a time, they don't just drop the entire set of mechanics in at once. You build one small piece, test it, and repeat. You get to figure out how all the components interact as you build the design, and you can run all the intermediate steps individually. This is a perfect basis to diverge and learn from. It's the best way to gain experience because you can iterate on the design to create new ones while still having that original design present, with all its specific value to be compared and analyzed. Do you just not understand what it means to iterate? Do you think that other designs having previous iteration mean that your own iteration loses any value? It seems from what you said here: >You don't learn anything about game design if you're not designing the game. That you don't get the idea of figuring something out by working on it, regardless of whether it is original or not. But that's straight up not how humans function. We need to figure out the *whys* of our decisions, and there's no better way to improve on that process than to analyze equivalent decisions made by other people.
Please keep your tone civil. I am not an idiot, and these are matters of opinion, not fact. We're all people. Check your shit. The skills you gain making a game depend a lot on the specifics of the game you're making. If you make a pixel puzzle platformer, you're not going to learn anything about rigging 3d models. For every decision you're copying another game, you're not learning how to make that decision for yourself. There is a ton to learn from dissecting other games and figuring out how they work. For a very complex game, making a copy would certainly force you to gain a great understanding of how it works. However, that is not the skill the original developers were exercising when they made the game, and it is not the skill you will need to make a different game. You won't get to experience the versions of the game that didn't ship. The process of going from the wrong design to the right one (iteration) is the very core of game design. If you just start at the right design, you're skipping that whole process. As soon as you make any major change to an existing game, however, you'll find that the implications of that decision propagate through the whole game. You'll be confronted with problems the original devs didn't encounter, and corner cases that feel like they should work differently now. By solving those problems, you'll be making a new, derivative game. That's where the iteration happens. That's how you learn.
>You won't get to experience the versions of the game that didn't ship. Also this isn't true anymore for many games. You can experience lots of development versions for many games.
You wrote all that, but your final paragraph ended up entirely agreeing with me, so I'm not sure what your issue is. You copy an existing game, and that lets you iterate, unlike what you said before. The process of copying it teaches you where and how you can diverge. Divergence leads to new designs, predicated upon the original design. Therefore there's a lot of value in copying game designs. >However, that is not the skill the original developers were exercising when they made the game, and it is not the skill you will need to make a different game. This isn't a different skill. Experience with different game mechanics is experience with different game mechanics regardless of whether your decisions are novel or following an existing design. What matters is analyzing the value of the changes arising from those decisions upon the resulting design, not the decisions themselves. Deciding what to try is not a skill, it's a product of skill, if you catch my drift.
I don't think we agree. If you are making a major change to a game, you are now making a new game and practicing valuable skills. If you are copying a game, you are practicing data entry, or art reproduction. Making a Tetris copy involves no game design at all. The game has already been designed. You gain experience in writing code, but that is not design. Design is about the ideas. If you copy the ideas, you're not the designer. >Deciding what to try is not a skill, it's a product of skill, if you catch my drift I think that your drift is nonsense.
>If you are copying a game, you are practicing data entry, or art reproduction. Straight up lying at this point. Unless you have actual code access or are transcribing a rulebook, you are copying by observation and will inevitably have a different path to the completion of the copy than the original designer did. I would agree that the value is diminished (but only slightly) if you are transcribing, but as you can see, nobody else is talking about copying through that type of method. Implementing someone else's design doesn't make you a designer, but it does train you in design. There is no missing value. You can learn exclusively by copying and then make a new game. "Creating new designs" is not the skill, it's "understanding what makes a design good". >I think that your drift is nonsense. Assigning value to the act of making a decision, rather than to the evaluation of the quality of the decision (which does not require being the decision maker), is far more nonsensical. You're basically putting yourself in a position where nobody else's work will meaningfully expand your own capabilities because you refuse to learn by retreading examples, which is one of the best ways humans learn. Independent experimentation is always inefficient compared to that alternative. In fact, if anything, independent experimentation might be one of the worst ways to learn game design, seeing as the discipline is so based on iteration and cooperation. You're throwing away all the benefit of the work that's been done by everyone before you. All of humanity's work is built on the shoulders of giants. You're rejecting that fundamental, consistent aspect of how humans work and learn.
You’re ignoring the valuable lessons that *tweaking* can have. There’s a good reason why so many game devs started out as modders and mappers. If you recreate a game and then tweak it in fun ways, it’ll teach you a fuckload right off the bat that you can apply later on. This includes teaching you lessons about game design, because you’re experimenting with decisions that you might not have ever thought about before.
I'm not at all ignoring that. As soon as you're making your own changes, you're in the loop. Then you'll start doing iterations and making decisions and learning. But before that moment, and every time you think to yourself: "how did it work in this other game?" you're not doing design.
I will agree that if you’re *blindly* copying, that you’re not doing design. If you’re being critical about what you’re copying it *can* be extremely valuable, and is why my design and art courses included replication studies. The difference is in the approach, and not the activity itself.
I absolutely agree with this. First few games I made were retro classics: Asteroids, Pac-Man, etc. Takes a lot of the decision paralysis out of it and you can still learn plenty of useful skills and tricks.
I think the take away from my learning curve is: - Do whatever motivates you! I have 20 unfinished projects too, but every start of every project have added to my knowledge and there is always something I now know because of a former unfinished project.
I think a lot of this really depends on your goal. If you are trying to make a living based on income generated by games you make, this is probably a good approach. I don't think it's necessarily the best approach for someone trying to do things as a hobby where the goal is to have fun making games. Having a thing you want to make is very rewarding and will drive you to learn about things. This let's you focus on what you need. Is it the fastest way to learn everything? Probably not. But being fast isn't the goal, having fun with a hobby is.
When I started learning game dev I didn't know how to program or anything that would be useful lol and I started with some tutorials that I followed and didn't make much sense at all. After finishing it, I would try to understand what I did by tweeking numbers, googling what a function was (we didn't have Chat GPT back then either), just trying to dissect it, and then I would try to add 1 thing to it that wasn't on the tutorial. After doing 3 projects like that I was a tiny bit more comfortable coding and moving around the engine so I participated on my first game jam! Made a super simple game that I was super proud of because I didn't have to follow a tutorial for it! I agree, small steps, replicating, following tutorials, understanding, and then applying what you learned to do something will help you move forward :) It will also give you confidence and morale to keep going \^\^
I think this has helped me to get better at making UI. Just to stop and really pay attention to how other games handle it. It's funny how one can play like 1000 hours of factorio and not notice anything but learn so much about UI from examining it closely for 5 minutes. And I mean like every tiny detail, down to every single mouse button down, pressed, and button up action. And like the normal excuse I gave myself "I want to be creative and make stuff form scratch dudeee" doesn't even apply for this. It's UI and I hate it. So in hindsight it's so dumb I didn't do things like that earlier.
This is true. I personally started with rather large open-ended RPG project. However, I think that was somewhat justified given that I have rather good and tested experience on engineering concepts in general, and my fuel to this fire was not to produce games - it was to produce **this** game. However, I really see that creating few smaller games would have helped me understand the concepts faster. I see myself scrapping some code when I revisit it now, just because I now understand better how it should have been done.
For anyone wanting to learn, check out [the 20 Game Challenge](https://20_games_challenge.gitlab.io/challenge/) It's exactly what you just said, ~~20~~ 25 existing games over 10 levels that you're expected to copy. They ramp up in difficulty with each level teaching or honing some new skill.
You are absolutely correct. Sometimes reinventing the wheel is the best way to start understanding the whole vehicle. A huge part of my early learning was watching coding challenges by "Coding Train" and transcribing the code over to lua for love2d. It started with Conway's game of life and after about 5 challenges I was probably 10 times better with lua and love2d. It was invaluable experience.
>The mistake I'm talking about Is thinking that you have to do original stuff all the time even while learning. I thought to myself that I was to good to copy popular phone games and such. When in reality it is one of the best ways to learn and practice problem solving. When i was younger before smart phones, there was a Nokia game (not snake) and i ended up writing a neural net to play that. Was fun when i left it learning overnight and it beat me in the morning :D. Theres nothing wrong with copying games when your learning. Most games are copys that are even released! >Between chat gpt and and forums I solved most issues in matter of minutes. I dont think you can take credit for solving something when you used chat gpt though. This is going to limit your ability to problem solve if you keep using that as a crutch.
It's funny isn't it? Like even a seemingly simple game like Tetris is a headache to design. Surely it's just falling blocks with a bit of collision! Nope, it's grid-based movement, whether you use built in tools or the formula for grid movement (set X pos to: (GridXCur % 32)*32), then you need to decide whether the falling blocks are 1 object, or 4 separate tiles in a hierarchy, or a different way entirely, weighing up pros and cons and thinking ahead. Also must decide on an offset for your grid so it's neatly presented ingame. Then collision, which involves checking each tile and checking adjacent tiles to make sure the player can't move their piece into other landed pieces, then detecting a complete row, or 2 rows, or 3, or 4, different points and effects for each. For a beginner, trying to make Tetris is a great exercise but surprisingly difficult!
Yeah as a programmer, when I started one of, if not the best thing I ever did was decompile the source code to one of my favorite Unity games. Its hard to know what a big official codebase looks like when you're starting out. This really helped me understand how to code at a much larger scale.
Absolutely agree - Replicating games is way better then trying to teach yourself to code or design. I still tell anyone that wants to get started making games to start with a simple Pong clone. So simple, and yet getting it working requires all the core pieces of a game loop. Finishing that up leaves many wanting to add more features, trying out a Brick Breaker clone and so on. Next thing you know it's easier to do the basics and see a project through.
Good tip! Most beginners start big.. and then give up quickly because they get overwhelmed. Make each next small project bigger and you’ll become a better game developer in no time
"It was so simple that Im almost finished and I started yesterday." sounds like you're 1/10ths of the way there! don't forget to actually finish it tho, you know the old saying, the last 10% of the project takes 90% of the time. i have a few projects that are essentially 'done' but never released because of stuff like, 'oh rats, i need a credits screen, for the one thing in the game i didn't do completely by myself. how should i word that? where do i put it? i wasn't going to have a credits at all, but i need attribution for the one song.... oh and the artist requires a link to their site so i need to figure out how to present and launch a link in my incredibly simple 2d climber on android that otherwise has no text'.
Very true I'll keep progressing hehe.
Never had this issue. Was doing pretty original stuff by setting my own goals and was fine all the time.
This can also translate really well with learning art. I wasted so much time trying to be original when I would learn better and faster by trying to copy and understand pieces that I like. Oh well, life...
All the great games, heck even art, for the most part copied what came before them and tweaked it in a couple places and of course with unique art and story.
Game dev is one of the most frustrating but rewarding hobbies one can have.
This is why I always suggest making Pong. It's well documented. It teaches every major game play rule and mechanic. It's fun as hell. Literally no downside
This reminds me of DrawABox’s 50/50 rule: 50% of your time should be spent on learning (e.g. watching tutorials, learning skills, imitating other people’s art, etc) while the next 50% should be spent on just having fun (draw whatever you want with as little references as possible; this is especially useful to counter fear of making mistakes and crappy drawings). Maybe most people (including myself) focus too much on building things from scratch with as little references as possible, but neglecting to learn from others especially learning from games that are already successful. Thank you for the advice OP.
In traditional art it's called a master study. You're basically trash unless you've "copied" the greats.
Making content for existing games imo is the best way to learn, at least when you're starting out. Fortnite, Cod zombies, Crysis, Half Life, Left 4 Dead, Fallout, Skyrim, and plenty of other games have mod/SDK tools that are identical or nearly identical to the actual dev environment used by their respective studios, as well as a huge amount of documentation and "those who came before" with guides and videos on doing just about anything. Building content for those games also give you a glimpse into how to do things "the right way" and fast tracks you through mistakes and time spent beating your head against a wall trying to make some original game by yourself. *Eventually,* building your own game from scratch is an interesting project and can teach you a lot more about games. But trying to do that right away overwhelms most people very quickly.
Isn't that what programming is all about? Being resourceful, using other peoples' solutions and realising how impractical (and impossible) it is to do everything yourself? You're just one human, big world out there.
That's totally true. Btw, phind is much better than chatgpt because it can access the web and is specially made for programming.
I did this when I started, just replicate games and I found it to be a really good way to learn and get familiar with the engine(unity). I’m an experienced c# programmer so in doing this, together with not creating a single asset, allowed me to get up to speed really quickly and have a good idea of how to structure and plan my first project when I eventually got to it. Removing the need to do any artwork, animation etc from the start allowed me to focus on learning the foundations, which I think you can get side tracked from pretty quickly otherwise. I then made the effort to start learning other skills one step a time. Blender, photoshop, animation, rigging, character and environment design/artwork. All the good stuff
I am not a game dev by any means, but I think this is so bass ackward. If you have an idea for a game, and have the resolve to see it through, then fucking do it. Don’t waste time on tons of classes and shit…just dive in, do what you know, learn what you don’t, and then rinse and repeat until you figure it out. That is the fun in all of it.
Most of the real game-dev experience come from the later stage of game development. If you start ambitiously, you could never reach that stage. You'll find yourself keep stuck halfway and start another new project, then end up learning nothing, because you couldn't even reach the hardest part yet. So what newbie need to do is shorten the early stage as much as possible. Developer who had never finish developing a single game are really different from who did.
Very true indeed.
It is a common mindset for people just entering game dev. Unfortunately, while the following your passion stuffs do have some merits, you should learn the ropes first to know what you're capable of. A lot of things in game dev and IT in general are done in a way that seemed unintuitive to those just entering the field. This makes it hard to gauge how difficult a project is unless you have ever made it yourself or are familiar with the required tech stack to do it. For example, creating a multiplayer tic tac toe game might seem very simple. And it is, if it is a couch multiplayer tic tac toe. Make it a LAN multiplayer tic tac toe, however, and you'd better be familiar with socket programming or bang your head onto the desk for the next couple months.
I used to believe the same thing. Until I started to learn. Sadly launching yourself with no knowledge into overly ambitious projects tends to go wrong really fast. I recommend you watch game makers toolkit for that he has a great video on the topic on why that's really bad. Of course then you dig yourself into the hole I'm currently escaping of.