For a color exercise, I did a couple of sketches using pico 8's full 32 color palette. It's not always easy to figure out when to use dithering and when to choose another color. Anyway, if nothing else, this might inspire some folks for their in game graphics. A sun set in a southwester US kinda thing and a more 'rocky mountain' scene during the day.
Neither of these are finished, they're just sketches, mostly working with color combinations.
One thing I've noticed a WHOLE lot of in pico8 games is screen shake and extreme overabundance of particle effects.
I think these are both useful in providing presentation flourishes and I love them both but, especially with screenshake, some designers seem to want to 'flex' their knowledge of special effects without thinking about the actual point of the effect itself.
I will not pull up any specific examples so as not to offend any one in public or make them feel bad. What I will offer is some advice, and this advice is very generalized, but is a good principle with any kind of creative endeavor. I know some people are thinking at this point I'm going to say 'less is more', but instead, what I want to say is 'consider dynamics'.
So what I mean by this is the peaks and valleys of your presentation, your art, your game, your sound, anything. The idea is that without the quiet, there's no such thing as loud. Without the still, there's no such thing as the movement. Without the weak, there is no such thing as the strong, etc. The idea is that when presenting your game that uses a screen shake, for instance, if literally ever tiny explosion causes a screen shake, then when a boss blows up and it also screen shakes, it's impact has been lessened by the fact every other little explosion causes the screen to shake. If every little tiny flame has a ton of particle effects on it, then when there's a need to dip into particles for a huge explosion with smoke and all that, then it will just look like yet another flame in your game.
And this goes for any kind of gimmick used for presentation, whether it be as simple as 'speed lines', close ups, slow motion (with obvious exception to Super Hot style games!), it makes a huge difference on how the game feels when using special effects and limiting them so that when they do happen, it's like, 'WOW!' or 'WHOA!' or 'OH NO!' Their best uses are for visual underlining of the events on screen.
I hope this makes sense and those who read this will take into consideration how and when to use effects like these for maximum impact and not just 'flex' their programming skill for the sake of it.
Thanks for reading and keep on keepin on!
One thing I've noticed becoming a little more popular is non-violent gameplay and I really like this trend, even if it's rather miniscule compared to the broader amount of games being made. Violence is a part of our media in general (see the writings of bell hooks for more info) and so it's nice when a game provides different kinds of solutions to obstacles that don't involve 'kicking something else's ass'. Notably, most of these games, though, tend to be in visual novels, but I suspect that there's an infinite amount of possibilities to do non-violent games that aren't simply puzzles or choose your own dating adventure (i'm being sarcastic with the latter, btw) but are still high on action and skill.
I'm just writing this in hopes someone else sees this an possibly thinks of an alternative to the 'kill enemies' approach to gaming. It's been done a billion times (probably literally a billion times at this point) and while I do enjoy a shooty shooty game as I'm an arcade junkie by nature, there's a lot of games I've played that aren't inherently violent and get my palms super sweaty...and yes, I consider abstract games to be of this nature (such as Every Extend, etc.)
If anyone cares to chime in, please do. Again, I'm not making value or moral judgements here, it's just something that I think has great room for exploration thematically within game design and I look forward to being surprised because dude with gun or person that squishes enemies by stomping on them is definitely a crowded genre/concept.
Peace and keep on making games, even if they do involve a little bit of shooty shooty. I'll still be there to play it!
I'm tentatively scouting around for a good OLED display for Pico8 project in the future as a handheld computer (i.e. think Pocket Chip stylee, with full keyboard). I'm not a fan of LCD screens or TFT at all and prefer something that gives off an image that more closely resembles CRT with deep blacks and rich colors. Thus far, I found this, 128x128 color OLED screen.
Does anyone else have any experience with hooking up piZero to OLED? Does it require any kind of specific device driver?
Link to the screen if anyone's interested.
I don't think anyone will seriously read this, I'm a nobody and I never blog here.
However, it's a tad frustrating that there seems to be an overabundance of Celeste mods within the normal places to release carts which makes me wonder if maybe Pico8 BBS needs a section just for game mods?
I think it would help fix a little of the clutter. I look at what appears to be a new game then after I get into the thread, I find out it's a mod of a game I already played.
It's just something I was thinking about and there's no place on the forum to speak to this so I figured I'd just mention it into the air for it to disappear forever. :)
I apologize I have no code snippets here, it's actually a question about code.
Reading the specs for pico8, there's a 32kb limit. Is this for JUST code? I know that obviously the cart cover shouldn't be counted against any actual program/graphic/sound data, it's just for decoration and distribution, but I am working on a program at the moment, I only have 800 tokens, have used about 1/4 of the sprite sheet, no audio/sound data, and about 64 lines of text in the code...
But I'm reading 15kb already and that seems a little excessive and it's got me spooked in terms of how much further I can take this even though I'm barely using any of the resources.
Is the 32kb for JUST code? Is it 16kb for 'built in data' i.e. graphic memory and 16kb for code?
I'm curious what the actual structure is because I feel like as little data as I have thus far (no cart image taken for this program thus far) is far below 15kb.
Thanks for any help on clarification.
Has anyone else experienced trying to change their icon and blog header and found a broken jpg icon instead? I even tried reverting back and it's not showing...
I guess another question is...do you SEE an icon right now for my avatar? Could be problem on my end too...Been noticing an increasingly invasive Avast as of late, even going so far as to breaking google drive for me when active.
I'm curious as to how people look at the Pico8. While it is it's own thing completely unlike any other real console, it does share some similarities to quite a few of them, if changed somewhat still. I myself can't be helped to be reminded of how similar it's sprite capabilities and FPS being locked to 30 and color output are similar to the Atari Lynx and so I tend to think about games I would've loved to have seen on it (though the sounds on the Lynx is way better! lol) .
However, I think Pico8 also does a good job of feeling like a Gameboy Color or Palm Pilot OS3 type device as well, maybe a NGP?
Does anyone else think of the Pico8 as some kind of way to feel like your idea for some console-specific game to come to life or does everyone else kinda just shrug and think 'this is pico8, this isn't anything else at all'?
There's really no purpose to this question, just more of a curiosity about other people making stuff on it...
Testing out an engine for Super Scaler games. It's still work in progress, much is needed to be worked out with how I ultimately want to handle the slices (tiled 8x8 images or custom stretches and sizes for everything?).
Currently, sorting of the layers is not in there as I'm having trouble figuring out the best way to use FOREACH().
I want to ADD and DEL from the tables that make up the sprites, and then use FOREACH() to do the scaling rather than arbitrary FOR/END loops based on a sprite limit. The idea is that if I can keep adding to the front and deleting from the back, then I don't need to sort anything (i.e. speed increase)...but I can't get it to work!
Screensaver for when you're tired of playing small games. Every button does something. Not all of it will benefit your experience. Most effects will not be immediately noticeable. Simply hold the button for the effect long enough for it to become noticeable. Letting go of the button leaves the setting as it is so don't expect going neutral on either p1 or p2 pads will grant you any savior of frame rate.
This was a small research project for a planned item for the future. Feel free to enjoy the source for your own works. There's also a song in there commented out at the top fo the script if you're bored with flying squares.
Okay, so it looks like since I've been away, Voxatron has shifted towards a virtual voxel-based console system, which I think is super cool. And I know the current version is only 0.2.1 and that it's original inspiration is Robotron...however...
It would be nice to set controls to something other than twin stick shooter-based controls (and beyond just mapping stick two to the mouse, etc.)...
I.E. I'm not saying just making it a completely open scripting language based system because that is cumbersome for beginners and such. The current level editor and checkbox style main editing is just fine...however, choosing different control schemes and level-base properties would be welcome. For instance:
Platformer - Controls would be one stick for movement and 2 or 3 buttons for actions, one of them shoot, one of them jump, one of them free assign (i.e. use item?) and have option for the map to 'lock axis' to keep free 360 movement from happening either on x or y axis depending on the person making the stage.
Scrolling Shooter - Controls would be same as platformer, except you have two shooting options and third button could be free assign (i.e. shield activate? Drop bombs?). Autoscroll x/y would be a level option along with 'loop background' as possibility...
RPG - Same as platformer without scroll locking, jump would be optional button.
That's just some examples of how it could work. In the main voxatron control setups, the user could set their own controller options per type of level that way they don't have to remap them in the middle of a game. It's already setup for all possibilities to their preferences before they play a cart.
I think it'd fairly easy to add these 'base modes' to the editor and even have it on a per level basis that way if someone wanted to go all out with one of those old NES games that have multiple modes (like Bayou Billy or Vice: Project Doom), then these modes are tied to the level itself, not the entire cart.
Anyone have comments on this? Yay/Nay?
In the spirit of Voxatron, I created ANSITron for Petitcom on Nintendo DSi. Here's a short video of me trying to play it through an iPod screen and keep from dying and keep the game in center frame. Hint: The results are me playing extremely bad! Basically, it's Robotron done in ANSI characters available stock in Petitcom, thus really 'blocky' movement of everything. There's only 4 kinds of enemies and 10 specific level designs before it generates random levels until you get a game over. 3 of the enemies (Green, Yellow and Red) are destructible. The Grey enemies are not. They wander around seeking to destroy diamonds, which are your bonus points (and each one you collect doubles in points, so grabbing as many as you can without dying will net you some extra men!). The 3 destructible enemies just move towards you faster and faster. Depending on their color, they take up to 3 hits to destroy. If you touch anything other than a diamond, you lose a life. My highest score was around 500k and I got to the 13th level. There is a bug that causes it to crash randomly and I could not find it because it doesn't show up until after about 30 games...very hard to track!
At any rate, the download link to the QR codes is in the description if you have Petitcom. If you have a DSi/3DS, you should check out Petitcom, it's a neat little mini dev kit available in Nintendo eStore.
I've got other projects in the works for it, but this one is actually finished. :)
I like the way PC88 coloring forces creative dithering...
I took an outline someone else did and attempted the same sort of coloring style...this doesn't have 'tall pixels' but does follow the 8 colors only scheme of PC-88.
I used D-Pixed and layers using it's built in dithering patterns, alternating color/transparent spots in the two colors available.
This one was started from scratch. No intention of finishing it but uses tall pixels and was done using GRAFX2.
It's fun playing around with these methods of coloring...feels almost like weird printing press with CYMK style coloring methods...
Hi, I know this question is not really related to voxatron but in a way it is...
I noticed at the bottom of the PNG save files is some 1bit noise that is likely monster/event data.
I'm working on a program in PetitCom for Nintendo DS and have run into an issue where I have massive amounts of data I need to convert to an image in order to save and load it but I can't think of how to do this properly and have all the data save in the alloted space of the image (256x192x256).
To be in more detail, I am trying to save map data. For each map, there's 32x24 tiles. For each tile, there's a 3 digit pointer for the image, a pair of 2 digit pointers for colors of the tile to be used, and several other 1 digit pointers for various other tile properties. Take each of these and multiply it x2 minus the tile graphic and colors. So you're looking at approximately, if they were all put together in a single string, about 32 characters ('m just using 32 to make it easier to work with in the whole powers of 8 world).
Now what's the best way to convert this data into pixels? I'm racking my brain and can't seem to figure out how it's done, which is why I'm asking here because you seem to have figured it out on your own. I'm thinking, though that a lot of your data is binary to begin with whereas each piece of data I'm working with for the tile is arbitrary to the data itself...i.e. for the tiles I have CONVEYOR which has value of 0-5 and another property is HEIGHT which can be 0-9...
so can't quite figure out how to do this...any insight on converting this kind of thing into an image would be helpful. Ultimately, I'd like to stack all of that data into a single pixel since I have option for 256 colors instead of just black or white, but any advice I'll definitely take.
Thanks for the help!
I can't seem to figure out how to get copy/paste to work on selections in the room...is there a way to do this? I.E. I place some floor tiles down, i would be quick to keep doubling how many I'm working with using select->copy/paste ...