i started a thing but i dont think ill manage to make anything by february since i’m also just starting to learn both löve and lua.
did get to the point where i can draw an isometric map correctly while moving a character around. the movements are tilebased which both makes some things easier but is also giving me other troubles to solve.
Haven’t done any more programming on my thing yet but I did get sprites drawn for a couple different enemy types and a few frames of animation for each. Still not final versions but I like how they’re turning out. It’s amazing what you can accomplish with just 8x8 tiles. Might post some pics tomorrow. Also made some okayish sprites for a couple treasure pickups. Those don’t have any animation yet but I think I’ll try to make them look sparkly.
I need to add more animations to my player character sprites and and get those called out properly in my player controller algorithm. Currently supports 8-directional movement but I’m only going to do animations for 4 so I’m wondering if I should restrict movement to 4 directions as well. I’ll have to get the animations implemented first so I can see how it all looks in action before I decide. Most likely I’ll keep it as is since it feels fine the way it controls now and I should keep everything as simple as possible.
I’ve also created preliminary tiles for more maps. I have enough now to have three or four distinct looking maps and that’s probably what I’ll settle on for now. I want to get the structure of the game built and get my basic gameplay stuff implemented before I decide if I’m going to make any more new content.
Basic gameplay loop is:
You spawn into a map (a maze) with the objective to get a key to unlock an exit door.
The key will be behind a gate that unlocks after you kill enough enemies, which spawn continuously as you kill them so there is always some set number of enemies on screen with you.
You can shoot them and one enemy type can shoot back.
If you get hit by an enemy or an enemy bullet you lose a blip of health (I’m thinking four blips before you die) and drop the key if you’re carrying it.
Another enemy type will try to grab the key if you drop it and take it back to the gate to lock it up, resetting the counter to unlock it again.
If you get the key to the door tile you win the map and move on to the next one.
Some additions/wrinkles on top of the basic gameplay loop:
Restore health blips via pickup and scoring threshold which is met by gaining score from killing enemies and reaching treasures.
Treasures are worth substantially more score but in order to reach them you have to cross unavoidable environmental hazards (floor tile that does one health blip of damage when crossed)
There are three locked doors but only one is the true exit. Not sure yet what I want the false exits to do beyond displaying a “try again” message.
Haven’t decided if I want to implement a timer counting down at the start of each map. Would be a good way to instantly create tension and I don’t think the basic gameplay loop is too complicated to not understand instantly so it doesn’t require much tutorializing beyond basic messages like “get key” or “press ‘x’ to shoot” or whatever. But if I do the enemy behaviors right and balance everything correctly it should also be possible to achieve an indefinite steady state of gameplay of getting and losing the key and losing and gaining health blips so a timer could mess with that. Night Stalker doesn’t have a timer and I’m loosely basing this off that so for now I probably won’t implement one but it sounds like it could be cool if I could see a way for it to work without hurting the basic loop. Maybe have the timer as a hard mode/next loop type thing.
If the condition of the key getting returned to its initial cage is met should the number of required enemies killed to reopen it increase by some amount? Maybe not but then maybe it could as part of a hard mode/next loop type thing.
So stuff I need to implement/program is:
I think that’s it. That’s a game design right there and there’s no task there that hasn’t already been solved by someone else long ago. Just need to keep learning and picking away at it. Maybe it will even turn out to be fun.
I have some doubts that I will finish by February but I will finish eventually. This is the year I make a game almost from the ground up. I say almost because while Pico-8 requires programming ability it automates a ton of stuff too so it’s not quite the same level of challenge as doing everything in C. Though making something totally new in C might be a cool project after I finish this one.
Having made prototypes and demos and abandoned projects in a lot of other frameworks and languages, I can say definitively that Pico-8 is pretty “real” in terms of game dev. Like Unity would “automate” way more. Pico-8 gives you a light framework, some constraints, and a way to display graphics and play sounds, but Unity would give to collisions, physics, animations, CPU and RAM overhead, and a bunch of other game-adjacent APIs and helper functions.
Pico-8’s strength is that it limits you with constraints to encourage you to scope your project properly, and that all the tools you need are baked in, but you’re legit programming a game from the ground up. The main difference is that most other languages & frameworks have a bunch of mental overhead and esoteric shit that you have to pay for before you get to the fun part. Once you get used to it, it takes like a week to abstract away that stupid shit and then you’re back to where you could have started with Pico-8.
Pico-8’s limited palette and colors and sounds give it a cohesive charm that I had trouble achieving with other tools, and it helps you set reasonable goals, and it feels approachable, but it’s not doing much else than that and it’s absolutely real game dev. If you can make a game in Pico-8 you can make game in about anything else, you’d just have to “pay your taxes” and slog though learning the boring shit.
Honestly, you’ve just sold me on Pico8. I think I’m gonna learn it!
Yeah I guess automate is the wrong word to use. Like isn’t Lua built on top of C? And C is built on top of Assembly? And Assembly is one layer up from binary? Like what is the hierarchy for all these things and how do they fit together?
Does the way computers work today still map onto the first stored-program computers from the 1940s? This paper has an interesting diagram at the end of it on page 17 (it appears to be a short student paper and I found it incredibly informative for understanding computing fundamentals):
Which layer of that diagram do things like Assembly and C and Lua fall onto?
I like Pico-8 precisely because you have more freedom from the start compared to something like Unity and it seems like a good gateway into learning how to program in general. But I’m kind of hung up on knowing what is programming exactly. Like I understand all this stuff in the abstract but I don’t fully understand what is literally happening when I write a program and how it is literally happening. That’s a big hindrance to my ability to learn something new like a programming language, is not knowing exactly what’s going on in relation to the bigger overall picture.
I appreciate APIs but I appreciate fundamental understanding above all else and I feel like the fundamental stuff is totally lacking in any given beginner approach lesson I’ve come across so far. I’m so sick of hearing everything explained via analogy (and this goes well beyond just the topic at hand I should say). Maybe I should have studied computer science in college.
I applaud everyone who’s doing a game with dozens of endings and actually pulls it off. I tried it before and it’s very rough.
For my game this time I decided on having one ending basically, although it has two major variations. I still try to acknowledge most of the things the player has done though, just with text variations during the one ending. The idea was to still make it satisfying.
I hope that depending on the player choices during the game the ending will have different connotations. Because it’s happening in a different context I hope it will hit differently for everyone. I designed it like that from the start with this in mind, so I hope it will work and not be a Mass Effect “colored ending” type situation. (I haven’t played the ME games, I just gather that that was the problem with the ending, that it didn’t take into account everything that came before and wasn’t satisfying.)
I’ll start this post by saying that yeah, beginner programming tutorials aren’t going to tell you how a computer works because it largely doesn’t matter. The whole point of abstraction is that you can just focus on the layer you’re working with, and trust that the layers underneath are carrying out the high-level commands you’re giving them.
As far as explanation by analogy, well, unfortunately, basically every layer of a modern computer is complicated enough that almost any explanation is a gross oversimplification of what it’s actually doing.
If you’re very interested in how computers work at lower levels, that’s cool! But that information is totally unnecessary if you just want to make a game. Programmers can be pretty elitist and gatekeepy and you might think you’re missing something important or fundamental or enlightening if you don’t understand every level, but you’re not, really! If you’re making something that really stretches the hardware and is performance critical then you might need to do a little more research on the next level down. But like John Carmack doesn’t understand every detail of every processor Doom ever ran on because he doesn’t need to.
I can’t even keep the entire context of the game I’m currently making in my head (less than 2k lines of code), let alone the architecture of my whole computer.
Programming a game in assembly ultimately isn’t that different than programming a game in Lua. The syntax and amount of overhead and context you have to keep in your head is different, but the algorithms and logic you’re having to employ are basically the same. Like a series of multiplications might involve loading values into different registers in assembly over multiple instructions, while in Lua in might all fit onto a single line, but in both cases the computer is multiplying and you, the programmer, have to consider the higher-level algorithm and the reason for that multiplication.
High-level programming languages just remove the burden the programmer has on telling the processor EXACTLY what to do and gives them tools that can simplify the implementation of an algorithm. Like, “add these two numbers together and give me the result”, rather than “put this number in this register, put this number in this register, call the add instruction, and then read the result from this register”.
Most of the abstractions listed in that paper still exist in modern computers, yes. Assembly and C and Lua ALL use those abstractions at some level. The thing that I was surprised about when I was learning comp sci was that things like calling a function and returning a value – stuff that seems like it’s a pretty high level of abstraction already – is actually directly hardware supported. When you call a function in Assembly or C or Lua, they’re all using the hardware-supported calls to like store data and instruction pointers on the stack, and the pop it back off the stack when the function returns.
If you’re super interested in how computers work at a low level, studying some form of assembly language is going to give you the most bang for your buck. Programming languages are just layers of abstraction on top of assembly (which is a pretty thin layer on top of machine code, which contains the instructions that the processor actually carries out).
At the lowest level, a processor basically reads a series of instructions in the form of numbers (e.g. binary or machine code). A processor has a defined “instruction set”, and each instruction has a unique number to define the instruction, and then a list numbers after (how many depends on the instruction) which are used to pass arguments or additional data to the instruction.
To understand the assembly level, we first need to understand what a compiler is. A compiler is simply a piece of software that reads instructions written in one language, and then outputs instructions in another language. The very first assembly compiler would have been written in machine code directly. Once your compiler is robust enough, you can start writing the compiler in the language itself (e.g. an assembly compiler written in assembly), by using the compiler you wrote in a lower-level language to compile your compiler (a process known as “bootstrapping”).
So to get from assembly to machine code, we just need a compiler. The translation here is pretty straightforward – again, assembly instructions pretty closely match the instructions the processor carries out, they’re just more human-readable.
To get from C to assembly, well, it’s just another compiler. This conversion here is a little less straight-forward. C somewhat abstracts away what instructions the computer is doing to complete a certain task or algorithm, so a few lines of C code may compile down to lots and lots of lines of assembly.
To get from Lua to C, that’s also a bit more complicated. Lua compiles to an intermediate byte code, which is read by a Lua virtual machine. A virtual machine is essentially software that acts like a processor (carries out commands based on its defined instruction set). The Lua virtual machine was written in C, so it’s a C program that reads Lua byte code and carries out those instructions.
So the whole process looks something like: the Lua code you write compiles to byte code, the byte code is read by a Lua virtual machine that was written in C. When the virtual machine was compiled, that C code was translated to assembly, which was then translated to machine code by an assembly compiler, which is then carried out by your computer’s processor.
But again this outline is a gross oversimplification at almost every step; there’s so much complexity in any of these layers that individuals that work professionally on a specific layer don’t even know the whole of it.
Hopefully that gives you some of the context you were looking for, or at least some jumping off points for your own research. Again, totally valid if you’re interested in it and if that’s what excites you, but certainly not a requirement to make a game.
Yeah Pico-8 is pretty rad. It doesn’t hold your hand but its simple tools and constraints and clear identity were what got me over the motivation and creativity hump that I struggled with in the past. I wouldn’t have dabbled in like generative art or music without it, too. It’s limited in a way that makes it feel inviting.
Definitely try to scope small. Like the original Pico-8 Celeste cart was stuffed to the brim so don’t scope bigger than that, unless you want to learn a bunch of esoteric shit and start dealing with multicarts.
I have an article I wrote directly after making my Pico-8 game that touches on a lot of this:
https://gate.itch.io/heat-death/devlog/121708/pico-8-motivation-and-value
Testing a “number block” mechanic. Not sure if I’m sold on it yet. I’m trying to solve a problem: namely the tedium of having to push long lines of blocks around all the time. Since this block has an internal state, I can encourage the player to interact with the copy & infinity mechanics without forcing them to deal with the “cleanup” of moving around a bunch of blocks at the same time.
These wouldn’t replace the shapes. Some levels are easier to design around the number blocks, and some work better with the shapes. The combination mechanic means you don’t want to push them into each other sometimes, so they could be used for different types of puzzles too.
I’m sold! keep it! numbers and shapes and colors! oh my!
yeah i did sort of like the sesame street aesthetic i was quickly approaching
Okay, yeah it’s staying. This new number block mechanic fixed like 4 puzzles I was having trouble designing. The statefulness & combination mechanics are really powerful. And I have a bunch of new ideas I wrote down too. Nice!
I love pico-8!! first thing I’m doing is fiddling with sound effects. Producing good results!
Some time in the future, or maybe during this jam, I will make a SFX pack
(I kinda wish I could participate in this but peak season at work starts next month so I’m trying to take it easy)
Even when you know what you are doing, this happens a lot in software development (especially when you are learning something new) and you shouldn’t feel bad about it. As others have said, don’t be too results-oriented and appreciate the small victories you make as you pick up new things.
Video games being a mostly visual medium means that it’s incredibly easy to fall into a trap where if something doesn’t look like a nice, playable game, it feels like we wasted all our time making dogshit. In reality, you’re going to be writing a lot of “infrastructure” and dumb math functions that are profoundly important to your game whose impact will never show up in a screenshot, and you can’t feel like one of those victories counts for less than something that does show up in a screenshot. My last Ludum Dare game looked like janky shit (no offence to the artists, it was mostly my fault) until about six hours before the game had to be uploaded, and now I think it’s one of the coolest things I’ve ever made.
Had a vague idea to make a game where you feed monsters, so I tried making a sprite in PICO-8. The constraints really helped me get something made (I’d probably still be trying to decide which colours to use if they weren’t already chosen for me).
This took me hours and I’m pretty unhappy with it! Suggestions welcome.
Looks great to me!
Here’s some gifs from my project showing the current state. First up is my player character in the first level showing his four frame run cycle and two frame idle cycle.
Next up is a view from the sprite editor of the enemies I’m working on.
PRO-TIP: F8 will start recording a gif and F9 will stop recording. Saves automatically to desktop and captures the most recent 8 seconds.
But real suggestion: If you’re unhappy with it you can either try slowing down the time intervals in between each frame so the loop plays out slower or you can alter the robe at the legs to kick up higher with each leg lift so there’s more exaggerated movement/motion during the default cycle (by which I mean maybe remove a couple pixels on the “inner leg” in either footstep frame so there’s a two pixel gap on one side and then it flips over to the other side maybe idk it is a challenge getting good animations in such a small tile).
Also FYI there is a second HIDDEN color palette in pico-8, just recently discovered apparently.
https://www.lexaloffle.com/bbs/?tid=35256
You can swap between the default palette and the hidden one or use both in conjunction by swapping between them frame by frame.
And just because I don’t want to spam the topic here’s a great resource for pico-8 but I don’t know if it’s still getting updated or not.
There’s actually a per-scanline palette that was discovered this year, where you can set the palette per horizontal row of pixels. And with screen rotation modes, it means you can actually do this on vertical lines too.
