Glad to see shmups getting some appreciation here. I started from basically no coding knowledge in Scratch by making a shmup. When I moved to Pico-8 after a few false starts my first finished game was once again, a shmup. In both cases it was very easy to get a basic game loop, with a ship that moves around, and one type of enemy appearing at the top of the screen. It was easy to then add more enemies that had different behaviour. Once there were three or four enemy types you get that satisfying 'emergent' game complexity, as enemies firing sideways and enemies firing at random etc. forced the player to dodge, enemies appeared to work together and set traps for the player. After that it was quick and easy to start adding 'verbs' to the game, adding an upgrade system, adding different weapons, a boss. It all felt very modular, any disastrous experiments could easily be removed without breaking the core game loop.
A subgroup of shmups, turret games. Avatar stuck in one spot and you focus on aim and shooting. Lots of old flash games like this that were fun back in the days
The coding in Tetris is surprisingly complex. The way Tetriminos rotate is very specific, and each piece rotates from a different point. The timing on when you can rotate and slide pieces is crazy. And rotations can have a lot of special bump rules. We won't even get into the crazy non-math behind the scoring...
Nonsense. There are 7 Tetrominos. Each has 4 rotations max. That's 28 assets. 19 if you take into account symmetry. You can just hard-code all of the rotation in a few minutes. Nothing about how the Tetrominos move and slide is "crazy". They move on a timer one tile at a time. The collisions are piss easy - you can easily just iterate through all of the tiles they are about to occupy. Way simpler then collisions in sprite-based games. Crazy Math on the Scoring: Singe = 40 Double = 100 Triple = 300 Tetris = 1200 Sorry, there is nothing crazy happening here
@@LazyDevs spoken like someone who's never dug into the game. There's a minimum of five different official scoring methods, and none of them are as straight forward as what you posted. There's also a ton of rules around how pieces rotate and slide vs the timing of the movements. Also, I only said it was complex, not difficult. It was quite fun recreating Tetris correctly. But hey, it's whatever. I'll continue to have fun, you continue to oddly gatekeep against your own channel philosophy. Weird choice though.
@@ShadowDrakken I agree that tetris would be one of the more involved falling block games to create, but since this is a video on making a first game I think the focus here is to recreate the concept and not exactly replicate the behavior of an official tetris game. You could just have pieces not be able to rotate if they dont have room, and have a piece lock in place the moment it tries to move down into something it collides with. As for scoring, you could just have 100 points times the amount of lines cleared at once. None of it has to be official or accurate internally when youre just trying to make shapes fall and lock together to learn how to code a game for the first time.
I think making an early "arcade style" platformer would be acceptable for first game. Single screen, enemies just doing their own thing (so pretty much no AI, just going back and forth, etc.) and need to be avoided (collision = player death). I am thinking stuff like original Donkey Kong in arcades, or Manic Miner on ZX Spectrum. Sure, you need to design some levels, but as long as they are single screen it shouldn't be too hard. Not to mention there will be plenty of tutorials and/or solutions on how to implement platforming in a given engine. Generally anything from early arcades, or pre-NES consoles would be a gold-mine for first game ideas. Those games usually have super simple rules, have next to no AI (at least before we get to Pac-Man) and have graphics simple enough for anyone to try something in that style. Not to mention, there's bunch of genre "dead ends" in there - types of games that never really took off or where just so unique that they fit no genre. Sure, those won't have an "userbase" but can attract people because they are something not commonly seen :)
I think if you really want to do a platformer going 1-screen would be best. I would avoid just any enemies altogether. I agree that Arcade games can be a treasure trove of simple game ideas!
@@LazyDevs Yeah, I wrote the comment before watching your other video and you make the same point there :) My bad. Another simple game I thought of is lightgun games, but without the lightgun (just an aiming reticle moved via mouse or gamepad). Remaking something like duck hunt or hogan's alley would not be too hard and the levels can be procedural to when, how the enemies pop out. I had some fun with mouse driven games like that. There was this series in Poland called Kurka Wodna (which I think was just a translation of a German game) about shooting chickens. Curiously, this was the first game I ever attempted making. It was somewhere in late 90s/early 2000s with some game making software that was on a magazine CD (probably CD action, I used to buy it religiously back then). Never finished it tho, so take that as you wish :P
Arcade 1. The goal is a better score 2. It can be endless or have an end 3. It's meant to be pickup and play 4. Simple controls 5. Uses some of your genre suggestions
Quite surprising my first game, a Paper-Rock-Scissors game falls under the one-button game, or in my case it has three buttons. It had a simple goal and that is to defeat all the characters to win the game. I am quite happy that I chose a simple yet easy to make genre as my first proper game after I decided to put aside my supposedly first project, a multiplayer TCG which gave me a hard time to code even though I also had fun working on the game.
9:28 this reminded me of a classic quote by Seanbaby (an amazing video game satirist) “Two directions and a button? Dear god why does your Donkey Kong creation mock me with its indecipherable madness!?!” lol
Great advice, as usual. I kinda tempted fate by starting with a platformer, but it had a procedurally-generated world and no enemies to keep things simple. ; )
your videos deserve more views! super awesome breakdown. When I finally sat down to make my first commercial game it was a physics based racing game, definitely will make one again to see how much I retained, I think that it would be worth it to create a course for students to create one of each of these games over the course of the class, from design to completion!
This is an amazing video. Thank you for doing this. As a beginner, scoping a game is challenging, and this video gives me some specific guidance on that. :) Thank you!
Hard to make a good Shmup, totally ! I've been developing one since September 2019 called Solitons (my background is physics and mathematics). I programmed the entire architecture of the game in 6 months, but the design part is what gets the most attention. I've got two people I've hired to do the artistic part, I've already spent $5,000 on the project in total, and that's what my goal is to make a good simple horizontal shmup with 5 small levels. The name of the game is Solitons and it has a Steam page.
I wanna say, puzzle games and tetris are both incredibly challenging games to make. Tetris has some wild mechanical requirements in regards to rotation and making blocks fit and fall properly. Puzzle games are by far one of the most difficult genres to make. They require an insane amount of playtesting and level design experience, neither of which new devs are likely to have. They may have one simple mechanic, but puzzles are about solving problems and thinking outside the box, meaning its way more likely for a player to really push at those edge cases. In order to make a decent puzzle without insane effort, the best thing I can think of is something like a pin-pull game or maybe a rotation-based puzzle where you find a path to the end, like the hacking mini game in bioshock. I want to add snake as a game option here. I've also made a super basic turn-based text rpg as my first game (it was in java and i hated dealing with java GUI so anything to save me from actually drawing to the screen was a winner) and I'd recommend that as well. I'm honestly getting a lot of mixed signals about starting out from this channel. I'm not sure what kind of "first game" this is supposed to be. I had the same issue with the list of genres to not start out with as well. These genres seemed to be geared towards a person's first time working in a game engine, but there's a lot of discussion about what an audience would expect from the game, which I would argue is not a great way to approach early game dev. Not to mention that puzzles, in my opinion, aren't really a great entry point for game dev, unless you already have experience with making other forms of puzzles. I'm still fairly new to game dev, but I've made a couple small projects, tested out a few engines (as well as the experience of not having one) and I've followed some early tutorials as well. A one-button game, shoot em' up or snake would be my recommendation if you're looking for tutorials to help get you started. Idle games are also a pretty good option as well. I know you argued against tower defense games, but I would argue that a super basic, pathless tower defense could work well as a second game, since there are a few extra moving parts. I'd also argue that it's better to finish very basic mechanics and move on rather than trying to truly finish everything you make when starting out. Not every project has to be a full game. I would suggest making a few projects where you can play with mechanics like power-ups or random enemy spawning or melee damage vs ranged damage or different enemy types. You'll learn a lot more that way and won't have the pressure of making a fully finished game. It's good to finish the game loop of your first game, just to give yourself an idea of what it's like, but I don't think its necessary to finish a game in order to be proud of what you made beyond that. I'd be proud of what I'm working on right now if I dropped it today, because it's still something I made and its the furthest I've gotten thusfar.
You over-estimate puzzle games exactly for the reasons mentioned in the video. Tetris in particular is pretty straight-forward. The amount of code required to run a version of Tetris can fit in a single tweet. It's just a few simple rules iterated over a grid of values. It is what programming is really good at. I had many students try idle games. There are a bad choice. They require a lot of UI work which is tedious and has a tendency to spiral out of control. They are games that live on a steady drip-feed of new content and making all that content takes more time than you think. Finally, play-testing them takes ages. Snake is a pretty good choice. Experiments are fine but eventually you need to aim to finish games because scope management is the most important skill as a game developer.
I wrote a version of Tetris in a day a couple of years ago I don't understand why people think it's difficult. It was very easy and straightforward, maybe because I didn't use a game engine which can make some of these very simple things more complicated than necessary. Not sure I think a lot can go wrong if you try to do something perfectly. I wrote the game and people played it and that was it.
I would like to see a Tetris like tutorial sometime. That one has a lot of tricky coding involved (hello 2d arrays). One early pico8 game I made was basically a Labyrinth puzzle game, but with some adventure game elements. There’s some good tutorials for those out there.
Go back to an old project and finish it. I've done this a couple of times and it helps to motivate. Change the scope. Make it smaller, more focused, but get it into a finished state.
Having watched hundreds if not thousands of hours of similar tutorials, I wish I started with this one! It's obviously not an exhaustive list of possiblities, but anyone could make SOMETHING with at least one of the above. BTW, why am I suddenly craving an omelette?
One pitfall with labyrinth style games, is that they can cross over with true rogue-like games, which can be insanely complex since it is essentially an open-world rig, and everything interacts with everything else. For example, you made porklike, but it can easily be expanded.
I like these ideas. 1-button, especially. I've done a game with 2 buttons (jump and drop presents into a chimney) and it was surprisingly satisfying. Never tried racing before but it does look quite doable. I've been afraid of falling block because I always felt like the ones that are out there are already so good... Like Tetris and Puzzles & Dragons. But you have a point, the general public seems to be open-minded about the genre. I think Whack-A-Mole and Asteroids could also be in there. Maybe I'd call them "single-screen" games. All action happens on one screen, and with a minimal amount of additional windows/popups. It's another nice constraint and overlaps with the falling block genre you mentioned.
Yeah Puzzle Games can seem so "perfect" from the outside. You feel like whatever you do will never live up to the originals. As if the developers had some kind if insight into games you don't have. I think that's just projection. I actually looked it up and "Yoshi" was a bit of a dud, actually. And Myamoto worked on it. If Myamoto can release a subpar puzzle game so can you! Whack-A-Mole seems like a good idea to me! Asteroids is fine too. Ship rotation can be a bit tricky.
Haha, that's fair. I'd say puzzle game levels aren't easy to design. But they don't escalate in effort and time requirements as other type of content. You don't have to create new artwork. You don't have to write dialogue. The size and scope is well under control.
Another option is "ponglike". Simple things that bounce around and touch and that's it. My first game was a simple "grab the balls" game, but I added the little twist that you were on one side of the playfield visually and the other side for collisions. Simple fun for 20 minutes, and quite low art requirements. Stepping games are possible (what you call labyrinth games, especially with the no real time constraint) but the problem is if someone knows DROD they suddenly become extremely nitpicky :P
"Ponglike" is a good choice. Only issue is that Pong is muli-player and so even if you have somebody you can playtest it with, you just obliterate your potential audience size. And turning Pong into a single-player game is tricky. Writing a fun AI for it is tough. So what you did is probably the better choice - just freely designing your own additional rules and mechanics on top. But then that can be quite a stumbling block for some. Glad to hear it worked well for you!
@@ShadowWolfTJC Kinda but there is one big difference: Akanoid/Breakout has bricks and those can be tricky when it comes to collisions. Despite this, I would still say it is a good choice
@@LazyDevs I can send you the p8 file if you want. :) I made a video about my design experience here in my Facebook. Starts at 39:18 since in the first half, I talk about the basics of Pico-8: facebook.com/marvin.m.flores.75/videos/10216829315593865
I made a lot of games with my ZX-Spectrum. Nothing big. A simple thing could be popular for the cousins, neighbours and family. I was mostly in it for making something with the code. A game was just a piece of the confusion or the experiment. I got an education from it. Nothing big either and I chose another profession as there was no "game development" and the alternative was boring... like typing and formatting numbers and lines in a bank. A few things helped me through life any way.
I mean I did a beginner tutorial for breakout. ;) Pong is really nice because you can whip it up in no time at all. But also, it's really only fun in multi-player. Coding an AI is for them is weird. It's trivial to just make a perfect AI. So you need to make the AI deliberately flawed. And then the game becomes about recognizing and exploiting that flaw and that doesn't feel right either. You need a whole bunch of additional game design to make it a viable single-player game. Breakout is better but the collision detection with the bricks can be actually quite tricky, as I have discovered. You can get one going easily. But to it can be tough to make it consistent. In the tutorial I had to rewrite the collision like 3 times to cover all the weird glitches that came up. It's a small tech rabbit hole actually.
What about simplistic platformer or platformer-adjacent games like not only Donkey Kong 1, 2, and 3, or (NOT Super) Mario Bros., but also Burger Time, Popeye, Pickaxe Pete, Mappy, Bubble Bobble, or Flicky? Of course, the 1st potential pitfall would have to be collision detection, so that the player character wouldn't be able to pass through floors, walls, or ceilings unless it's supposed to happen (plus maybe enemies, unless they're meant to fly through terrain like ghosts). Many games impose speed limits not only for player movement but also for falling movement, in combination with some fairly thick terrain, to help prevent these kinds of glitches from occurring. (I believe that, in Sonic the Hedgehog's case, its collision detection needed to be more advanced in order to account for Sonic running up and down walls, and even upside-down while passing through those loop-de-loops, and furthermore, the game needed to account for how fast Sonic could move.) Like with shoot'em ups, platformers would likely have a dedicated fanbase behind them, so trying to make sure that whatever platformer you create would at least be realistic to implement, if not good enough to satisfy those fans of platformers, might be another potential pitfall. Scope creep would obviously be a potential pitfall, such as trying to recreate Super Mario Bros., Celeste, or Super Meat Boy for example, all of which are pretty long games. Granted, you might be able to rapidly churn out enough terrain to match those games using procedural generation (which I suspect was the case for Super Mario Bros. in order to keep under the 32KB ROM space limit), but you'll need to make sure that the terrain that's generated is playable 1st, functional a close 2nd, and decent-looking a distant 3nd. Slopes and semi-solid platforms could be 2 more potential pitfalls to have to deal with. Sure, if you can overcome those challenges implementing these features, they could help make your platformer shine. However, other things that help make your platformer more unique from most others could also make your platformer shine, perhaps even more so, even without slopes or semi-solid platforms. A screen that moves with the player as they travel through levels, such as in Super Mario Bros., could be another potential pitfall. Nearly every early 2D platformer game, prior to Super Mario Bros., along with a few afterwards, didn't even attempt to work with a moving screen. At best, if multiple interconnected screens were required (like in Pitfall or Monty on the Run), then the game would've simply warped the player character to the next screen over, not necessarily even doing screen scrolling like in The Legend of Zelda or Mega Man in many cases. Many platformers that had dynamic horizontal scrolling, like Super Mario Bros., would try to move the camera in front of the player, so that the player could see further to the left or right as they were moving the player character left or right. (One side-scrolling platformer that I'd argue has poor camera movement would be Turrican. Don't program your camera to lazily follow behind the player, thus restricting their view forward, like in Turrican, please!?) Some platformer games with vertical scrolling, like Kid Icarus, would only move the screen upwards if the player landed on solid ground above a certain height, and attempting to scroll down by falling towards the bottom of the screen would only result in instant death, as if the player had fallen into a bottomless pit.
My first game was made in excel and i made a (very simple) rogue-like game. Then i'm trying to move it to pico8 but i keep learning the lua language and restarting it...
I‘d say they are more platformers. But as far as platformers go probably one of the more viable choices since there is no jumping. Enemy pathfinding might get a bit tricky
I think I said this before at some point but ya a smup was a good idea for a game, at least for a game jam when I didn't have much time and I just had to worry about a handful of things like a tiny bit of collision and enemies and there was no map. Great genera to try out for sure.
@@LazyDevs ya it was for the Löve 2021 jam, itch.io/jam/love2d-jam-2021/rate/931493 It has some bugs and issues but I was pretty happy with it, would want to try to make another shmup at some point, like I said trying it took some of the content issues out and made it easier. edit: also you may have to open it with löve, I didn't port it for each ver and instead just uploaded the .love file.
I have to say your channel offers well prepared and thought-out content, however it is sorry to see that your view count is far lower than other channels that don't offer content of this standard
I'm not convinced the physics in a racing game even the micro machines one you put there is a good fit for a first game in pico 8. There are a lot of calculations to do. Spriteing is also difficult for the cars unless you use an 8 way controller. So this means knowing how to do rotation. However having said that I do agree that its something that Unity (which is not something I've actually used) should make easier. When starting pico-8 I made a snakes clone as cell based movement is easier than discrete movement and collision detection is easier. (is there something in that cell). With regards to your one button game, I think you're confusing something like flappy bird which is yes 1 button with something like temple run which takes 4 inputs as far as I can see. Move left move right jump and duck (which seems to be a pretty standard fair for infinite running games) My recommendation would be to produce anything thats simple and has limited movement. Such as snakes, falling block games, minesweeper, card games. Even doing a high low game can be instructive. But yeah something that can be finished. Great Vid. Thanks.
These are fair observations. I do not necessarily disagree. Rotations can be tricky in Pico-8. But the main issue is really that you can't rotate sprites so you have to do it by rotating the sprite by hand in the sprite sheet. The trigonometry for 360° movement just feels intimidating. It's actually really simple and you'll need it all the time in other genres. In any case, if that's too much of a hassle you can make an even simpler racing game - basically a shmup without the shooting. Snakes is not much of a genre, it's just one game. Snakes is just ok. Snake has an unappealing effort vs results ratio. Keeping track of the body segments and always making the last one disappear as you move is surprisingly tricky. As in - it looks like it would be simple but you have to set up a quite elaborate system. Like, going from TRON Lightbike to Snake is not the simple jump you THINK it would be. You need to set up an array of body segments. Or you store the body segments as tiles in the map and do smart tile tricks to find out where the tail is. And it gets even more convoluted if you want smooth movement animations. And after all that effort what you get is ... just another snake game. Meh. This is just my practical experience - I've seen students struggle with remaking snake only to be kinda stuck with something that's passable but underwhelming - not being able to turn it into something exciting. It's not a BAD game to start with. But I don't think it's particularly good either. To me the endless runners evolved from one button games. Canabalt back in the day was huge. There were also successful, cheap follow-ups like The Impossible Game. Mobile was a very good platform for these games to flourish. Over the time the controls just got a tiny bit more elaborate. "Limited movement" is fair but a bit vague. Your recommendations don't really match. Minesweeper doesn't really have anything that moves. Card games are a bad idea, I think - They end up being a UI/Usability rabbit hole. They can be a good system to experiment with when doing physical board games.
@@LazyDevs Agreed the sprite rotation is the hardest part of it. I feel like 4 way rotation should have been built into pico itself. A standard rotation library would help but that's just not how pico does things. There have been lots of variations on snakes over the years, since anaconda. Making the last segment disappear isn't too difficult of a programming challenge. I've seen tutorials that take a different approach but my one is basically keep a list of segments. What I do feel about snakes is its good as a learning exercise for more arcadey games. Theres one type of data to keep track of the play field but you still need to handle inputs and timings and basic array manipulations. However I do agree the reward is a bit lacking. Limited movement I mean effectively tile based games, rather than something like a platformer where you have many types of collision to deal with and lots of sub positions. I think artillery games (worms, scorched earth, gorilla) etc may also be a good programming exercise. But unfortunately these lend themselves to being two player games more. One last recommended genre is the rhythm game. Simple to code. Is the player pressing the correct button at the correct time. Think guitar hero but without the music being the prompt. That genre means the game loop can be simple but you can add lots of embellishments.
Maybe the genre they pick seem bad because nobody knows to teach them properly on those genres? Or maybe it is a lack of proper genre terminology which is something very common these days as everyone has a say on and about genres but most people fail to understand the term genre as such and so they come up with run of the mill bullshit terms. 1. No. One button games are intuitively boring. Make it at least two buttons. Because then you can create simple platformers more effectively or fun games like Epic Loons. 2. Like that one.Easy to understand mechanics. Most of the time. But how many get as creative as things like Gradius and R-Type? 3. Never as a starting genre. Never. Tetris can be complicated to program properly. That is the reason why so many successful Tetris denominators exist. 4. Labyrinth type games are boring. 5. Cool idea but can also be very complicated. You can range from remote control type racing games like Micro Machines or totally complex like Gran Tourismo.
Making a "boring" game is going to be among the most favorable outcomes starting out with gamedev. If you are intimidated by Tetris then honey you will not make it far in this profession
The sad thing about shmups is that the traditional kind has gone all but extinct in favour of bullet hell games, which, while popular for their challenge, are an annoyingly stagnant subgenre in comparison to the often quite experimental nature of e.g. Irem's arcade shooters.
Come on, what are you even talking about? R-Type Final 2 came out just this year, made by ex Irem staff. Last year we had gems like GG Aleste 3, an on-spec Game Gear game in 2020! And if you really want something experimental - indie Shmups like Dezatopia or Project Starship X are coming out all the time. Nothing is "extinct" and somehow blaming Bullet Hell accomplishes nothing but poisoning the discourse. Shmups exist in all shapes and sizes, appeal to different tastes and I have yet to play a title that didn't bring something new to the table. I wished other genres were as diverse and experimental as Shmups.
Nah. Racing games are hard, and 2d racing games are often disappointing. And they're also a content rabbit hole. And the tech rabbit hole is not only in enemy AI, also engine/speed simulation, physics simulation (suspension and friction and collisions), checkpoints/time calculations... only engine sound is a huge topic. People expect some kind of vehicle customization for progression - if it's a commercial game. If it's a 3d racing game, I expect the driving to feel better than in GTA, and that's a reasonably tall order for an indie title, not to mention creating the world/tracks and assets. I know, because I've started working on a few, gave up and restarted work several times. It's just hard to limit the scope of a racing game and have it be interesting, you're more likely to make a basic arcade racer with annoying gimmicks. But I would like to see more of them coming out. Since Codemasters is gone, and the proper NFS developers are scattered into the 4 winds, there's some room for small and medium scale racing games.
Those are great advices but I don't understand why bother with trying to make a good playable game, prototypes should be enough, because if you're still traning you should first learn how to take notes and write a good GDD that any team member is able to read. Solo developers exist but they're often workaholic, have different skills that take a lot of time to learn, and will miss learning from experienced people; i don't think this is a healthy way to start a career.
Oh yeah. This is advice for solo devs because that's how pretty much everybody starts out. Team communication is a whole different can of worms and I might talk about that some other time. Sure, solo devs are in danger of over-scoping and can easily burn out. But so do teams. It's a universal GameDev problem. Protoypes are good and certainly part of the process. But they will only get you so far. You learn how to make games by making games.
Instruction unclear, started working on a MMORPG.
Glad to see shmups getting some appreciation here. I started from basically no coding knowledge in Scratch by making a shmup. When I moved to Pico-8 after a few false starts my first finished game was once again, a shmup.
In both cases it was very easy to get a basic game loop, with a ship that moves around, and one type of enemy appearing at the top of the screen. It was easy to then add more enemies that had different behaviour. Once there were three or four enemy types you get that satisfying 'emergent' game complexity, as enemies firing sideways and enemies firing at random etc. forced the player to dodge, enemies appeared to work together and set traps for the player. After that it was quick and easy to start adding 'verbs' to the game, adding an upgrade system, adding different weapons, a boss. It all felt very modular, any disastrous experiments could easily be removed without breaking the core game loop.
Oh man, I missed this comment. That's awesome to hear! Did you publish your game somewhere?
A subgroup of shmups, turret games. Avatar stuck in one spot and you focus on aim and shooting. Lots of old flash games like this that were fun back in the days
Oh yeah! Even better than a Shmup. No scrolling!
The coding in Tetris is surprisingly complex. The way Tetriminos rotate is very specific, and each piece rotates from a different point. The timing on when you can rotate and slide pieces is crazy. And rotations can have a lot of special bump rules. We won't even get into the crazy non-math behind the scoring...
Nonsense. There are 7 Tetrominos. Each has 4 rotations max. That's 28 assets. 19 if you take into account symmetry. You can just hard-code all of the rotation in a few minutes. Nothing about how the Tetrominos move and slide is "crazy". They move on a timer one tile at a time. The collisions are piss easy - you can easily just iterate through all of the tiles they are about to occupy. Way simpler then collisions in sprite-based games.
Crazy Math on the Scoring:
Singe = 40
Double = 100
Triple = 300
Tetris = 1200
Sorry, there is nothing crazy happening here
@@LazyDevs spoken like someone who's never dug into the game. There's a minimum of five different official scoring methods, and none of them are as straight forward as what you posted. There's also a ton of rules around how pieces rotate and slide vs the timing of the movements.
Also, I only said it was complex, not difficult. It was quite fun recreating Tetris correctly. But hey, it's whatever. I'll continue to have fun, you continue to oddly gatekeep against your own channel philosophy. Weird choice though.
@@ShadowDrakken I agree that tetris would be one of the more involved falling block games to create, but since this is a video on making a first game I think the focus here is to recreate the concept and not exactly replicate the behavior of an official tetris game. You could just have pieces not be able to rotate if they dont have room, and have a piece lock in place the moment it tries to move down into something it collides with. As for scoring, you could just have 100 points times the amount of lines cleared at once. None of it has to be official or accurate internally when youre just trying to make shapes fall and lock together to learn how to code a game for the first time.
I chuckle at your advice of making your car *explode* during collision, that's really practical! haha
I watched a lot of Fast & Furious for this wise lesson ;)
I think making an early "arcade style" platformer would be acceptable for first game. Single screen, enemies just doing their own thing (so pretty much no AI, just going back and forth, etc.) and need to be avoided (collision = player death). I am thinking stuff like original Donkey Kong in arcades, or Manic Miner on ZX Spectrum.
Sure, you need to design some levels, but as long as they are single screen it shouldn't be too hard. Not to mention there will be plenty of tutorials and/or solutions on how to implement platforming in a given engine.
Generally anything from early arcades, or pre-NES consoles would be a gold-mine for first game ideas. Those games usually have super simple rules, have next to no AI (at least before we get to Pac-Man) and have graphics simple enough for anyone to try something in that style. Not to mention, there's bunch of genre "dead ends" in there - types of games that never really took off or where just so unique that they fit no genre. Sure, those won't have an "userbase" but can attract people because they are something not commonly seen :)
I think if you really want to do a platformer going 1-screen would be best. I would avoid just any enemies altogether.
I agree that Arcade games can be a treasure trove of simple game ideas!
@@LazyDevs Yeah, I wrote the comment before watching your other video and you make the same point there :) My bad.
Another simple game I thought of is lightgun games, but without the lightgun (just an aiming reticle moved via mouse or gamepad). Remaking something like duck hunt or hogan's alley would not be too hard and the levels can be procedural to when, how the enemies pop out. I had some fun with mouse driven games like that. There was this series in Poland called Kurka Wodna (which I think was just a translation of a German game) about shooting chickens.
Curiously, this was the first game I ever attempted making. It was somewhere in late 90s/early 2000s with some game making software that was on a magazine CD (probably CD action, I used to buy it religiously back then). Never finished it tho, so take that as you wish :P
Arcade
1. The goal is a better score
2. It can be endless or have an end
3. It's meant to be pickup and play
4. Simple controls
5. Uses some of your genre suggestions
Sure. But also "Arcade" is not a genre. Plenty of very different Arcades games out there: Racing, Shmup, Brawlers, Fighting Games, Puzzle, etc...
Quite surprising my first game, a Paper-Rock-Scissors game falls under the one-button game, or in my case it has three buttons. It had a simple goal and that is to defeat all the characters to win the game. I am quite happy that I chose a simple yet easy to make genre as my first proper game after I decided to put aside my supposedly first project, a multiplayer TCG which gave me a hard time to code even though I also had fun working on the game.
RPS seems like a good choice for your first game!
9:28 this reminded me of a classic quote by Seanbaby (an amazing video game satirist) “Two directions and a button? Dear god why does your Donkey Kong creation mock me with its indecipherable madness!?!” lol
Isn't Donkey Kong actually 4 directions and a button, since there are ladders in the game?
Great advice, as usual. I kinda tempted fate by starting with a platformer, but it had a procedurally-generated world and no enemies to keep things simple. ; )
You absolutely can get away with a platformer. No enemies is a good way to simplify things!
your videos deserve more views! super awesome breakdown. When I finally sat down to make my first commercial game it was a physics based racing game, definitely will make one again to see how much I retained, I think that it would be worth it to create a course for students to create one of each of these games over the course of the class, from design to completion!
Thanks! Yeah, that's essentially the idea. Will get there eventually.
This is an amazing video. Thank you for doing this. As a beginner, scoping a game is challenging, and this video gives me some specific guidance on that. :) Thank you!
Hard to make a good Shmup, totally ! I've been developing one since September 2019 called Solitons (my background is physics and mathematics). I programmed the entire architecture of the game in 6 months, but the design part is what gets the most attention. I've got two people I've hired to do the artistic part, I've already spent $5,000 on the project in total, and that's what my goal is to make a good simple horizontal shmup with 5 small levels. The name of the game is Solitons and it has a Steam page.
Oooh sounds exciting! Sounds like you are committed. Good luck!
I wanna say, puzzle games and tetris are both incredibly challenging games to make. Tetris has some wild mechanical requirements in regards to rotation and making blocks fit and fall properly. Puzzle games are by far one of the most difficult genres to make. They require an insane amount of playtesting and level design experience, neither of which new devs are likely to have. They may have one simple mechanic, but puzzles are about solving problems and thinking outside the box, meaning its way more likely for a player to really push at those edge cases. In order to make a decent puzzle without insane effort, the best thing I can think of is something like a pin-pull game or maybe a rotation-based puzzle where you find a path to the end, like the hacking mini game in bioshock.
I want to add snake as a game option here. I've also made a super basic turn-based text rpg as my first game (it was in java and i hated dealing with java GUI so anything to save me from actually drawing to the screen was a winner) and I'd recommend that as well.
I'm honestly getting a lot of mixed signals about starting out from this channel. I'm not sure what kind of "first game" this is supposed to be. I had the same issue with the list of genres to not start out with as well. These genres seemed to be geared towards a person's first time working in a game engine, but there's a lot of discussion about what an audience would expect from the game, which I would argue is not a great way to approach early game dev. Not to mention that puzzles, in my opinion, aren't really a great entry point for game dev, unless you already have experience with making other forms of puzzles.
I'm still fairly new to game dev, but I've made a couple small projects, tested out a few engines (as well as the experience of not having one) and I've followed some early tutorials as well. A one-button game, shoot em' up or snake would be my recommendation if you're looking for tutorials to help get you started. Idle games are also a pretty good option as well. I know you argued against tower defense games, but I would argue that a super basic, pathless tower defense could work well as a second game, since there are a few extra moving parts.
I'd also argue that it's better to finish very basic mechanics and move on rather than trying to truly finish everything you make when starting out. Not every project has to be a full game. I would suggest making a few projects where you can play with mechanics like power-ups or random enemy spawning or melee damage vs ranged damage or different enemy types. You'll learn a lot more that way and won't have the pressure of making a fully finished game. It's good to finish the game loop of your first game, just to give yourself an idea of what it's like, but I don't think its necessary to finish a game in order to be proud of what you made beyond that. I'd be proud of what I'm working on right now if I dropped it today, because it's still something I made and its the furthest I've gotten thusfar.
You over-estimate puzzle games exactly for the reasons mentioned in the video. Tetris in particular is pretty straight-forward. The amount of code required to run a version of Tetris can fit in a single tweet. It's just a few simple rules iterated over a grid of values. It is what programming is really good at.
I had many students try idle games. There are a bad choice. They require a lot of UI work which is tedious and has a tendency to spiral out of control. They are games that live on a steady drip-feed of new content and making all that content takes more time than you think. Finally, play-testing them takes ages.
Snake is a pretty good choice.
Experiments are fine but eventually you need to aim to finish games because scope management is the most important skill as a game developer.
I wrote a version of Tetris in a day a couple of years ago I don't understand why people think it's difficult. It was very easy and straightforward, maybe because I didn't use a game engine which can make some of these very simple things more complicated than necessary. Not sure I think a lot can go wrong if you try to do something perfectly. I wrote the game and people played it and that was it.
I would like to see a Tetris like tutorial sometime. That one has a lot of tricky coding involved (hello 2d arrays).
One early pico8 game I made was basically a Labyrinth puzzle game, but with some adventure game elements. There’s some good tutorials for those out there.
Great video and breakdown of your suggestions!
Glad it was helpful!
This video arrived 2 years late. I've done nothing but craft unfinished garbage for 2 years and only now i realize thats why i cant progress.
Don't beat yourself up about it. It's a common issue.
Go back to an old project and finish it. I've done this a couple of times and it helps to motivate. Change the scope. Make it smaller, more focused, but get it into a finished state.
Having watched hundreds if not thousands of hours of similar tutorials, I wish I started with this one! It's obviously not an exhaustive list of possiblities, but anyone could make SOMETHING with at least one of the above. BTW, why am I suddenly craving an omelette?
One pitfall with labyrinth style games, is that they can cross over with true rogue-like games, which can be insanely complex since it is essentially an open-world rig, and everything interacts with everything else. For example, you made porklike, but it can easily be expanded.
True, all projects can have the potential to explode. You need to come to terms with the fact that you are making JUST a Labyrinth game.
I like these ideas. 1-button, especially. I've done a game with 2 buttons (jump and drop presents into a chimney) and it was surprisingly satisfying. Never tried racing before but it does look quite doable. I've been afraid of falling block because I always felt like the ones that are out there are already so good... Like Tetris and Puzzles & Dragons. But you have a point, the general public seems to be open-minded about the genre.
I think Whack-A-Mole and Asteroids could also be in there. Maybe I'd call them "single-screen" games. All action happens on one screen, and with a minimal amount of additional windows/popups. It's another nice constraint and overlaps with the falling block genre you mentioned.
Yeah Puzzle Games can seem so "perfect" from the outside. You feel like whatever you do will never live up to the originals. As if the developers had some kind if insight into games you don't have. I think that's just projection. I actually looked it up and "Yoshi" was a bit of a dud, actually. And Myamoto worked on it. If Myamoto can release a subpar puzzle game so can you!
Whack-A-Mole seems like a good idea to me! Asteroids is fine too. Ship rotation can be a bit tricky.
This is fantastic 👍
i love the scrambled egg analogy
Sokoban levels are easy to design!? Citation needed
Haha, that's fair.
I'd say puzzle game levels aren't easy to design. But they don't escalate in effort and time requirements as other type of content. You don't have to create new artwork. You don't have to write dialogue. The size and scope is well under control.
funtastic! i like the layout too
Another option is "ponglike". Simple things that bounce around and touch and that's it. My first game was a simple "grab the balls" game, but I added the little twist that you were on one side of the playfield visually and the other side for collisions. Simple fun for 20 minutes, and quite low art requirements.
Stepping games are possible (what you call labyrinth games, especially with the no real time constraint) but the problem is if someone knows DROD they suddenly become extremely nitpicky :P
"Ponglike" is a good choice. Only issue is that Pong is muli-player and so even if you have somebody you can playtest it with, you just obliterate your potential audience size. And turning Pong into a single-player game is tricky. Writing a fun AI for it is tough. So what you did is probably the better choice - just freely designing your own additional rules and mechanics on top. But then that can be quite a stumbling block for some. Glad to hear it worked well for you!
@@LazyDevs Arkanoid would be essentially single-player Pong, right?
@@ShadowWolfTJC Kinda but there is one big difference: Akanoid/Breakout has bricks and those can be tricky when it comes to collisions. Despite this, I would still say it is a good choice
Yey it's mah man Krystian who's been to my country the Philippines! ;) I love your channel by the way!
I'm intrigued! Where can I play "WTF Bosh Rush"?
@@LazyDevs I can send you the p8 file if you want. :) I made a video about my design experience here in my Facebook. Starts at 39:18 since in the first half, I talk about the basics of Pico-8: facebook.com/marvin.m.flores.75/videos/10216829315593865
So much good and useful information here! Loved it!
i just realized one my fav games growing up was 2 button and racing, fun run 2!
Like the layout, some good ideas here, thanks.
I made a lot of games with my ZX-Spectrum. Nothing big. A simple thing could be popular for the cousins, neighbours and family. I was mostly in it for making something with the code. A game was just a piece of the confusion or the experiment. I got an education from it. Nothing big either and I chose another profession as there was no "game development" and the alternative was boring... like typing and formatting numbers and lines in a bank. A few things helped me through life any way.
Same here. Just an Atari 130XE instead of the Spectrum.
Saw food, read overCOOKED, was intrigued, watched and was confused but satisfied nonetheless! 😀 Thanks!
Really needed this!! Thank you sm!!!
void stranger is a true innovator in the sokoban genre
There's also the pong like or brick breaker type of game that can be great.
I mean I did a beginner tutorial for breakout. ;)
Pong is really nice because you can whip it up in no time at all. But also, it's really only fun in multi-player. Coding an AI is for them is weird. It's trivial to just make a perfect AI. So you need to make the AI deliberately flawed. And then the game becomes about recognizing and exploiting that flaw and that doesn't feel right either. You need a whole bunch of additional game design to make it a viable single-player game.
Breakout is better but the collision detection with the bricks can be actually quite tricky, as I have discovered. You can get one going easily. But to it can be tough to make it consistent. In the tutorial I had to rewrite the collision like 3 times to cover all the weird glitches that came up. It's a small tech rabbit hole actually.
@@LazyDevs Cool I'll go see your tutorial.
What about simplistic platformer or platformer-adjacent games like not only Donkey Kong 1, 2, and 3, or (NOT Super) Mario Bros., but also Burger Time, Popeye, Pickaxe Pete, Mappy, Bubble Bobble, or Flicky?
Of course, the 1st potential pitfall would have to be collision detection, so that the player character wouldn't be able to pass through floors, walls, or ceilings unless it's supposed to happen (plus maybe enemies, unless they're meant to fly through terrain like ghosts). Many games impose speed limits not only for player movement but also for falling movement, in combination with some fairly thick terrain, to help prevent these kinds of glitches from occurring. (I believe that, in Sonic the Hedgehog's case, its collision detection needed to be more advanced in order to account for Sonic running up and down walls, and even upside-down while passing through those loop-de-loops, and furthermore, the game needed to account for how fast Sonic could move.)
Like with shoot'em ups, platformers would likely have a dedicated fanbase behind them, so trying to make sure that whatever platformer you create would at least be realistic to implement, if not good enough to satisfy those fans of platformers, might be another potential pitfall.
Scope creep would obviously be a potential pitfall, such as trying to recreate Super Mario Bros., Celeste, or Super Meat Boy for example, all of which are pretty long games. Granted, you might be able to rapidly churn out enough terrain to match those games using procedural generation (which I suspect was the case for Super Mario Bros. in order to keep under the 32KB ROM space limit), but you'll need to make sure that the terrain that's generated is playable 1st, functional a close 2nd, and decent-looking a distant 3nd.
Slopes and semi-solid platforms could be 2 more potential pitfalls to have to deal with. Sure, if you can overcome those challenges implementing these features, they could help make your platformer shine. However, other things that help make your platformer more unique from most others could also make your platformer shine, perhaps even more so, even without slopes or semi-solid platforms.
A screen that moves with the player as they travel through levels, such as in Super Mario Bros., could be another potential pitfall. Nearly every early 2D platformer game, prior to Super Mario Bros., along with a few afterwards, didn't even attempt to work with a moving screen. At best, if multiple interconnected screens were required (like in Pitfall or Monty on the Run), then the game would've simply warped the player character to the next screen over, not necessarily even doing screen scrolling like in The Legend of Zelda or Mega Man in many cases. Many platformers that had dynamic horizontal scrolling, like Super Mario Bros., would try to move the camera in front of the player, so that the player could see further to the left or right as they were moving the player character left or right. (One side-scrolling platformer that I'd argue has poor camera movement would be Turrican. Don't program your camera to lazily follow behind the player, thus restricting their view forward, like in Turrican, please!?) Some platformer games with vertical scrolling, like Kid Icarus, would only move the screen upwards if the player landed on solid ground above a certain height, and attempting to scroll down by falling towards the bottom of the screen would only result in instant death, as if the player had fallen into a bottomless pit.
I made a video on what genres I would NOT recommend. Platformers are among them
ruclips.net/video/Hq7IiMPH_DE/видео.html
My first game was made in excel and i made a (very simple) rogue-like game. Then i'm trying to move it to pico8 but i keep learning the lua language and restarting it...
Nice ty!
Quick question: do lode runners count as labyrinth puzzles? Anyways, quite a helpful guide!
I‘d say they are more platformers. But as far as platformers go probably one of the more viable choices since there is no jumping. Enemy pathfinding might get a bit tricky
I think I said this before at some point but ya a smup was a good idea for a game, at least for a game jam when I didn't have much time and I just had to worry about a handful of things like a tiny bit of collision and enemies and there was no map.
Great genera to try out for sure.
Shmups are great! Is your game still playable somewhere?
@@LazyDevs ya it was for the Löve 2021 jam, itch.io/jam/love2d-jam-2021/rate/931493
It has some bugs and issues but I was pretty happy with it, would want to try to make another shmup at some point, like I said trying it took some of the content issues out and made it easier.
edit: also you may have to open it with löve, I didn't port it for each ver and instead just uploaded the .love file.
I have to say your channel offers well prepared and thought-out content, however it is sorry to see that your view count is far lower than other channels that don't offer content of this standard
les goo love these vids
Great!
3rd person Pac-Man with a horror skin on top. Would this be good for a first project?
PacMan sounds good! 3rd person implies 3D and that is something I would generally advise against
I'm not convinced the physics in a racing game even the micro machines one you put there is a good fit for a first game in pico 8. There are a lot of calculations to do. Spriteing is also difficult for the cars unless you use an 8 way controller. So this means knowing how to do rotation. However having said that I do agree that its something that Unity (which is not something I've actually used) should make easier.
When starting pico-8 I made a snakes clone as cell based movement is easier than discrete movement and collision detection is easier. (is there something in that cell).
With regards to your one button game, I think you're confusing something like flappy bird which is yes 1 button with something like temple run which takes 4 inputs as far as I can see. Move left move right jump and duck (which seems to be a pretty standard fair for infinite running games)
My recommendation would be to produce anything thats simple and has limited movement. Such as snakes, falling block games, minesweeper, card games. Even doing a high low game can be instructive. But yeah something that can be finished.
Great Vid. Thanks.
These are fair observations. I do not necessarily disagree.
Rotations can be tricky in Pico-8. But the main issue is really that you can't rotate sprites so you have to do it by rotating the sprite by hand in the sprite sheet. The trigonometry for 360° movement just feels intimidating. It's actually really simple and you'll need it all the time in other genres.
In any case, if that's too much of a hassle you can make an even simpler racing game - basically a shmup without the shooting.
Snakes is not much of a genre, it's just one game.
Snakes is just ok. Snake has an unappealing effort vs results ratio. Keeping track of the body segments and always making the last one disappear as you move is surprisingly tricky. As in - it looks like it would be simple but you have to set up a quite elaborate system. Like, going from TRON Lightbike to Snake is not the simple jump you THINK it would be. You need to set up an array of body segments. Or you store the body segments as tiles in the map and do smart tile tricks to find out where the tail is. And it gets even more convoluted if you want smooth movement animations. And after all that effort what you get is ... just another snake game. Meh.
This is just my practical experience - I've seen students struggle with remaking snake only to be kinda stuck with something that's passable but underwhelming - not being able to turn it into something exciting. It's not a BAD game to start with. But I don't think it's particularly good either.
To me the endless runners evolved from one button games. Canabalt back in the day was huge. There were also successful, cheap follow-ups like The Impossible Game. Mobile was a very good platform for these games to flourish. Over the time the controls just got a tiny bit more elaborate.
"Limited movement" is fair but a bit vague. Your recommendations don't really match. Minesweeper doesn't really have anything that moves. Card games are a bad idea, I think - They end up being a UI/Usability rabbit hole. They can be a good system to experiment with when doing physical board games.
@@LazyDevs Agreed the sprite rotation is the hardest part of it. I feel like 4 way rotation should have been built into pico itself. A standard rotation library would help but that's just not how pico does things.
There have been lots of variations on snakes over the years, since anaconda.
Making the last segment disappear isn't too difficult of a programming challenge. I've seen tutorials that take a different approach but my one is basically keep a list of segments.
What I do feel about snakes is its good as a learning exercise for more arcadey games. Theres one type of data to keep track of the play field but you still need to handle inputs and timings and basic array manipulations. However I do agree the reward is a bit lacking.
Limited movement I mean effectively tile based games, rather than something like a platformer where you have many types of collision to deal with and lots of sub positions.
I think artillery games (worms, scorched earth, gorilla) etc may also be a good programming exercise. But unfortunately these lend themselves to being two player games more.
One last recommended genre is the rhythm game. Simple to code. Is the player pressing the correct button at the correct time. Think guitar hero but without the music being the prompt.
That genre means the game loop can be simple but you can add lots of embellishments.
ᵖˢˢᵗ ᵈᶦˢᶜʳᵉᵗᵉ ᵐᵒᵛᵉᵐᵉⁿᵗ ᶦˢ ᵗʰᵉ ˢᵃᵐᵉ ᵃˢ ᶜᵉˡˡ ᵇᵃˢᵉᵈ ᵐᵒᵛᵉᵐᵉⁿᵗ
ʸᵒᵘ ᵐᵉᵃⁿ ᶜᵒⁿᵗᶦⁿᵘᵒᵘˢ
Did these guy make just one boss
I did not make Just One Boss, you are looking for ruclips.net/channel/UC2Ea8uwt3r2NOttXY8gcOSw
Maybe the genre they pick seem bad because nobody knows to teach them properly on those genres? Or maybe it is a lack of proper genre terminology which is something very common these days as everyone has a say on and about genres but most people fail to understand the term genre as such and so they come up with run of the mill bullshit terms.
1. No. One button games are intuitively boring. Make it at least two buttons. Because then you can create simple platformers more effectively or fun games like Epic Loons.
2. Like that one.Easy to understand mechanics. Most of the time. But how many get as creative as things like Gradius and R-Type?
3. Never as a starting genre. Never. Tetris can be complicated to program properly. That is the reason why so many successful Tetris denominators exist.
4. Labyrinth type games are boring.
5. Cool idea but can also be very complicated. You can range from remote control type racing games like Micro Machines or totally complex like Gran Tourismo.
Making a "boring" game is going to be among the most favorable outcomes starting out with gamedev. If you are intimidated by Tetris then honey you will not make it far in this profession
What if people are only interested in developing 3D games?
It feels like you only talk about 2D games
minecraft was a good publicly developed game
Not quite sure sure in what context you are bringing up Minecraft?
The sad thing about shmups is that the traditional kind has gone all but extinct in favour of bullet hell games, which, while popular for their challenge, are an annoyingly stagnant subgenre in comparison to the often quite experimental nature of e.g. Irem's arcade shooters.
Come on, what are you even talking about? R-Type Final 2 came out just this year, made by ex Irem staff. Last year we had gems like GG Aleste 3, an on-spec Game Gear game in 2020! And if you really want something experimental - indie Shmups like Dezatopia or Project Starship X are coming out all the time. Nothing is "extinct" and somehow blaming Bullet Hell accomplishes nothing but poisoning the discourse. Shmups exist in all shapes and sizes, appeal to different tastes and I have yet to play a title that didn't bring something new to the table. I wished other genres were as diverse and experimental as Shmups.
Nah. Racing games are hard, and 2d racing games are often disappointing. And they're also a content rabbit hole. And the tech rabbit hole is not only in enemy AI, also engine/speed simulation, physics simulation (suspension and friction and collisions), checkpoints/time calculations... only engine sound is a huge topic. People expect some kind of vehicle customization for progression - if it's a commercial game.
If it's a 3d racing game, I expect the driving to feel better than in GTA, and that's a reasonably tall order for an indie title, not to mention creating the world/tracks and assets.
I know, because I've started working on a few, gave up and restarted work several times. It's just hard to limit the scope of a racing game and have it be interesting, you're more likely to make a basic arcade racer with annoying gimmicks.
But I would like to see more of them coming out. Since Codemasters is gone, and the proper NFS developers are scattered into the 4 winds, there's some room for small and medium scale racing games.
My dude. I am talking about hobbyist solo dev beginner projects. You need to think Micro Machines, not GTA
@@LazyDevs So am I.
Nice try, I'm still gonna do mechanically advanced multiplayer RPG as first game
You mean you will ATTEMPT an RPG ;)
41 minutes... no thanks
Those are great advices but I don't understand why bother with trying to make a good playable game, prototypes should be enough, because if you're still traning you should first learn how to take notes and write a good GDD that any team member is able to read.
Solo developers exist but they're often workaholic, have different skills that take a lot of time to learn, and will miss learning from experienced people; i don't think this is a healthy way to start a career.
Oh yeah. This is advice for solo devs because that's how pretty much everybody starts out. Team communication is a whole different can of worms and I might talk about that some other time. Sure, solo devs are in danger of over-scoping and can easily burn out. But so do teams. It's a universal GameDev problem. Protoypes are good and certainly part of the process. But they will only get you so far. You learn how to make games by making games.