The general strategy for developing Voxatron's toolset is to provide specialized features (modifiers, microscripting, physics properties etc) that capture 90% of a typical designer's requirements, and then leave the rest to Lua scripting. Lua will be kind of like a glue that that holds the engine together and fills in the gaps of functionality.
Working on custom player inventories and menus that have a plethora of possible requirements, I feel I've hit that 90% boundary. The engine is now complete enough that it is possible to create a Lua API that is grounded in something stable and maintainable. For this purpose, I've created a text editor that can be used within Designer, and a custom version of Lua designed to work efficiently with Voxatron (both of which you can see in action in PICO-8). It's time to (carefully) plug everything in and see what happens!
It will also be possible to write cartridges from scratch in Lua, of course. This would be handy for making games that need their own style of physics, or things like RTS, sim or puzzle games that deviate a lot from typical Voxatron shooty-runny things. The purest cartridge can contain simply one Lua script, and no rooms or object definitions.
If all goes well, I'll start to roll out a minimal API later next month for anyone to experiment with. It is a typical object-wise callback scheme, where things happening in the world/engine call Lua functions that the cart designer provides.
Here's a simple example:
[vine]eiTpKIL2eLZ

8/11/2015 - first "level" created. Buying and something resembling a puzzle added. still no death :P
7/22/2015 - better enemy movement, beginnings of the shop
7/22/2015 - total re-write @_@
7/6/2015 - hud, area titles, updated ladders
6/30/2015 - enemies
6/29/2015 - ladder code added
6/25/2015 - added basic sound effects - still working on ladder code

For some reason, when POKE()ing an invalid address, my program quits with the following error message:
triangle square dot lines square triangle triangle lines
Those symbols are printed just like any other fatal error. It doesn't cause any problems, but I think a normal error message would be more helpful.

Hi zep!
pget seems to use the camera which is kind of strange I think...
This does not do what it looks like it does if camera() is used:
col=pget(x,y) pset(x,y,col) |
Manual correction (if cx and cy are camera position):
col=pget(x-cx,y-cy) pset(x,y,col) |
Is this a known issue or am I misinterpreting something here?
Thanks!

A replica of the title screen of metroid for the NES.
History:
- 0.1.4 - removed syncopation in the 6/8 section
- 0.1.3 - pressing a button doesn't end the game (it was confusing)
- 0.1.2 - finished 6/8 section
- 0.1.1 - fixed some errors in the melody
- 0.1.0 - initial version
To Do:
- add texture to the ground
- improve logo + animate
- add stars
- add emergency order
Old Versions:
So according to a thread I read five seconds ago, Lua script is coming soon. BUT WHAT IF IT ISN'T SOON ENOUGH?!?! (Or maybe that wasn't what I read.)
Anyway, here is a way to add simple logic in Voxatron levels, within a single object, (ab)using the Priority and Modifier mechanics.
The first demo shows how Priority works. Each rectangle represents a triggerable object (such as an animation or a modifier). The white objects have their duration set to 5, and the black objects have their duration set to 0 (indefinite). They each have their priority written on them. When you activate one, it 'shadows' all of the ones beneath it, preventing them from activating or activating the one set as 'next'. The indefinite ones can still be turned off by activating a higher priority one. This can be used to create things like S/R latches.
By the way, the diagram is one object. It receives input from the buttons via IS:OBJ_ID:##:M_STATE:SHOT.
Next is a demo of Modifiers, represented by hollow rectangles. Like normal objects, they can be forced off by shadowing them. They will also disable all of their children while they are disabled. The red object's trigger is set to PARENT:ACTIVE, so it will always be active while the modifier is. You can use this to shadow other objects or have multiple 'next' objects for one modifier. The children also won't send or receive 'next' triggers while their parent is disabled, as shown with the one at the bottom.
Using these, you can build complicated networks, like the one for this passcode door. Here's how it works:
-
The object at the top resets the lock using three children (not pictured) that are set to IS:PARENT:TIME = 1, so that they'll activate once, setting the state triggers appropriately.
-
One object, unlike the others, is not set to reset on activation. It will only activate once, triggering the reset object to initialize the lock. (also not pictured)
-
The state triggers at the right are S/R latches that each have their own group. When active, they shadow the button triggers so that they don't activate erroneously.
-
The buttons each trigger 3 objects, 2 of which are shadowed. The unshadowed one determines the action that will be performed: Either activating the next row, or resetting the lock.
- When the last trigger is activated, it will disable the lock, play a sound, and use an animation to clear a hole in the wall.
And that's how you make mechanisms out of the bits and bobs lying around in Voxatron! Maybe, to prove that it is Turing-Complete, I'll build.. A TURING MACHINE! Wish me luck...
I was wondering how to adjust the cartridge label and the starting level. There is a prop called 'label' that gets its own entire tab, but it does nothing, and it looks like levels start at the room where you leave them, but I'm not sure.
I'd rather not publish a level until I can figure out how they work. Could someone help?
EDIT: Oops, I clicked the Resolve button.

