System Driven Level Design (My Biggest Mistake)
Вставка
- Опубліковано 1 чер 2023
- ➤ Wishlist My Game Blood And Mead store.steampowered.com/app/10...
➤ Join the community - / discord
➤ Support on Patreon - / lostrelicgames
➤ Buy me a coffee - www.paypal.com/donate/?hosted...
Other videos and devlogs:
My character art sucked, so I fixed it.
➤ • I HAD TO DO IT - Blood...
My Game Lost it's G Rating
➤ • My Game Just Lost it's...
Indie Game Launch FAILS Badly ( My Response / Analysis )
➤ • Indie Game Launch FAIL...
Description: In this video I discuss System Driven Level Design, a valuable concept to help those looking to create games, specifically platformers, dungeon crawlers and level-map-centric games.
Subscribe for more Game Dev videos
bit.ly/2MpZ1ao
#gamedesign #gamedev #indiedev
I hope others in the community can benefit from this video. Likes are appreciated!
In Gameplay Design we differentiate between System and Content Design or as some call it, the skeleton and flesh of a game! So yes, you definitely have to develop the Systems first in order to adapt the Content in a functional and entertaining way! Nintendo always works from System to Story to Content.
However, there is a major difference when it comes to titles that heavily focus on stories! Sometimes a good world and Story can make the systems, so I would add a concept component. So Concept or idea, then the systems that are derived from it and the content to show the systems in a good light!
1. you could start with a premise:
3rd Person Survival Game in a post-apocalyptic society where you play as a homeless person that gets dragged into gang activity and has to work together with the city's robot police to not be executed by the city!
2. Now you think about all the Systems (the smallest parts/games of your game) that can be used in such a Scenario
3. You think about how you use these Systems to create content (Quests, Level Art and Level Design, Narrative Design, etc.) > Now that there is a system for shooting, how do you get your gun, and how do you teach the way to use it and what impact has this element on your plot?
This is why greyboxing is so important. Don’t make a nice looking level right off the bat. Grey box it while you’re still developing the systems, it makes iterating quick, and you can easily test it within the level environment and context, it just lacks the polish.
I'm reminded of an interview with the devs of Mario 64. They said that, before making any levels or really anything else, they nailed down Mario's movement. Because once they got that figured out they could tailor the rest of the game to him. It's a mindset I want to keep in mind when making my games. Get the basic systems made, then worry about the levels.
In particular, they said that they didn't stop working on the move-set until it was fun just running around in that one empty room.
While late for a response, sorry about that, there are a lot of hacky fixes in Mario 64. I saw someone on youtube explaining that, as an example, each coin in the game is being created individually and that tanks the performance. Or how they made mario move against walls when in a corner.
Can't say, at least on the corner movement, that the devs for Mario 64 had it all figured out. Like every dev, there's a lot that won't look pretty in the end.
But in a more "how far will Mario jump" sort of example to the nailing down, then I agree that the devs for Mario 64 mostly seemed to have finished that before release. :P
Systems first, testing using a prototype area. Especially if your game is precision platformer!
Not sure if the pain of game dev is always the good kind!
In my developer life I was always the guy that was given the code no one wanted to attempt. In the various stages I was writing the main code everyone else needed. So I saw very early on what you learned the hard way. So now I am starting my game studio and my first game. First thing I did was open up a journal and begin my game design document. Just the high level stuff at first. Then I wanted to build one island in the ocean but realized I needed the subsystems first. So now I am writing the inventory system that includes a method to determine if an item is in inventory and how much. The framework for the crafting system which used the inventory system method quite a lot. Then I realized the inventory needed to have a variable size since everything in the world had an inventory. Some day I'll build that island, but I need the backend code no one wants to write ready for use!
Always try to make a MVP - Minimal Valuable Product - asap to test all the systems and iterate over it (more) peacefully.
The timing of this video is perfect. 😊 I'm about to make my levels. 😅
My level design always ties to my game Lore. It will be easier to make them when you have set of rules made by your lore. Same goes with my characters.
A few years ago, I learned about the concept of a "vertical slice" - a small version of your game that you create with very little, very focused, content. All the systems, mechanics, core loops, and interfaces are polished to near completion, tested with one another with only a minimal set of content. Only when your vertical slice "feels good", do you move on with building out further content. It serves a couple purposes: it gives you a polished product to show off and discuss, it allows you to test the core functionality of your game to make sure it's enjoyable, and it forces you to focus on what really matters in the game - how the combination of systems and loops makes the player feel. It's very similar to your approach, and for me as a solo hobbyist, it forces me to stay focused and productive. It was a game changer... pun intended! :D
Love it, thanks for making a series about this. Too often I find that there is very little content about ACTUAL game development, especially for 2D side-scroller types. I am currently designing an action platformer and these types of discussions are exactly what is needed to get into the nitty gritty. I joined the Discord, hopefully Ill get to chat with you about some theories and ideas. Great work keep it up!
So relatable. I love the way you described how you had been thinking about making the level, and then sprinkling in the mechanics. I was thinking the same thing at first. Fortunately my workflow is much better now 😅, but this video is reassuring. Thanks.
One example is setting up a level with platforms to jump to, later you decide you want to change the player speed for one reason or another. Now the level needs re-work. Just do the content building last, as hard as it is resist it will always save massive amounts of time.
Thanks for the share. Glad to hear you found the light! Heh.. there is a GDC talk I recommend to my non game design friends about overcoming cursed game design elements. But you found your own way of dealing with some of it. Similarly I am focusing on the gameplay mechanics & building out from there, mostly. You already experienced with map making (same here) so you can better design maps that highlight the befits for players to choose the shortcuts you give them. Really the part where you mentioned enemies & spacing, players perception of fairness, & using stand-in minimalist enemies to see how they fit they map & player mechanics - prior to fleshing out the enemies animations & mechanics. These are tips I don't see very often but to me they work well for prototyping player & enemy interactions (mostly) first & then afterwards making a stronger version of the map I already had in mind. Except when I do it this way, I'm thinking about how the map art, items, & enemy placements (+ bonuses) can compliment one or more optional styles for the player to choose to play. But as you said, it's not entirely linear, I also will think of possible map designs & what type of enemies would be fun for "those types of levels". I think it's good to think of game design from as many angles as is constructive. My project is slow tho, as a forewarning, albeit I'd blame it more on my terrible luck with PCs dying (also inherited an intermittent long term memory issue) & shoestring budget haha.. but new one in the mail & I'm determined to see it release if it's in my power to continue. Thanks again! Take care~
Thank you, John, for that is a greatly important topic that you've brought up. When I started to my make my own game, the very first thing that I did was a document describing all of the important game mechanics, so that later on I could easily block out a map based upon those said mechanics. And it did help tremendously! I also liked your phrase: "...level is a vehicle to carry the player from one system to the next.", never thought of that, smart!
Additionally, I would like to thank you for... introducing? me to the "No Zero Days" strategy. Ever since that video, I've implemented this tactic in my life flow and it did absolute wonders! Step-by-step, my dream is coming true and I finally feel like I am doing something right in my life.
As a final note, John, I wish you well with your creative endeavors and I am excited to see and play your game (which is, of course, wishlisted!)
This goes along well with something I heard one of the designers of Super Meat Boy say, and it's so true. They basically said it's important to have a goal first, like "what am I trying to teach the player here?". From there designing around that goal. The example they gave was introducing a new mechanic the player can do (eg. running, and by extension jumping further). You might start simple and have a large gap to jump, but later you mix it with other enemies. The key being the mechanics are coming first and the level shape and design accommodates the use of those mechanics. Excellent advice
Great advice! Seems my initial thinking was good since I was going for systems and scripting before overall design.. but dont forget, like Johns says, level design and design in general is fun and its probably important to get some graphics and design in early as it will increase the "fun" of it all :)
Happy grinding y´all!!
This video was insightful. I still got a while to go before I make some levels for my game, but thinking about and designing the systems first makes sense. Your videos have helped me a lot. Thanks for the great content.
Hey I'm really glad to hear you found it useful. All the best out there
Very insightful video John, thanks. I experienced this myself in early development where I had a level with a jumping puzzle that required precise movements from the player. The distance between platforms was carefully measured to make sure the player could not cheese it. But then some time later I discovered a bug in the player's movement code that was so fun that I converted it into a feature I call "gravity jumping", which basically allows the player jump massive distances that now completely trivialized those previous jumping puzzles. Thankfully I had only created that one level at the time, so I didn't have to redesign much.
Nice video! This definitely seems to be an issue loads of game devs come across, including myself last global game jam.
I suspect it comes from the fact we like to see results, especially when we have to show off on social media, and a level is much more compelling than a finely tuned jump. It reminds me that often in software development people don't like writing tests first because it's 'not the actual code' but it helps establish the design and confirms the behaviour works. All crucial foundations for anything you make.
I remember seeing this level design trick on a video some while ago, and since then I've been developing my levels just like this. It makes level design so much easier
Hey there and thanks for telling us about this. A friend of mine from streaming brought this video to my attention and I just watched. I kinda think I am doing what you are saying as I am at the moment working on my initial level for players to learn the basic mechanics, and I've not designed my level yet. Instead I am using the double drawbridge that is the place where the player will learn to use jumping, as a central mechanic. That has to be perfect before I move on with any level design. Yes, I have made some assets, but nothing really final so far, just to have something to look at while I stream my progress. You mention that level design is fun, I am hoping I am going to be able to do it right..
Absolutely true. I was messing up with level design and setted up a test stage to just see how it will look and also test a player movement. It actually came up to my mind what if player have double jump or some other movement ability. You need to adjust level for it to be actually useful but also keep it in mind so the player wont get out of intented area. In linear game where player gets his abilities in given time its a bit easier but if you intend to be kind of open and player being able to return to previous area then you must take into account both scenarios - players with and without the abilities.
3:99 its pure pain 😂i share your opinion about that. On one of my game where i still work on i changed behaviors or add new stuff and you need then often adjust the already done levels for example. So mostly you need to make the system first but in praxis you will never do this really as you might think sometimes "oh this might be a cool idea for this game too" and add and checkout if this is a cool new system and if it is - you might want to have it in your game.
Great advice! Reminded me of the Tiny Town example used by Google for Maps. Create a (small) place with the purpose to test how all of the systems interact together, so that both iteration and regression testing time can be reduced.
I notice this common problem in map making for minecraft as well. Too often the terrain is made first before thinking about the gameplay it would have.
That made me even coin a term for it, the entropy syndrome; when something was made for asthetics first then gameplay was added to fill it. It's always very noticeable that the layout wasn't build with a purpose in mind because the gameplay suffers from it.
That's why, when I start making a map, I first get an idea of the theme of what I want, then I make the enemies/hazards, then when I have my toolbox ready, I can create the placeholder layout with gameplay in mind from the start. So instead of adding rooms and paths randomly hoping it works out, I can instead create new spots as I need for the gameplay experience I want to happen.
And yeah, your final words are very right, it's a hard task.
I shudder to think how difficult Elden Ring must've been to make, in terms of level vs system design, really educational video, thanks.
This makes SO MUCH sense!! And answers some questions I didn't realize I had! Thanks for this insight!
"game development is pure pain" man, you are really selling this :P
Golden Rule: build games for systems, not systems for games.
Start with a toy, something that is just fun to do and interact with. Then expand upon that toy. Don't even have a genre or game aesthetic in mind. Then build everything you can to give that toy context and meaning. Make it a means to an end. Choose an aesthetic to enhance the feelings the toy illicits. Story, levels, art, audio and genre are all the icing and decoration for the cake and should never be the cake itself.
Totally agree. (And I offer this in the most helpful spirit possible : the word you want is "elicits". "Illicit" means something rather different.)
@@landru27 Depends what the system is doing to your mind and how lol
@@KryyssTV 🤣
Video pop while I'm creating some levels hahaha. I've been trying to take more of an experience approach on levels, which is kind of what you presented. Thinking "how I want to challenge player next?". This requires me to have the systems ready to drop in. I like creating the core systems easy to extend and link together.
Thanks! That was greatly insightful and a very logical approach. I will surely try it out.
MAN! That’s exactly the problem I’m having with my game. I don’t know how to make the levels. Thanks for the video. It definitely gave me an important insight.
A major part of the reason why gamedev takes for ever is because of not really knowing what we want up front and change the system multiple time. One change in the system is never has so much consequence on level design, side effect, making another system irrelevant ...
Yeah learned this lesson not only doing programming, but also playing games like Minecraft and ARK. It's fun to make a concept of this wonderful looking base, right up until you can't fit the stuff you need inside of it. Then you're left with a very pretty, but non-functional base.
Pro-tip for designing anything, build inside out. Start in the middle (in this case the underlying game systems) and then work out from there.
Man... I"ve definitely learned (and continue to re-learn) this the hard way, can't tell you how many times I've remade the same areas to facilitate new mechanics or tweaks. Its tough though, i still dont always know for sure which should come first
Completely agree 👍 im working on systems and how they work while casually making my own pixel art sprites in spare time. I believe the foundational systems that we implement and learn also help to potentially shape how our game will be in the end long before any environmental development. Do the hard yards of learning systems THEN make it pretty 😅
Most Important lesson indeed. Personnally when I tackled projects and I wanted to avoid these type of sinkhole is to make a huge round of Vertical Slice. My vertical slice in games are always almost longer than the production cycle. The longer you keep it and iterate on the system while having only one instance of everygamplay ingredient is time saved seing all the potential ramification and tools needed to speed up processes during the production. It's the perfect time for estabilishing scope, constraint, let the game grow organically while keeping a clear vision holding, all that creative part that we love, but figuring out and nailing all the aspect needed so that the production cycle will be purely in a sort of "auto-pilot" mode. Take time to distill everything to it's simplest methodologies, but most importantly a unified methodology.
The part where you mention about doing the systems first and then level is really good advice. It is something I have come to learn as well. I would eagerly build some cool looking level with a nice layout, but then after working on a game for a few weeks, I think of a cool feature to add to the game, but implementing it into an already existing level doesn't always work, so I would either have to force it into the level somehow, which ruins the level experience, or I would build a new level from scratch, just to test out the idea, which is also bad because everything is still subject to change.
Make sure you think really hard about what you want to add into your game first, and when making levels, just keep them stupid simple and experimental. Don't set anything in stone and it will save you time and energy. Burnout from having to rework a whole level can be really demotivating!
Chat gpt generated comment to audience of similar channels. You can tell.
@@paulsaulpaul ?
Incredible video! Thank you so much for the advice and wisdom
Really good tip! Thanks a lot.
I'm using a placeholder level (very simple and small) and I'm building my systems in it first. I know that level is like a testing ground.
I did a tutorial and it was player movement, enemy spawning, collision detection. As the tutor went he tended to clean up and refactor, then he moved on to global variables and singletons. He created a ton of functions and eventually a lot of reuseable constants, he developed code like player death that actually was reused for enemy death in terms of destroying the game object instanced in the tree etc. Some animations and scripts became reuseable. I began to wonder just how much can be figured out before starting - in terms of how much repetition can be reduced and how similar players are to enemies, similar animations, detections, particle fx, mirroring. There were tons of timers in the end. If i foresaw that before beginning it might give me ideas like using a timer to trigger another timer or something?
A valid point indeed. After two years from beginning of prototyping I only recently started modelling levels in blender. Having everything tested in terms of performance and mixing different systems is tricky enough. Levels and detailed modelling should always come after paper prototyping the level design.
Iteration is super important in gamedev. You seem to imply that you failed and should've been able to do your level design only once or maybe I'm putting words in your mouth.
Finding the fun is important, failing and starting over is important, you learn something about your game on what is fun and not in your game.
I feel the real personal growth is finding a good way to fail at low cost, having test levels to try out mechanics, having one single level you remake again and again, before you go for the full content of the game and make all the levels. I don't pretend to know the answer, but failures help to find that sweet spot.
They way we approach this here , all the system (enemy /trap/block etc...) are seen as lego block we need to create the block before building level with them, and new block should be added along the way for later level. so you don't need all you block at the beginning of the process but you still need a lot of them. To test at the beginning we just do a fake level(like your wireframe level)to put each system in.
“The first draft of anything is sh*t.” - Hemingway
I agree with this approach and I had this in mind while developing my game, but I still had to scrap my level. After I had a vertical slice of my game completed, I submit it to publishers and I got feedback that the core mechanics wasn't deep enough. So I had to rework the mechanics, and now the levels have to be scrapped due to the change in how the player handles.
Thanks I needed this - Extremly Helpful✨
🤔 this gives me a lot to think about... I just started remaking my game after I abandoned it for months, with a whole new gameplay and completely different systems. I was planning on designing my levels very soon. Thank you for the video 🙏
Strip it down to the systems and shelve all ideas of what kind of game it is. Play with the systems isolated from the bells and whistles to see if they are fun within themselves. If not then keep tweaking the systems until they're fun despite being nothing more but ugly placeholder assets.
Thanks for sharing this, it will probably save me a good chunk of time to follow your advice! I’m curious about what kind of balance you’d like to see with tweaking the mechanics based on existing levels, it seems like you could go that way as well. Or do you keep a set of prototype levels?
Great!! Thanks for letting us know about that common error!! This will help new developers to save a lot of hours
Well, I make 3D projects but what I usually do before getting into the modelling work for the levels or world is I create a simple prototyping space to test out different mechanics and behaviours. For me, I make a hallway with rooms, each room to represent the different areas that will eventually be implemented down the line in the game world such as boss rooms or environments that use different mechanics or specific encounters. Then I can nail down all the dimensions I will need to remember and write them down in a notepad that considerably reduces how many iterations I need to make to environments to make them flow properly.
I love the "building a house" analogy. I'd like to expound on that analogy by saying that one could ask themselves, "Is my game/level/environment accessible to my player character? to my NPCs?"
I've tried to soak up as much knowledge about accessibility as it pertains to gamedev, but it's naturally always in terms of accessibility for the player. Your analogy looks at accessibility from a whole different perspective - that of the digital characters. It's very common for game devs to build a sandbox/holodeck level for working out the metrics of the player character - how tall of a ledge is accessible with a single-jump? How tall of a ledge is accessible with a double-jump? How far of a gap is accessible with a dash? How big should a door-way/entry-way be to allow for the camera?
It's a very interesting thought exercise, and development practice to ask those questions in terms of the systems: how big of a turning radius does an NPC need to correctly navigate a hallway? Is the cost of an item accessible given the amount of currency within a level? Is the HP of an enemy within an accesible damage range for the player character at this point in the game?
Thanks for the insight!
What most game designers do is make the middle section of your game (levels, puzzles, mechanics and artwork) then as you gain experience you make your beginning and end levels. The reason you do it in this order is because when you start making your middle portion of your game, you will gain experience and new level building skills that will be far more advanced than how you started. The beginning and end of the game should always be the most polished.
It’s a reason why some demos only let you play a beginning portion of the game.
Well, this is exactly what I needed. Thank you for sharing!!
I think I would have made the opposite mistake.
I'm a programmer and think primarily in systems so that is what I would start with. I'd just create an empty space with a block on one side, an enemy on another side and just add one (or more) of each type of object I want to interact with. I think level design is probably one of the last things I would do. But then I wouldn't have the experience in creating the levels. Then when creating them I would likely go back and change the systems or replace them altogether.
Like you said they are intricately connected. I guess the ideal solution would be to find the perfect balance between the two and work on both of them so they can influence each other.
If someone knows how to find this perfect balance, please enlighten me 😄
It seems that you would benefit from a map builder. I understand that it's more work to build the map builder but if it can place all those tiles and prefabs for you and even procedurally add parts it would make things a lot more fun and speed up iteration. It also opens up the possibility of a frontend for players to create and their own maps in a sandbox mode. There are a few 2D Level Designers on the asset store, one called "Olive" which looks fit for your approach.
Just found your channel, and I'm loving the videos a lot!
(Imma repost this comment because I'm an attention hungry bastard... But I think this also might be helpful, hopefully?)
I just watched your last character redesign, and though it feels like a huge improvement, something bothered me about the design, though I couldn't put my finger on what exactly...
But I think I've figured it out: It's the direction the eyes are looking.
The previous design had the helmet almost completely blocking the eyes, but since in this one they're so prominent, it seems strange that they're not really looking ahead at the enemies, but kind of diagonally towards the player. In fact, the old design (from how little you could see of his eyes) was looking rather ahead, and it looked more natural (though it's just that, the gaze).
The foreground eye (since it's not really a left-right issue) seems fine, but if you could point the other one, (the farthest one? The one away from the player), a little more "forwards", towards where the guy's walking, so that he's actually looking at the dudes he's chopping up, I think it might help him not feel like he's looking into nowhere, which makes the whole character feel kinda weird (surprisingly, given how small of a detail it is).
Maybe even giving him pure white, berserker eyes could be cool, lol. Might be too big of a departure from your concept though.
Anyways, might be just me, though I'm an artist more than a game dev or a programmer, so this is the one thing that I'm confident in, lol. If you read this, I hope it helps!
Hey! The eyes have since been adjusted ;)
I have to admit, there is a huge advantage to doing things by yourself in that you can create things in the order you need... so build systems and test enemy types, then design levels with placeholder graphics, then when all the levels are done you can start doing the art so none of that time is wasted. Quality artwork and animation especially can't really be rushed; you can get more efficient with the software you use, but the amount of content that needs to be created is insane and there aren't usually satisfactory ways to cut that time down. I mean... you can repeat the same objects/enemies over and over, but then your game is boring. It's a sad day when you realize you can't use artwork/animation that you spent so much time on!
I also really like the extra time you get to stew on what the characters and levels will look like, and the best case scenario is when the systems make sense depending on the environment. So maybe if you have jump pads you imagine them as mushrooms so now you're in a forest, or there is a strong wind effect so now you think about it as being on the top of a snowy mountain, etc. It also informs what your enemies will be and look like, and if they seem like they "belong" to the environment that can be a way to deliver story without using text.
Yeah.. this is probably why we need to make the full gameplay/controls first and then make the environment around it. Thank you for the interesting personal wisdom
Story first because it can influence gameplay and system design. Easy examples. Any super hero you know of or fantasy story you've read. You don't have to write a novel but having a good understanding is important. Then system design, then level design. This is what makes the most sense to me. Elden Ring too this approach as well. Although you can start at system design and attach story to it as you go as well. It will take more fixing though I'd imagine
Thank you for the advice Josh :)
What I am doing so far successfully is defining a level design system with rules and metrics. For example defining standard sizes for small or large areas / spaces. Putting all of that in a procedurally generated system that does the basic placement for me. As I progress I update those rules conceptually and in the system which reduces the time I spend readjusting things
This is a good idea, but those exactly spaced jumps or whatever shouldn't look that formulaic to the player or it'll be boring.
Making a "spike," or "vertical slice" can be very beneficial. The idea is that you're *not* going to keep any of that code, write it quickly without any attempt at making the code efficient or easy to work with. Just throw the basic systems together along with a simple map. Don't bother with great graphics, just gray box the level and use geometric shapes for the player/enemies/etc. Then play it, see if it's as fun as you thought it would be, what's good what's bad.
It shouldn't use flexible layouts for different size monitors, it shouldn't save the game, no menu, no rebinding. Just *game idea* and nothing else.
Then chuck that nonsense out, do *not* try to refactor it into good code. Its only purpose is to showcase the idea in a playable format. Or to be more precise, start a new project in your game engine and leave the test alone, just keep it for reference. And now you build the game, but focus on maintainability and tweaking all the systems so they are the most fun.
The "spike" name comes from agile programming, or test driven design. The "vertical slice" is more from making a demo in the game design space. They are mostly the same thing, just a slightly different focus on who the executable is meant to be played by. But the amount of time you can save by just "throwing it at the wall and seeing what sticks" will save you so much time in the long run that the time spent making "throw away" products is saved many times over.
Just don't fall for the siren song of "just keep working with this version, it'll be easy" since the idea is to not make it bug free and robust which the final game should be. Just using the lessons you learned and starting over will be faster and safer than trying to fix the mess you've made.
Prototyping, making test-levels, developing systems/NPCs/Interactables, plan the visual styles, plan the pacing and learning curve of the game, then leveldesign and beautify.
DUDE COME ON.. I am trying to edit my video and you release one... now I have to stop and watch this.
😂😂😂
Yeah, he's always like that😢
It's amazing how much jump Heights and movement speed have on levels
Good ideas and glad you shared thise
absolutely, one slight run speed increase can decimate maps, especially so for precision-platformers.
I have found this out...again and again...
Giovanni from Haruneko Entertainment here. My strategy as a solo dev is: write down inside a game design document (gdd) ALL the systems and ALL the enemies. Treat it as a bible. Implement everything except the bosses, and while doing so try everything in a test level - at first, a super-ugly one, then asap move to another one that has a "game ready look". Treat the test level are pure garbage, it won't be in the final product. After all the systems and enemies are finalized, start doing the level design. And stick to this rule: change something inside the systems or enemies ONLY if it doesn't contradict what you already have in place OR if it fixes a game-breaking problem. Otherwise keep the brillant idea for a sequel: write it down, and forget about it now. Adapt the levels to the systems/enemies you have, not the other way around: unless you were designing overcomplicated "one-trick-pony" systems/enemies (NEVER do that), you should have enough freedom to create interesting levels.
Awesome advice, cheers!
The level design of the game looks very good and high quality. I wonder what program did you use? did you use adobe illustrator.Did you do it yourself or someone else? Basically The idea you shouldn't put the hole level in scene. You have to slice it right?
I think maybe a situation to learn to questioning yourself.
Maybe self reference the linguistic of "Jump! How high"
"this is a jumping puzzle, jump."
"how high?"
This role of "questioning your own instruction" or "goal" puts the players potential situation into account.
You need to make the jumping puzzle work with the jumping mechanics and height.
Another example is:
"Get to the exit."
"Which way?"
clear directional instruction is key to map building.
Thank you for the wisdom! You rock!
I would say there isn't really an option in which creating the levels before stablishing the mechanics would work.
Even if you could somehow make a functional level, if you were to introduce a major mechanic then you'd likely have a lot of rework to do. And rework means time lost, and time lost means your project costs more to make.
Knowing what the characters can do before you build a level is not only easier, but will likely allow you to build levels that make better use of your mechanics.
Great video!
Great advice. Thanks.
Thank you for this video
Great video as always, secret sage!
It's great to see John wick doing game development.
Best advice I got for level design is the same advice given to architects, form follows function
I like to focus on problem solving potential issues before they appear, creating a robust proof of concept, it seems difficult but gets more effective over time
I thought this was common considering prototype phases are focused on establishing the core systems.
More so referring to the level-specific systems that emerge as development progresses beyond prototype/vertical slice phase.
@@LostRelicGames - Oh okay I see.
I'm watching this video as I'm designing level map ideas. I use the old fashioned pen and Math paper before moving on to computer stuff.
ah yes, the classic "we can always change it later" and then later becomes the present, well this is too much work, this needs to be reworked, we don't have time, and game turns out shit,
very well done video m8
I never get the chance to design a level in the layout or area editor of whatever environment I am using because Scope ambition sneaks up on me and makes everything procedurally generated. lol
In my case since I work on a classic active turn based battle system (Chrono Trigger style). I've mostly worked on that system for now to a point I could put it in a scene.
Player progression that is the keyfactor from where you start designing.
I completely agree that you shouldn't build your levels first. But you also really need to be aware that building systems first can leave you feeling like you aren't making progress sometimes. There are a lot of times that you will finish a large, complex system that has very little visual feedback to see. And even though you know you made a lot of progress, it can feel bad because there isn't anything rewarding to see. Just be aware of it so it doesn't demotivate you.
Great tip!
ON TIME, THANKS!
I discovered this making a van conversion as a short arse, but I never really connected it to programming... 😅
Thanks for sharing. I'm kind of on the opposite end of endlessly building systems and avoiding making actual levels. All things in moderation eh 😅
A good tip for sure. I seem to jump back and forth between the 2
Lol I do exactly this and I agree it's inefficient.. BUT. For me, in my mind, I cant separate the systems from the levels. I need to see everything together as I put it together so can get a sense if whatever I'm adding fits the overall vision I intended. Also want to see it in the context of the player moving from one thing to the next. I suppose this can do in prototype levels but my brain is like 'its not the real game' and not only that its BORING haha. I think you can work like this but just scale it back as much as you can (like first sequence of levels or key levels).
“Pure pain...” - the game dev’s tshirt
This makes a lot of sense, I think it's part of having a good instinct for design overall
I learned this a very long time ago without even realizing. I spent a lot of time in game editors, in those the mechanics are already set, the only job is to create a new layout with those mechanics in mind to create the sort of experience you want to.
More than having a basic layout, I suggest having a theme, it can be anything, like fire, water, bread, action, super challenging, jump, literally anything, but that gives you a very specific path to follow which helps you create something relevant. Also, please do not confuse game with level design, the two are very different jobs and that's why I see a lot of indie devs suffering so much, Game Design is the base of any game, once you have that in place, the path becomes really easy to follow because the mechanics pretty much create themselves, once they are designed you can create a bunch of game moments with them, that's level design, then tied them all together and there you have it, your game is ready... almost, you have to season it with some art and sound that fits your game.
I also highly suggest studying Rayman Legends level design, you can see how they implement the same mechanic in very different ways just by changing the layout of the level. In other words, imagine enemies and systems as toys, play with them as much as you can, you'll be amazed by how a simple spinning wheel can create so many different challenges.
How much of the work of turning an idea into a level can you automate or at least make repeatable by the right code? Seems like the higher that % is, the less painful reworking a level would be.
As the old saying goes, “No pain, no game.”
I like to rush in with no ideas, start randomly developing systems, hate everything after a couple days, and then move on to the next project.
while(true) {process.Repeat();}
While watching your next video I was thinking how much metroid has affected this game... and in this video I just notices after few mins the picture on the door :D best platformer ever
Hehe, Yeah man, I grew up on playing the NES all day long. Metroid is close to my heart for sure! Still love the original the most
You should start with the motive/story. The mechanics should revolve around the vibe/story. The player wants to know why they should invest time in your game. I think.
Yup, pain is what mostly we get when making games. Hopefully in the end it will be worth it!