Controls:
[ Player 1 ]
Move Left: Left Arrow
Move Right: Right Arrow
Move Up: Up Arrow
Move Down: Down Arrow
Shoot: X
[ Player 2 ]
Move Left: S
Move Right: F
Move Up: E
Move Down: D
Shoot: A
Pause Game: P
=============================================
I recently followed the Dom8verse tutorial on shooting bullets and checking collisions, which is found in Pico8zine #3. After I finished the tutorial, I kept trying to add things with the hopes of learning more about Pico-8 game development (I usually learn best when I present myself a personal challenge). One thing lead to another and I ended up creating a very simple 2-player (unfortunately it does not have a 1-player mode) robot battle game.
This is my first Pico-8 game, so feel free to let me know what could be improved.
3/11/2018 UPDATE: I went ahead and improved the map artwork and at some basic particles when a player gets hit. Special thanks to Felice for the suggestions.
3/12/2018 UPDATE: Added a shot rate to the player's blaster. Tweaked map graphics.
Gosh, given the genre, I'm not sure you could have done it a lot better. I only see two things to suggest:
-
A small audio/visual effect when a successful shot hits an opponent is satisfying for the player. You already added a sound, so you're halfway there. I'd obviously leave the actual choice to you, but examples from other games would be a little electric zap, a little flameball, a little smoke puff, perhaps some physical pushback on the target, or maybe shake the target or the screen along the axis of the shot. One or more of those, or something similar, would seal the deal.
- I'm having to guess, but are the barriers means to be, like, hedges? Or pipes? At first the screen looked like a platformer where I should be jumping from one bright-topped surface to another, so I was momentarily confused until I realized they were walls and I was simply meant to walk around them. Depending on your intended motif, there might be a way to make this clearer to the eye. Maybe a shadow? I really dunno.
I glanced at your code, but you seem like someone who knows their craft, so no need for advice there.
Pluses:
Nice audio. Everything has a sound, even walking, so that's great. People often underestimate how putting sfx in the appropriate places can constitute half of their game.
I especially wanted to call out your animations. Considering the bots are mostly 4x6 rectangles, I think you did a great job, and very thorough as well, with lots of different animation phases. It's very pleasing to walk them around.
Have you written games before? I would guess 'yes'.
Felice, thanks so much for the great advice!
I'm definitely going to attempt to add a visual effect when the player gets hit. The map artwork is a little weak too. I'm going to rethink the art design. Having dark floors makes it hard to add shadows.
As for my background, I have very little programming experience. I've been self-teaching myself Python for general purposes but game development always interested me. I've messed around with other simple game engines but I wanted to actually learn how to code a game. Pico-8 made a lot of sense for me because I felt it had limitations that would force me to keep my first games simple and Lua is not intimidating to learn.
To be honest, I didn't plan on releasing this little 'game'. But I felt it would be a good way to get comments and help me learn.
I really appreciate the comments.
If you're still relatively new to programming and you're writing code like what I see here, then I think you have a knack for it. I'm going to offer you some advice, from a 20-year games industry vet, because I think it's a shame for someone with the knack to miss the opportunity to be great.
Make sure that, if you don't go to school for it, you deliberately pick up some of the fundamentals you would want to get from school/college. In the same way we all learn multiplication tables by heart in elementary school, to allow us to do more advanced math without having to think about the grunt work of longhand multiplication, you want to learn a bunch of fundamental algorithms by heart as well.
I'd suggest finding a book, site, or course concentrating on such fundamentals. Look for something that'll teach you foundational stuff like trees, lists, hash maps, sort algorithms, etc. Both data structures and algorithms have these fundamentals, and you want to know them by heart. Even if you usually use high-level language functions for such things, it's reallllly useful to understand how they work under the hood.
Especially learn how to analyze and describe the complexity of an algorithm. This is usually expressed in "big-O" notation. If you either know or can recognize an algorithm's complexity, you can readily make the right choices for different conditions. Some algorithms are fantastic for small datasets, but don't scale well. Others scale well but have too much overhead for small datasets. Getting that knowledge into the programmer equivalent of your muscle memory will help you decide reflexively how to get things done and not get bogged down in the specifics of implementation or (late) optimization.
In the same vein, get a solid understanding of what I think is technically called "discrete algebra", but which we usually just call "logical expressions", with words like 'and', 'or' and 'not'. Build up a really good feel for how to manipulate and simplify them, because that can reduce a big pile of code to a very small amount of code, same as with arithmetic expressions. Logic and math almost parallel each other in that respect, and you want to be able to look at a semi-complex expression and just automatically know, from rote learning, which bits will reduce down to simpler forms.
One thing a lot of self-taught programmers don't do is to learn what a "truth table" is, and the methods (I think there are three really good ones) used to convert it into a single expression. That lets you take a table of inputs vs. outcomes and produce a logical expression that converts the inputs into the outcomes without needing a bunch of "if" statements or the like.
Good luck, and welcome to our world. :)
Thanks for the detailed guidance! I'm going to research these topics and make sure I understand them. I think instead of focusing on specific game engine tutorials, I'm going to take some time to learn general game logic programming.
Quick question, do most people use the Pico-8 editor for coding or is it more common to switch to a regular code editor like Visual Studio Code?
Thanks again for the help :)
I honestly don't know what most people do. I like to just jump in and use the built-in editor, but that's largely due to being too lazy to spin up external editors and stuff when I just want to try a quick idea.
I think a lot of people end up using external editors and tools because the complexity of their project is too significant for the built-in tools to handle comfortably.
Really, it's very subjective. Dabble in various different methods and see what works best for you. There's really no better way to choose, in my opinion. The rest of us are just people who did the same, with varying personal needs, not to mention degrees of diligence in trying different methods. What we found might not be the best fit for you (or us, for that matter).
Felice, I think I'm going to try and use the built-in editor for as long as possible. If I create a project that becomes a bit difficult to manage using this editor, I'll consider trying something else.
By they way, I updated the game using your suggestions. Thanks again!
I like the art a lot.
You might want to add a longer cooldown for shooting and some 'invulnerability' time after someone gets shot. Right now, if one player has a wall of bullets they can destroy the other immediately.
For AI.. there are a lot of ways to go. As with most things, Felice is probably the expert here.. But my 2 cents is to start with something simple like moving in a random direction for N seconds, and if the player crosses the line of sight (if you ignore walls, it's the same as collision, just do x or y instead of checking both) then move in that direction and start shooting.
| As with most things, Felice is probably the expert here.. |
I appreciate your confidence in me, but I'm fallible. :) One of the things I fall very short on is AI. Quite honestly, I suck at AI. I don't think I'm fundamentally incapable of it, but I have almost zero experience writing AI. My career track just never took me anywhere near it.
[Please log in to post a comment]
