Plunder the tombs of the great Egyptian royal families - now in 3D!!
Following on from our first release, Picoh Mummy, for the Monster Mix and Match Jam #MMAMJAM, weareroad presents 3D Picoh Mummy.
Ok, yes. It is another 'mummy' game, and the concept had nothing to do with us thinking we could re-use our assets from the first game - particularly when we realised that most of them couldn't be re-used, what with that tricky extra dimension and all...
On with the show...
Fresh from his recent 2D outing, and faced with the likely economic ruin of an oncoming Brexit, our hero has turned a decided shade darker in this, his latest adventure.
[i]Released from his British Museum role due to "re-balancing of human capital", he found an outlet on the black market for the treasure of the great Pharaohs, he sold his Sam Coupé retro computer to fund a trip to Egypt, and he's off, plundering whatever isn't nailed down from the ancient tombs...
7 comments
I don't like scratch its basicly same thing as coding but in blocks, plus I suck at coding, and I want to try somthing new instead
I need help, like how hamumu.com made his games like dr lunatic supreme with cheese it has game maker without need for code.
you can also find his game on itcho
2 comments
Sorry if this is really dumb - I don't think I've seen this mentioned anywhere but happy to be corrected!
In our games so far, I've used init() to set up 'global' variables and do the one-time-only kind of stuff. But I've seen other code snippets where the same kind of initialisation stuff is done simply by having lines of code at the 'top' of the code area.
Is there a difference? I read that init() only gets called once - if it exists, does init() get called before any 'code at the top'? What is the order of this stuff? Is there a reason to use one approach over another (other than I personally think code 'at the top' looks untidy, I prefer all the init type stuff to be at the end of the file out of the way).
Obviously I could sit and play with this and 'black box' it all out, but I think that not knowing this seemingly fundamental point might indicate a basic misunderstanding of the system on my part :-D
If there's a good resource for this 'fundamentals' stuff, happy to get a pointer; my go-to at the moment is mostly the manual and the api cheat sheet.
12 comments
Controls:
[Z] Red Player/Player One Drop Bomb
[W] Yellow Player/Player Two Drop Bomb
[Arrows L/R] Select Switch Left or Right
[Arrows U/D] Toggle Switch Up or Down
How to Start a One Player Game:
First, turn on the console. When the console is on, the game number can be seen above the play field. This screen is the game select screen. Toggle the game reset switch while the game number is 1 and you will start a one player game. Have fun!
How to Play:
The player with the highest score wins. The game ends when someone scores 1000 points or misses with six bombs. If you do not hit a colored block with your bomb it is a miss. If you do not take a shot as you cross the canyon, it is a miss. The deeper the block, the higher the score. Six different game modes for one or two players.
More on Using the Console:
Hitting the game reset switch does one of two things. It either exits the game and returns to the game select screen or it will launch the currently selected game. Use the game select switch to select the game number you want to play.
With the difficulty switch in the upper position (a), you cannot shoot another bomb until it has hit something. Setting the difficulty switch to the lower position (b), you can fire again before the bomb has hit something with no penalty. The left and right difficulty switches are for player one and player two respectively.
The TV type switch gives you the option of B&W or color.
You can only shut off the console from the game select screen. The game select switch only can be toggled from the game select screen.
3 comments
menu, keys, fonts and more
Now we have lives. We can die. And we can turns off alwaysrun mode.
+some fx
7 comments
I'm having trouble getting rid of a graphical glitch in a game I'm working on.
When the player dies, the game state switches from the main gameplay screen to an intermediate screen that waits for a keypress before returning to the main gameplay screen. If that doesn't make sense, it's similar to Super Mario Bros.; when Mario dies, the main gameplay screen is replaced by a black screen that shows lives remaining, then after a short time returns to the main gameplay screen.
The glitch happens at this return to the main gameplay screen. Before the first frame is drawn, the screen flashes with what appears to be the last frame drawn to the main gameplay screen before it changed to the intermediate screen. Is this the back buffer? It seems like it shouldn't be, because I'm drawing other stuff on the intermediate screen. Is there something else that could be saving the last frame drawn?
I'm running at 60fps and using cls() at the beginning of each _draw() call. The draw operations for each game state are called from within _draw() based on the current game state.
I found the following in the manual: "If your program does not call flip before a frame is up, and a _draw() callback is not in progress, the current contents of the back buffer are copied to screen." Might this have something to do with it?
4 comments
Ima just going to put this here.
I worked on this for a little while but recently have got distracted by other things.
It is almost finished, but I was never happy with the alien patterns and I kind of got bored trying different things and tweaking configuration variables like drop rates etc. As it stands it the same thing each time, but the limited types of enemies just get harder.
It did let me try out my particle system and gave me some experience setting up a stage system (intro, game, game over). I also think I'm now settled on how I create and use inheritable classes in LUA.
Oh, and I've no idea why it's called "pigdog". I just thought of the name, and it stuck.
5 comments
| The rumour races through Petra's town: a Fony Music rep will visit at the close of 1988, handing out a record deal to the band with the fans. Meanwhile, if Johnny doesn't "shape up", his dad's gonna send him to military school. So Petra's getting the band back together. |
Hi folks, I'm very pleased to present "Signed by '89". This is my first PICO-8 game, and it ended up being quite a full cart! It's a short-form mini music management game. Hope you have as much fun playing it as I had making it.
I originally started working on this for #LOWREZJAM 2018 (that's why it's in 64x64 resolution), but the deadline sailed right on past months ago. Think of this as my very, very belated entry. ;-)
14 comments
This is a game I worked on briefly last year but ended up abandoning, I brought it out for the #gamegraveyard.
Control your ship with the arrow keys, and use your exhaust to erase the obstacles. If you collide with an obstacle the game ends.
Posting it on Twitter helped me find the game that inspired it, which is called Spout.
4 comments
Arrow Keys to Move around
X to Scramble the maze
Z to go back to the beginning or Retry
CTRL-R to restart after you reach the goal
1 comment
Important note: Due to the multi-cart nature of this game, do not use the "reset cart" menu option. All that will do is corrupt the data loaded from another cartridge and make the whole system crash.
A massively multi-cart Mario Party type of game. Currently an early proof-of-concept tech-demo type of thing and not actually "playable".
The character select can be huge because every character exists in its own "sprite blueprint" cart and gets chainloaded compressed into RAM when the game starts, followed by the game board or game mode (eg. a minigame select free-play menu) cart which drives the rest of play. The board/mode itself (and any minigames it loads into) decompress only the specific sprites they need into the active sprite sheet for use in play. Some minigames might only use the sideways character sprites because they're 2D. Some might use tiny Jelpi-style sprites for players. Some might opt to use player portraits instead of world sprites. And so on.
The sprite blueprint system supports multi-part sprites (in this case Nora's head is separated from her body in all but the portrait sprites) made of parts which are independently offset, vertically and horizontally flipped, and palette-remapped (including primary and secondary "special colors" which might be remapped for duplicate players or special events), and all that data is transferred between carts so the sprites, colors, and character names are consistently recreated.
13 comments
This is a simple shoot 'em up I made for the GBJAM6.
The game had to use only 4 colors to mimic the Game Boy style.
It's really hard and I didn't have the time to implement a good way to restart.
Controls
-Arrow keys
-X, C
7 comments
This is a lightweight particle system that can be used to simulate most particle systems.
Full instructions in the comments.
Feel free to use it in your projects, but let me know if you do - I'd love to know if it's useful!
5 comments
This is my effort at trying to make the mouse work as a joystick. Click to move.
Also it's sort of a cart I want to work on more, so it's in WIP instead of Snippets
0 comments
So I was writing some compression functions and I think I found a bug with the token parsing in PICO-8.
Here's the code:
-- entire code should be 6
-- tokens, not 49!
x = "\
34,36,93,91,1,\
33,35,94,92,1,\
29,31,36,38,1,\
91,31,98,38,1,\
29,89,36,96,1,\
91,89,98,96,1,\
35,37,92,90,0x1015.8421\
"
print(x)
|
Pico-8 claims the code size is 49 tokens, but there is just a big string here that looks like it has sub tokens. Overall size should be 6 tokens :).
3 comments
When a wish is made, a fairy is born to grant it...
Join Dynia the fairy in a grand adventure to make wishes come true! Journey across three exciting stages and battle numerous foes! Collect powerups, escape danger, and contend against mighty bosses! Remember, when suffering is eternal, hope is futile!
Circle button (Z): Start game
Cross button (X): Shoot
Directional buttons: Move
Thank you for playing!
3 comments
