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
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. ;-)
13 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 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
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
I'm about to make a dozen blind assumptions based on this old Tamagotchi device, the original Digimon Digital Monsters Fighting Virtual Pet. I know very little about electronics and don't currently own one of these devices to do any tests on, so please excuse my ignorance if I'm completely wrong.
Those two metal bits on top? They're GPIO pins, essentially. If you're lucky, it's likely even 3.3 volt and won't need to be converted up or down to utilize it.
Because they're oriented vertically, the top pin will always connect to the matching top pin of the partnered device. Therefore, instead of using one pin as an input and the other as an output and just hoping the clock speeds of both devices match (which would require a horizontal pin layout so that the input pin of one device connects with the output pin of the other and vice versa), they probably use an i2c method of communication. https://learn.sparkfun.com/tutorials/i2c
Therefore, if you carefully inspect the transmissions between two of these devices (which should be simple, considering the pins are spring-loaded and would easily compensate for a wire being shoved between them), figure out which pin is the clock and which pin is the data, and what kind of data is being transmitted...
Theoretically, you should be able to develop a virtual pet on Pico-8 which can utilize the GPIO pins of a Pocket CHIP or Raspberry Pi device to fight a Digimon. And win. How cool is that? :3
4 comments
Hi all, here's a multi-player open-world shooter I'm working on, using an entity-component-system model,
I'd love feedback, and am also interested in collaborating on this game (or a new one) with anyone interested.
Thanks!
4 comments
Hello!
I am an indie designer/curator and I am curating a gaming exhibition at my local art gallery on Nov 1.
As part of the exhibition, I am building an arcade cabinet for a Pico-8 game I designed a little while ago. I'm looking for someone to help me debug and polish the game so that I can focus on refining the hardware side of things.
The game is a cheeky spin on traditional bubble shooters. I've already completed a full game loop with most of the core mechanics fully working as well. I'm looking for some help debugging, optimizing, and refining some of my collision code.
I'm willing to pay industry standard wages (I live in Canada) and I'm up to discussion for milestones and rates. The exhibition is on November 1st, so this would need to be in the next week and a half.
I will provide much more detail about the game and its architecture if you are interested! Coder will have full rights to showcase project and will be given credit in exhibition.
Please let me know if you're interested at kade67 [ at ] gmail [ dot ] com.
6 comments
