Truly, I owe this community more than I could ever possibly repay.
I've spent years searching for game ideas and building things I wasn't satisfied with. This is the first time I'm making something that really excites me, the sort of game I could see myself spending the next five years making.
Anyway, enjoy the video. Leave your thoughts and impressions. I appreciate it
I've spent years searching for game ideas and building things I wasn't satisfied with. This is the first time I'm making something that really excites me, the sort of game I could see myself spending the next five years making.
Anyway, enjoy the video. Leave your thoughts and impressions. I appreciate it
Edited by Ted Bendixson
on
Reason: Initial post
The game idea looks interesting.
There are a few things that seems weird. I know it's not a finished game, just letting you know my feeling based on the video.
- In the first level, when the right character moves outside the blue zone, the left character "disappears" behind the wall. In later levels it seems that the character is blocked by walls which allows you to "offset" the character in the zone. So I guess I don't understand which character has collision. Is it based on which character the camera is focusing on ?
- In the level, where there is an unnecessary couple of blue zones (the level you need to fix) you seem to indicates that you want people to think they need the blue zones where they don't actually need them. I don't thing that ever happens in Stephen's Sausage Roll. I mean there aren't levels where there's something you absolutely don't need. You might misunderstand what you need to do in the level, or have a first assumption that you need to solve the puzzle in a certain way, but I'm pretty sure they pay careful attention to not add any red herrings.
- In the same level and in the last level there is a problem with visual information (in my opinion). The "pipes" looks like they are solid geometry that you can't go through. While polished graphics are no necessary at that point in the development, graphics still need to properly convey information.
- In the second level, after falling in the pit, when you come back you "walk on the hole" (well after watching it again it seems it's just the collision of the character that are bigger than expected).
- The camera seems to move a lot sometimes if you do small left/right movements.
There are a few things that seems weird. I know it's not a finished game, just letting you know my feeling based on the video.
- In the first level, when the right character moves outside the blue zone, the left character "disappears" behind the wall. In later levels it seems that the character is blocked by walls which allows you to "offset" the character in the zone. So I guess I don't understand which character has collision. Is it based on which character the camera is focusing on ?
- In the level, where there is an unnecessary couple of blue zones (the level you need to fix) you seem to indicates that you want people to think they need the blue zones where they don't actually need them. I don't thing that ever happens in Stephen's Sausage Roll. I mean there aren't levels where there's something you absolutely don't need. You might misunderstand what you need to do in the level, or have a first assumption that you need to solve the puzzle in a certain way, but I'm pretty sure they pay careful attention to not add any red herrings.
- In the same level and in the last level there is a problem with visual information (in my opinion). The "pipes" looks like they are solid geometry that you can't go through. While polished graphics are no necessary at that point in the development, graphics still need to properly convey information.
- In the second level, after falling in the pit, when you come back you "walk on the hole" (well after watching it again it seems it's just the collision of the character that are bigger than expected).
- The camera seems to move a lot sometimes if you do small left/right movements.
Wow thanks so much for your thoughts
And I totally agree, not having many art assets this early on is definitely creating confusion. I'll do another pass on the graphics to make sure they are more clear
And I totally agree, not having many art assets this early on is definitely creating confusion. I'll do another pass on the graphics to make sure they are more clear
The game idea looks nice, it seems like you've hit on a universal truth about games. That is the best ones have a super minimal gameplay loop that can be expressed with very little in terms of mechanics and assets. Once you have that loop, you can stretch it, build other loops over it, dress it up with an interesting aesthetic, but whether or not the game is fun will ultimately depend on having a nice, tight loop.
I enjoyed your discussion of handmade philosophy. As someone who has been building games mostly by scratch on and off for a couple decades, the handmade thing just "makes sense" to me, to the point where it can be difficult to describe why to someone coming at it from the other angle. I've tried really hard to empathize and understand not only where they are coming from, but also all the history and cultural context behind it.
I think there's a couple interesting tidbits. A lot of the common opinion, even among hobbyists and indies seems to be shipped out of big AAA shops. It can be very perilous to do your own engine at that scale, the tradeoff is a more unique expression of your game idea, at the cost of developing an incredibly complex system from the ground up. Any "greenfield" project like this has its risks. You bring up a really good point, that if you aren't trying to build a general-purpose engine, it's not as complex of a task, but to create a game of sufficient complexity as to compete with the other AAA offerings, you're going to have to pull off a lot of the same bits.
Scaling down to indie developers, it's a question of where to spend extremely limited resources (time, energy, money). I've seen some really inspiring indie games that used unity, and by freeing themselves from writing game code, were thus able to spend a lot of time writing and refining their narrative structure. The gameplay itself might not have felt as novel, but they exchanged that for a really neat story. Assuming they even had the skills to write gamecode, the only way they could have done the same game handmade would've been to significantly increase dev time.
The last thing I think about, is that there are two very different personas who masquerade under the same guise: tinkerers and makers. The former, the tinkerer, might be perfectly content messing around with engine ideas or code structures and never actually shipping anything. This kind of person might give the impression that by doing things by scratch, you are stuck in a purgatory of incomplete projects. It's not true, they just have a different goal than the maker. A maker has an end goal in mind (a shipped game) and is using the handmade "engine" as means to that end. There's nothing wrong with either persona or objective, but someone could easily look at the graveyard of incomplete engines as damning evidence that handmade = never finished.
All those words to say, there isn't a one-size fits all solution. The objective of a handmade community isn't to convert every single person possible over to the "better way" (for some projects, unreal or unity might be the better way), rather it should be about legitimizing it as an option (which I think your video did a fantastic job of outlining), and then for those who choose that option, the community should be there to help enable, encourage, and support their journey.
-
One last addendum, when you talk about a tool that is only for one person or a small group, I generally point to a jig. A woodworker might have the same general purpose tablesaw as everyone else, but it's also almost always a guarantee they've got a bunch of jigs spread across their workshop to tackle the specific challenges of their projects.
I enjoyed your discussion of handmade philosophy. As someone who has been building games mostly by scratch on and off for a couple decades, the handmade thing just "makes sense" to me, to the point where it can be difficult to describe why to someone coming at it from the other angle. I've tried really hard to empathize and understand not only where they are coming from, but also all the history and cultural context behind it.
I think there's a couple interesting tidbits. A lot of the common opinion, even among hobbyists and indies seems to be shipped out of big AAA shops. It can be very perilous to do your own engine at that scale, the tradeoff is a more unique expression of your game idea, at the cost of developing an incredibly complex system from the ground up. Any "greenfield" project like this has its risks. You bring up a really good point, that if you aren't trying to build a general-purpose engine, it's not as complex of a task, but to create a game of sufficient complexity as to compete with the other AAA offerings, you're going to have to pull off a lot of the same bits.
Scaling down to indie developers, it's a question of where to spend extremely limited resources (time, energy, money). I've seen some really inspiring indie games that used unity, and by freeing themselves from writing game code, were thus able to spend a lot of time writing and refining their narrative structure. The gameplay itself might not have felt as novel, but they exchanged that for a really neat story. Assuming they even had the skills to write gamecode, the only way they could have done the same game handmade would've been to significantly increase dev time.
The last thing I think about, is that there are two very different personas who masquerade under the same guise: tinkerers and makers. The former, the tinkerer, might be perfectly content messing around with engine ideas or code structures and never actually shipping anything. This kind of person might give the impression that by doing things by scratch, you are stuck in a purgatory of incomplete projects. It's not true, they just have a different goal than the maker. A maker has an end goal in mind (a shipped game) and is using the handmade "engine" as means to that end. There's nothing wrong with either persona or objective, but someone could easily look at the graveyard of incomplete engines as damning evidence that handmade = never finished.
All those words to say, there isn't a one-size fits all solution. The objective of a handmade community isn't to convert every single person possible over to the "better way" (for some projects, unreal or unity might be the better way), rather it should be about legitimizing it as an option (which I think your video did a fantastic job of outlining), and then for those who choose that option, the community should be there to help enable, encourage, and support their journey.
-
One last addendum, when you talk about a tool that is only for one person or a small group, I generally point to a jig. A woodworker might have the same general purpose tablesaw as everyone else, but it's also almost always a guarantee they've got a bunch of jigs spread across their workshop to tackle the specific challenges of their projects.
I disagree that your idea of building around a single tight core gameplay loop is a universal truth about games. It's certainly a common and useful method for making games, but it's only that - a way to make games. There are other ways, and plenty of games that are great despite not being structured in the way you describe.
Some such games just take a more gestalt approach to their core mechanics. The quintessential example of this to me is always Roller Coaster Tycoon. It's obviously a fantastic game, but there are really no tight loops that are engaging on their own. The interesting things that happen are all relatively long-term, playing out over the course of several minutes or hours. The game's rules and systems are complicated, highly interconnected, and kind of inscrutable, and if you took out any one major piece, the rest of the design would pretty much fall apart, because no single piece stands on its own. They only make sense once they're all put together.
Other times, a game is simply about something that doesn't lend itself to a tight gameplay loop. For example, games about exploration can't really nail down the core gameplay with little in the way assets, because the fleshed-out game world is the gameplay. If you don't have a world worth exploring, you can't make exploration fun. Exploratory gameplay is just not something you can engineer in a vacuum.
Other than that, I pretty much agree with the rest of your post. Your analysis and explanations are spot-on. The tinkerer vs. maker distinction in particular is similar to something I've been trying to communicate to people for a while. The way I usually approach it is to draw a distinction between "making a custom engine for your game", vs. "making a custom game with no engine". The former makes sense if your end goal is a game engine, whereas the latter makes sense if your end goal is a finished game. This draws the line in a slightly different place than tinkerer vs. maker, since the "custom engine" category includes a lot of people that may be dissatisfied with off-the-shelf game engines and want to make their own tech, but have been misguided to think that creating a custom engine upfront, which they plan to then make their game in, is the only alternative, because for whatever reason they either haven't considered the possibility of not using a game engine at all, or assumed it wouldn't be viable.
I don't know this for sure, but I suspect that if we make the "custom engine" vs "no engine" distinction more clear, it may clear up a lot of the FUD that has built up about making games the handmade way.
Some such games just take a more gestalt approach to their core mechanics. The quintessential example of this to me is always Roller Coaster Tycoon. It's obviously a fantastic game, but there are really no tight loops that are engaging on their own. The interesting things that happen are all relatively long-term, playing out over the course of several minutes or hours. The game's rules and systems are complicated, highly interconnected, and kind of inscrutable, and if you took out any one major piece, the rest of the design would pretty much fall apart, because no single piece stands on its own. They only make sense once they're all put together.
Other times, a game is simply about something that doesn't lend itself to a tight gameplay loop. For example, games about exploration can't really nail down the core gameplay with little in the way assets, because the fleshed-out game world is the gameplay. If you don't have a world worth exploring, you can't make exploration fun. Exploratory gameplay is just not something you can engineer in a vacuum.
Other than that, I pretty much agree with the rest of your post. Your analysis and explanations are spot-on. The tinkerer vs. maker distinction in particular is similar to something I've been trying to communicate to people for a while. The way I usually approach it is to draw a distinction between "making a custom engine for your game", vs. "making a custom game with no engine". The former makes sense if your end goal is a game engine, whereas the latter makes sense if your end goal is a finished game. This draws the line in a slightly different place than tinkerer vs. maker, since the "custom engine" category includes a lot of people that may be dissatisfied with off-the-shelf game engines and want to make their own tech, but have been misguided to think that creating a custom engine upfront, which they plan to then make their game in, is the only alternative, because for whatever reason they either haven't considered the possibility of not using a game engine at all, or assumed it wouldn't be viable.
I don't know this for sure, but I suspect that if we make the "custom engine" vs "no engine" distinction more clear, it may clear up a lot of the FUD that has built up about making games the handmade way.
Edited by Miles
on
It is a tough thing to specify, because when going custom, building the engine before the game feels like putting the cart before the horse. However calling it "no engine" doesn't quite feel right, here I'd point back to Ted's point in the video, that you make a game, and the engine is what comes out the other side. Like, all the code that drives your game and breathes life into it can be properly labeled as an engine. So it's more like, engine-driven or engine-first gamedev. A custom general purpose engine is a lofty undertaking, and is probably not what most people actually want or need (unless they are a tinkerer and it's the autotelic nature of the thing), whereas what we're discussing is more of a custom bespoke engine that results from handmade creation.
Regarding your point on gestalt approach, you're absolutely right. I should've known better than to write "universal". It's one really solid approach, not the only approach. Kind of 'bottom-up'. Whereas a gestalt approach is a bit more 'top-down'. I think the result of a gestalt approach still results in a gameplay loop for the player, but to your point, this loop is an emergent property of the system and you wouldn't find it looking at any one of the pieces alone.
Regarding your point on gestalt approach, you're absolutely right. I should've known better than to write "universal". It's one really solid approach, not the only approach. Kind of 'bottom-up'. Whereas a gestalt approach is a bit more 'top-down'. I think the result of a gestalt approach still results in a gameplay loop for the player, but to your point, this loop is an emergent property of the system and you wouldn't find it looking at any one of the pieces alone.
deleter
you make a game, and the engine is what comes out the other side. Like, all the code that drives your game and breathes life into it can be properly labeled as an engine.
I don't think I can get behind this sentiment. A "game engine" is a specific term for a fairly specific kind of thing, and stretching the definition to encompass basically any collection of game code makes it so broad and vague that it becomes functionally meaningless.
Hi Ted, thanks for recording this (twice, hah). I saved it to watch later and finally got around to it. I enjoyed hearing your thoughts and look forward to seeing more of this interesting game. The other videos on your channel sound interesting too but I can't find the "memory management talk" that you mentioned near the end. Do you have a link?
In particular, your insight that when you build a tool it doesn't have to be generic really hit home with me. The vast majority of software out there is built on top of heavy abstractions (read: generic code), somewhat out of necessity, because its purpose can only be accomplished by talking to other software, and said other software only speaks an overly complex (again, read: generic) protocol. (Who has the time or inclination to implement their own HTTP server or client, or window manager [or operating system]?) The thing is, there is something about building on top of heavy abstractions that guides you to make your own code overly generic as well. The documentation for those abstractions says to always do things a certain way, following certain best practices that are all about propagating the generic approach. Furthermore, it's painful to program to heavy abstractions, and you have an instinct to save yourself more pain later by making today's code more generic, not realizing you're only perpetuating the vicious abstraction cycle and making your own code harder to work with.
I went on a bit long there, but that's all to make the comparison to games and consider why this community started with a game project and is still big into games: a game is (or can be) very self-contained software. It usually just wants to get a fullscreen window and be left to do its thing. A networked game only has to talk to other instances of itself, or maybe a custom server. It's the type of software best-suited to being written from scratch, because a platform layer is the only accidental complexity you need to deal with before doing what you really wanted to do. But I hope in the future, other kinds of end-user software will also benefit from this approach. The web especially has caused an explosion of abstractions because programs need to talk to each other, this means we need standards, standards are generic and therefore complex, therefore the code to implement standards is complex and becomes a heavy abstraction layer, and heavy abstraction layers are painful so people build new abstractions on top to try to avoid the pain.
In particular, your insight that when you build a tool it doesn't have to be generic really hit home with me. The vast majority of software out there is built on top of heavy abstractions (read: generic code), somewhat out of necessity, because its purpose can only be accomplished by talking to other software, and said other software only speaks an overly complex (again, read: generic) protocol. (Who has the time or inclination to implement their own HTTP server or client, or window manager [or operating system]?) The thing is, there is something about building on top of heavy abstractions that guides you to make your own code overly generic as well. The documentation for those abstractions says to always do things a certain way, following certain best practices that are all about propagating the generic approach. Furthermore, it's painful to program to heavy abstractions, and you have an instinct to save yourself more pain later by making today's code more generic, not realizing you're only perpetuating the vicious abstraction cycle and making your own code harder to work with.
I went on a bit long there, but that's all to make the comparison to games and consider why this community started with a game project and is still big into games: a game is (or can be) very self-contained software. It usually just wants to get a fullscreen window and be left to do its thing. A networked game only has to talk to other instances of itself, or maybe a custom server. It's the type of software best-suited to being written from scratch, because a platform layer is the only accidental complexity you need to deal with before doing what you really wanted to do. But I hope in the future, other kinds of end-user software will also benefit from this approach. The web especially has caused an explosion of abstractions because programs need to talk to each other, this means we need standards, standards are generic and therefore complex, therefore the code to implement standards is complex and becomes a heavy abstraction layer, and heavy abstraction layers are painful so people build new abstractions on top to try to avoid the pain.
Edited by winnythefoo
on