matthewmatosis
patreon
Project Proxima Developer Diary 001
🕑 Added 2021-03-28 21:06:28 +0000 UTCStarmap
While it’s not motivating to assume you’ll fail from the outset, the reality is probably that most games never see the light of day. With that in mind, it seems like I’ll need more than one card up my sleeve if I want to improve my chances of actually releasing something. As you might imagine, I’ve come up with a few ideas over the years. Four of those could roughly be described as 2D Action Platformers. They each have a different focus but the point is they would all need a similar 2D engine at their core. The plan is to develop the smallest idea first then fall back to the next smallest if something goes wrong. I think there are two good reasons for this approach.
Firstly, I’d prefer to earn money for a complete game than an incomplete one. Secondly, I think developers often succumb to over ambition, even indies. This results in either unfinished games or ones that bite off more than they can chew, leading to a lackluster experience. I’ve always found short arcade games fun. A more modern example would be Devil Daggers which is also fun. I have a small idea which might be enjoyable so there’s no reason not to try that one first.
Devil Daggers and many arcade games show that quantity of content isn't everything.
The name is Project Proxima because it seems like the closest one within reach. While these blog posts will mostly discuss progress towards Proxima, I think it would be good to name the others now so that I don’t have to mention Game B/C/D all the time. The others are, from smallest to largest: Project Betelgeuse, Project Procyon and Project Sirius. If Proxima fails, Betelgeuse will be the fall back and so on.
The focus is Proxima but I will sometimes be thinking of the others along the way. For a sense of scale, here’s a rough idea:
Proxima has a couple of aspects which might be difficult to implement but requires the least amount of content and is essentially an arcade game.
Betelgeuse requires much more content than Proxima but is the most straightforward of them all. This is probably the safest and most likely to be feasible.
Procyon is a moderate step up in scope from Betelgeuse and would also benefit from a much longer period of development to nail its fundamentals.
Sirius would be fairly ambitious even if I had experience from the other three games. As such, this one is off the cards unless one of the others earns enough money to secure more time or a small team.
To summarise, Sirius is not a serious concern at the moment but I’d like to keep the other three in mind as I get comfortable with my tools. Next time I’ll talk about collision detection where I’m building in extra complexity that might not be useful for Proxima but would be useful for Procyon. It might be a bad idea to think so far ahead but we should consider this outing as a learning exercise. It might even be best to think of education as the primary goal since I can’t guarantee the release of a game but I can guarantee I’ll learn something in the attempt. So far I’ve learned much more by pursuing this extra complexity and even had a few more ideas as a result. If a prototype of Proxima turns out to be fun then I will definitely narrow focus but for now I’d prefer to learn more about techniques and systems which will be relevant in a general sense.
Just in case this becomes important later, I’ll also mention a nebulous idea called Project Helix. This sits between Proxima and Betelgeuse in scope but I don’t have a clear picture of how it would work yet. If I can figure this one out, it’ll be an appealing candidate due to its small size but until then it’s getting skipped.
The Winter Triangle, although we'll be aiming for Proxima first.
The Greater Good
It’ll be a while before I discuss the specifics of Proxima so I’ll start by talking about my approach more abstractly. First of all, I think it’s important to know my strengths and weaknesses. This can’t be said with any certainty since I haven’t made a game yet but we can take an educated guess. Those of you who watched Mega Microvideos 2 will be familiar with the concept of More Good/Less Bad. I’m a big proponent of More Good but unfortunately for me, I believe I’m a Less Bad kind of thinker by default. Thankfully this distinction can be blurred. For example I’ve praised the Wonder Liner as a way of increasing tactical complexity during combat which is obviously More Good but it can also be framed as a way of ditching unnecessary button presses which arise from traditional weapon swap systems which is Less Bad. The two aren’t always mutually exclusive.
As you know, I’ve put a lot of effort into analysis over the years. Maybe I’m misguided but I believe one of my strengths is how isolated I’ve been from much of the discourse. I’ve never relied on others to tell me how I should think or feel about aspects of game design. In the early days of the channel this hampered me but as I’ve exercised this muscle it seems to have grown stronger. By now I’m confident in my ability to look at a game, disregard any preconceived notions of what makes something good or bad, then identify problems which stop a game from becoming a better version of itself. Basically, I have a lot of experience identifying problems but not much experience in solving them. I believe these two skills are intertwined however. After all you can:
Identify a problem.
Propose or test a solution to that problem.
Identify problems with the solution.
Repeat.
It’ll take more creative thinking than that to come up with interesting solutions but one guiding principle is the old Miyamoto quote: “A good idea is something that does not solve just one single problem, but rather can solve multiple problems at once.” This seems like the key to making a simple Less Bad change into a More Good change too. I’ll try to keep that in mind.
As for Proxima itself: Proxima is a simple arcade game. Proxima is not all things to all people. This isn’t going to be something that makes everyone say Matthewmatosis was right about everything. At best, it can be a game that makes some of you say I was right about one thing. Proxima is designed to address a problem I’ve talked about but I don’t think that would be obvious to an average player without explanation. Even so, this quality is another reason to start with Proxima. I’m enthusiastic about Betelgeuse, Procyon, Sirius and Helix for various reasons but Proxima is the most “Matthewmatosis” in the sense that it will attempt to address something I've discussed before. I hope I can elaborate on what I mean by that some day. In the meantime temper your expectations, it's probably not going to be mind blowing, just an area where the channel and game happen to overlap.
Like my videos, Proxima won’t see the light of day if I’m not happy with how it’s turning out. If one were to ask me, my greatest success with the channel was always releasing videos I was happy with, games will be no different in that regard. If I’m 90% done and don’t like it then it doesn’t release. I say this as a warning that you should brace for potential disappointment but I would also like to reassure you that I’m eager to recycle work whenever possible. In the past I’ve been surprised how often a piece of writing has been on the verge of deletion only for a few changes to cause a rise from the ashes. Sometimes the change is so extreme it goes from being the worst part of a script to the best in the span of an hour. If I run into trouble I’ll be hoping that something similar is possible with games.
Lastly, I’d like to ask for a reminder. Over the years, editing has taken greater precedence in my work. I’ve strived to get better over time and I think extensive editing has been a large part of that. I won’t pretend to understand exactly what happens behind the scenes of every game, however it does seem as though editing is an undervalued idea in game development. We’re all familiar with the idea that games get polished toward the end. All the rough edges get sanded off and finalised but what if there was a phase beyond polish? What if you had a fully functioning, ready-to-release game but then didn’t release it? Maybe this happens already but it doesn’t sound like what most developers mean when they say polish. You could argue this isn’t important in the modern era when so many games get patched substantially after release but I think that mentality is a little harmful. Once a game is out in the wild you will be reluctant to make certain changes to it. The thing that makes editing hard is that you sometimes have to ditch nice material for the sake of the overall package. This is hard to do and people consuming the work might not immediately understand why you made such a change which could cause them to lash out. Players can’t miss what they never had so the designer is certainly more free to edit before release than afterwards. I doubt this idea will matter much to Proxima but I’d like a reminder anyway. If I look like I’m gearing up to release something, feel free to remind of the importance of editing.
Concerning Engines
There are more options than ever for choosing how to develop a game so picking GameMaker wasn’t done lightly. Even so, I wish I had a more sophisticated answer to this question because the main reason is actually pretty simple: I don’t want to make my own tools. I have no experience with tools programming and right now it’s not something I find particularly alluring. Tools programmers are arguably the backbone of any development studio - they probably don’t get the kind of recognition they deserve - but I’m not convinced it’s the job for me. I’d prefer to spend my time dragging and dropping tiles than writing the program which allows me to do that. GameMaker solves the level editor and sprite drawing problems. It might be fair to say I’m not even picking GameMaker for its engine exactly, I’m picking it for its tools.
We have a long way to go but at least we have a grid to place tiles.
It was tempting to use Unity instead but from what little I tried, making a 2D game in Unity felt like trying to square a cube, so to speak. It’s been a while since I checked it out so I won’t go into specifics but my overall impression was that it would be unnecessarily fiddly to make a 2D game since it’s a 3D engine with 2D features, not the other way around. This isn’t some attack on Unity though. If I ever move to 3D development it would be a great choice. Perhaps even 2D development has certain advantages when it comes to parallax or other techniques but so far I prefer the simplicity GameMaker has offered instead.
There are some legitimate concerns either way. Using any generalised engine is less efficient than a custom built one. Jonathan Blow has put forward a convincing theory that software is not actually getting better. Reliance on generalised tools are one reason why. When you don’t know what kind of game the user will make, you have to support a bunch of extraneous junk they’ll never actually use. Users themselves also avoid having to solve certain problems which reduces the number of people with that skill. Assuming I release a game with GameMaker I’ll be a perpetrator of this decline since I’ll be rendering a simple 2D game with more horsepower than actually needed. I don’t like the idea of perpetuating inefficiency but my excuse is that I’m also a victim of increasingly convoluted development.
Ever since I got into programming I’ve just wanted a simple way to get sprites on the screen. I’ve always been envious of developers who started out in the NES/SNES era for that reason. I know they had their own troubles but even their problems seem more enjoyable to solve since they relate to the fundamental workings of the hardware. Maybe there’s something wrong with my thinking here because graphics libraries have long outlasted any specific device and yet I can’t help but think I’d be much happier learning the intricacies of a Mega Drive than DirectX. Anyway, I won’t wax lyrical here, I’m just glad to have a simple method for drawing graphics along with the necessary tools to drop pieces into a level, that’s all I really want. Most of what I’ve done so far could easily be exported to another engine anyway so I wouldn’t say I’ve made some huge commitment yet either.
My only real concern right now is that Proxima may require me to draw a large number of sprites at once which could be a problem. A brief test indicated that I might be in trouble here but there are still many optimisation techniques to try before worrying about it too much.
One Frame at a Time
A little knowledge can be a discouraging thing. I learned about the difference between framerate dependent and independent (delta time) engines a long time ago. Unfortunately, I think this knowledge is one of the things that held me back. Knowing that framerate independence was the “proper” way to do things but also considerably more difficult to implement is disheartening to say the least.
There are many reasons why I decided to finally pull the trigger on game development but I think the wheel really began rolling around the time I was finishing up my Viewtiful Joe commentary. It would be worth listening to my speech on framerate dependent programming here. The gist is that there is at least one argument in favor of framerate dependent programming and even if you reject that argument, maintaining a stable framerate closes a lot of the gap between the two methods. This topic was one of the last things I wrote for that video and (like many of the things I’ve written over the years) it came as a sudden revelation to me. One of the best things about doing full-time analysis was that I really got to hold a magnifying glass over everything. While I’ve always strived for accuracy and depth in my work, I’ve looked at Devil May Cry and Viewtiful Joe more closely than any other games which was an extremely valuable experience. This insight about framerate dependence probably didn’t matter to most people but it mattered immensely to me.
I've spent a lot of time in Movieland.
I own a 144hz monitor so I’m not going to tell you that a 60hz cap doesn’t matter. It does. In my experience, the faster the game the more it matters. The final levels of Thumper are a great showcase and first person shooters benefit greatly since the entire perspective tends to shift with every frame. That said, I’m making sidescrollers here. 144hz would be nice but probably not a game changer.
Thumper is so fast paced that higher framerates have a noticeable impact.
Additionally there’s the reality that a lot of classic games are framerate dependent. Do I think Viewtful Joe is bad because it uses this style of engine? Not at all. What about Pac-Man, Super Metroid or Resident Evil 4? They’re all still great games by my reckoning. If I play them without complaint, why should I dwell on doing the same thing they did? There’s a lot to be said for having pride in your programming but I want to start with something simple and build from there. This has been my way of saying that Proxima will probably have a 60fps cap. It’s not ideal but I’ve been thinking it’s not such a big deal either and if the game itself goes on to be a success it can always be revised later.
The Critic Curse
How often do critics successfully create something in the medium they once criticised? I honestly don’t know but from what I hear the prognosis isn’t good. It’s not something I’ve spent a lot of time thinking about but it seems foolish to continue without at least thinking about it a little. Speculating might help me avoid some pitfalls.
If I had to guess, I would say the problem critics face when they try to make something of their own is that they’re too attracted to rules. This is a natural impulse when you remember the critic has no say in how a work is formed. Games would continue to release no matter what critics said or did. If artists are players on a field then critics are referees, except each referee is making up his own rules so there’s no clear winner. Under those circumstances it’s easy to see why you might become obsessed with proving that your rules are the ones which should govern the outcome. The problem with this line of thinking (or analogy) is that artists aren’t actually playing against each other. Each artist is just following their own desire to make something, they might not care about what’s happening on the field. Oscar Wilde put it like this:
“Diversity of opinion about a work of art shows that the work is new, complex, and vital. When critics disagree, the artist is in accord with himself. We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely. All art is quite useless.”
Some artists have been brutally critical of others. Apparently Orson Welles, once said “I hate Woody Allen physically, I dislike that kind of man.” along with many scathing comments about fellow filmmakers. Surely that should be enough to classify him as a critic, even if that wasn’t his primary work. It seems as though game developers tend to be less outspoken about their contemporaries but everyone must hold opinions privately which makes them critics of a sort too. My point is merely that critical thought itself isn’t poison, at least in certain doses. Maybe dwelling on it too long is the problem or maybe there is no problem and the track record of critics simply reflects the average track record of anyone trying to break into a different field, which admittedly is grim.
This is taking too long to write and I’m not sure I’m getting any closer to an answer. I suppose it might be useful to do more research on this topic but I’m just going to follow my own advice which is to pursue a vision regardless of how other people feel about it. Of course I hope others will enjoy it because that will allow me to fund another project but the main thing is to be in accord with myself. Personally I find this to be a natural and relaxing way to operate. If you only need to please yourself then you just work on something until you’re happy. It might take a long time but I think I can get there eventually. Here’s hoping.
Comments
I very much enjoyed reading through your thoughts. Your openness to sharing your own thoughts this candidly is an inspiration to me. I'm rooting for you.
Blooper
Good read, and this was actually quite a bit more than I expected from an update like this.
SteveReen
Really good read. I had a similar experience messing with Unity which I think I mentioned on an earlier post. I know it's possible to make 2D games good with it if you know what you're doing, but it just seemed like more work to get right than is worth doing for me. On a sidenote, I came across that talk from Jonathan Blow a while ago and loved it, he makes a lot of great points. Regarding framerate independence, I definitely think there is more nuance to it than some people suggest. Personally, I think it depends a lot on the type of game, but I actually like certain aspects of games being framerate dependent. I like a game having discrete states that can be predicted exactly from one step to the next (as opposed to things being a bit more vague depending on the exact amount of time that has passed since the last update); it generally feels "tighter" to me that way if that makes any sense, and is how I would like to design a game myself. That said, being able to run at higher framerates for something like a shooter has obvious advantages as mentioned. Thumper is also a good example, and in a more general sense I think rhythm games are a type of game where framerate independence is crucial, since everything needs to stay in sync regardless of if frames drop or anything. Anyway all of this is to say, I agree with your assessment that it's not as clear cut as some might say, and I'm definitely okay with any game doing one or the other based on its own particular needs. Lastly, I definitely like the attitude to "pursue a vision regardless of how other people feel about it." Not exactly a shocking take or anything but I think works from that mentality tend to be the most interesting. This is part of the reason The Witness is currently my favorite game; I don't even necessarily like everything in the game, but when I look at it as a whole, I see something more unique and personal than most other games. Obviously I'm not suggesting that what you're making is comparable to that in any particular way, but I guess my point is, I'm supporting you to make exactly the thing you want to make. Maybe you'll bring it to completion and I won't even like what it turns out to be in the end, but I'd be happier to know you made the game that satisfied you. Anyway sorry for rambling I guess. I enjoyed reading this and am looking forward to seeing where it goes as always.
Dorkaxe
These types of posts might be worth the patreon pledge alone, wow, lots of interesting stuff here. Keep it up, man.
Cool post, I think you are being too hard on yourself about the timestep thing. There is still no clear winner on what is objectively better between frame rate independence vs dependent. The conversation is a little more nuanced though. One example I can give you where there is no choice but to be frame rate dependent is games that run in the browser. A limitation of websites is when you reach the end of your game loop you need to return control of the program back to the browser. If you immediately start the next loop's calculation then the web page hangs. Another issue is the difference between rendering step and physics step. I think you might have noticed already that your renderer and physics engine are coupled together. This is where the right architecture choice should be to separate the two different threads. This only matters if your animation system is based on a interpolation instead of a sprite sheet. For example using a skeleton system to animate your characters vs using key frames. If using the latter you don't get much out of separating the two but you don't lose anything either. Maybe you could make the argument that it runs better but the separation and run time improvements are trivial. Now the REAL question is whether your physics system is on a fixed step or delta step. The answer is usually fixed step. There are a whole course of floating point errors that are eliminated if you know how much you are integrating by. Unless you really need variable time step or your a simulating the environment (graphics, realistic collision) there is no reason to use variable time step. Curious to see where the development goes.
GMS2 is probably the most reasonable option if you: - Want to make a 2D pixel-art action game. - Don't want to write any of your own tools. It has many varying issues, but don't feel bad for choosing it. You could do a *lot* worse when it comes to choosing what to make your game with. I don't know how many people here are experienced with it, but I've used it for a long time, and if you ever get horribly stuck on something I'd be happy to help.
David Foster
Best of luck with the projects, Matthew! I’ll miss the analysis because you’re one of only two critics whose opinions I have faith in! But you got to do what you want to do. If I can be cheeky and give a little bit of advice, never be so stuck to a plan that you discard those so called ‘happy accidents’.
super excited for you! you’ve actually been somewhat influential in inspiring me to go back to college and change career paths. i start next month!
Incaptivity
Much more interesting update than expected! As for a critics curse, I get a lot more concerned about the extra scrutiny placed on a critics creations. Neat to point out how the critic themself might fall into all kinds of pitfalls
Interesting update. Good luck and see you next month!
Thanks for the update! Rooting for you and your project!
Matthewmatosis
I decided it would be a good idea to have a buffer between my work and the blog posts hence the collision stuff coming next month. If you’re looking for a more straightforward status update, this month has been productive but less than I hoped. On the one hand I have a solid enough base to accommodate Proxima and Betelgeuse but on the other hand the current system imposes some limitations on the way levels can be designed. Those limitations are minor and probably irrelevant to the first two projects but I would prefer to solve them if possible before moving on. Allowing myself the maximum amount of freedom when it comes to level design seems like a worthy goal. Unfortunately, trying to solve some of the relevant edge cases has caused me to go in circles more than once which has been frustrating. Still, I am gradually making progress and have become more familiar with tile-based systems in a general sense so it’s not all wasted time. Hopefully I’ll be comfortable showing it off next time. If not I’ll come up with something else to talk about.