It was November 2011. I backed Voxatron on Humble Bundle. I was really excited. It looked so promising. I was looking forward to playing all what was promised.
Time and time again promises were broken. The release next week would be the month after next one, the release next month would be next year.
Pointless percentages on "Development" page. One man army adding unnecessary features nobody asked for never mentioned in the first pitch. Overambitious"console" design of Voxatron. For one man. And development plan straight out of Oracle or SAP; poor fit for a one person hobby project.
What ticked me off to write this post was Hololens presentation of Minecraft on E3. It's almost everything that Voxatron aspired to have. It does not have story mode, but neither Voxatron will have; and probably will not have in this decade. Voxatron is getting irrelevant really fast.
I feel that I got good fun for the money I invested in Voxatron. But I cannot help but feeling lied to when I look what all has been promised and when it was promised and what we have right now.
I have lost any illusion that Voxatron will be finished with current effort. The best thing that can happen to Voxatron right now is to get opensourced or to have a team of people take it over and work on it for few months seriously. Community may or may not recover but the game would be in finished state.

Heyo. This is R(e)Xventure. It's more shooting-oriented, less puzzle-y bits then Nightmare. You play as a sentient creature who's just awakened to the world around them; desolate, decrypt, and filled with monsters, thus setting you off to purify the world. You have two main shot types, which you can switch at certain " weapon " rooms: Flame and Spread. In addition, any other weapons (aside from a certain odd weapon) you pick up are sub weapons, in that you can use them alongside your main shot type.
!IN-WEB CONTROLS!
Q = Subweapon
E = Phantom Dash
JKIL = Shooting Analog
Space = Jump
note: flame weapon nor bullet sword are not mine.
To: ANDREW SHOULDICE (<3<3<3 Happy Birthday <3<3<3)
From: JARED COHEN, CHRIS LAVELL, ALLAN LAVELL (#LACREW #YAMCHA)
Made yesterday afternoon with the shiny new v0.1.1 release (thx zepz) for Andrew Shouldice's BYOG (Bring Your Own Game) birthday bash. Jared provided the art, Chris and I the progz + gam.
There's no win condition, vaguely thinking it could be about stopping as many ships as possible from getting past you (and you would win/lose based on a ratio or something like that). Open to suggestions.
<#
P.S. Looks like v0.1.1 carts don't run on browser yet? You'll have to DL for now.
P.P.S. Zep fix't'it

Pilot your spaceship close enough to burn your enemies with your thrusters, but try not to crash!

PICO-8 0.1.1 is now available! Grab it from the Updates page.
Note that PICO-8 is available to all Voxatron alpha users (including bundle customers). You may need to activate your account, or log in via email if you don't have a username/password already set up.
I'm doing things a little out of order here.. a full introductory post to PICO-8 will follow in a bit for those who haven't been around lately, but for now here's a rundown of new stuff in 0.1.1..
1. Gif saving! Press F9 to save the last 8 seconds (or F8 to set a starting point if you wish)
2. Token counting.
Instead of limiting cartridges to ~15k of ascii text, the primary limit is now 8192 tokens. I say primary limit, because the character count still stands, but is now 32k -- in practice the token limit is almost always reached first. There is actually also a third limit when saving cartridges -- the code must compress to the original 15k allocation. Exceeding this is extremely rare and you can probably ignore it! To get the status of your program, use the new INFO() command.
There aren't currently any cartridges that I know of that go over 8k tokens, and in general this change will give you around 20~30% more space.
[b]3. Freeform sprite and map editing






1 comment


