itch.io

Amazing game, i love it :-). If this is some sort of testing the waters for a full game based on the Quake engine, consider the waters thoroughly tested :-P.

Thank you :-)

Hi.

So, here is a hint: consider a deck of playing cards (like in Solitaire/Patience), what number would an ace represent there? What number would three aces, placed next to each other, would represent?

If you are using Windows or DOS (in case you want to try it on an old laptop from the 90s) then you can download Petra099n.zip and run one of the executables inside. For Linux download Petra099nLinux.tar.xz. If you have a Mac download Petra099m.dmg - it is a slightly older version, but there weren't any Mac-specific changes in 0.99n anyway.

Assuming you are using the Windows/DOS archive, the executables you may want to try are:

• glpetra.exe - Windows: this will give you the OpenGL HW accelerated version
• sdlpetra.exe - Windows: this will give you the software rendering version but wont support gamepad
• gdipetra.exe - Windows: this will give you the software rendering version and supports gamepad, but it will be choppier
• d3dpetra.exe - Retro Windows: Direct3D 7 HW accelerated version for old Windows PCs
• winpetra.exe - Retro Windows: DirectDraw software rendering version for old Windows PCs
• petra.exe - Retro DOS: DOS version for old PCs

If you are not sure and just want to check out the game and your laptop is not older than 15-20 years or so, you can run glpetra.exe.

Thank you :-)

Thanks :-)

You mean the Anbernic RG-350M? Might have to do with 640x480 output, i'm not sure if SDL on it does software or hardware scaling (the game requests 320x240 mode).

I haven't implemented joystick/gamepad support in the SDL versions - i might do that at some point. Though the engine itself doesn't really "know" about gamepad (originally the game was written for DOS with keyboard-only input), the versions that have support for gamepad simply generate fake key events, so it wouldn't be that different from using the D-PAD. But i might try it anyway in a later version.

Thanks :-). I just realized i do not have a short description set :-P.

Hi and thank you :-).

Hi! I just finished watching the steam video :-).

About the code, basically it is a failure to provide good feedback on my end - the result of making stuff up as i go i guess. Someone wrote that it looks like Tomb Raider - initially i was planning to make a TR-like platformer but making those animations took time and as you noticed, controls are a bit janky... so i just started adding more and more puzzles instead :-P.

Your initial guesses were actually right, it is just that there wasn't any feedback about what to do about the middle number.

Since itch.io doesn't seem to have a way to mark spoilers, i'll give you a hint on what to do: go "at" the book's title (the "at" was intentional :-P) and use the action button. And now i guess you can see what i mean with failing to provide good feedback... there should have been a way to tell when you can interact with something (the same applies with the bookcases - only those in the room are interactive). But i thought of that too late (i made that room near the end of the deadline).

But this is basically a half-baked 3D platforming engine forced to become an adventure game engine mid-development :-P. Anyway, i can tell you the full code if you want, just send me a mail at badsector -at- runtimeterror -dot- com :-).

About some other things. The game didn't crash the first time, from what i can see in ~33:50 when you opened the inventory you had the Quit button highlighted and i guess you pressed Enter or Space which activated it. This is something i pretty much added the last moment (i was killing DOSBox or pressing Alt+F4 for most of the development to exit the game) and the UI system was hacked quickly together in an afternoon, which is why it doesn't have any confirmation popup... or why the note disk text sometimes reads in a weird way (there is no scrolling nor word wrapping so i was trying to fit the text in the few lines and characters as if it was Twitter :-P).

The sound was a bit choppy... my guess is the K6 you use wasn't fast enough. It'll sound counterintuitive but the software version (WINPETRA.EXE) might work better - i've only written the D3D code recently and only tried it on my 1GHz P3 machine whereas i tried the software renderer on weaker machines and optimized it a bit more.

About DOS not having audio and DMA issues: Soundblaster has two DMA types, low DMA and high DMA. The low DMA was there from the beginning but only supports mono audio whereas the high DMA was introduced in SB16 and supports stereo. Post Apocalyptic Petra requires SB16 to do stereo so it uses only the high DMA. Your sound card probably doesn't support the high DMA mode, which is why you get that. There might be a way to get stereo audio out of low DMA-only SB compatible cards because it sounds weird to me that these cards forced DOS games to be mono. Then again, i guess by the time they were new most people used Win9x and DOS support wasn't much of a concern. I might check that out at some point.

Does it do anything if you press space? It might take a bit to load the data (though the latest version should display a message when it is loading, are you using 0.99f?).

I'll upload a video later.

Well, it is minesweeper and i tend to suck at this game :-P. I like the "A E S T H E T I C" though :-).

I like the ASCII first person graphics (and nice detail with the shadows) but couldn't figure out a single riddle :-P. Are the hints in the gameworld? I tried to enter most places but only one was open and was empty. Also tried 'search' all over the place but couldn't seem to find anything.

A nice take on the match-3 genre. Initially the controls felt a bit weird and took me a while to realize that i can only match circles at the row the cursor is at (i had matches above the cursor and thought the matching was broken) but after i figured out how to play it was a nice challenge.

My only two issues are that the controls feel a bit stiff - there is a slight delay between pressing the keys and the items sliding - and... the white background is a bit tiring to the eyes :-P

Looks good and i liked the intro. Needs some work into the feedback, it took me a bit to realize that the white bars were a countdown to the next action and the blue bars were preparing for attack.

I managed to play a few rounds until the moment i came against three enemies, which quickly wiped out Kuro and then Sayori (since there wasn't anyone to heal her). I *think* it might be a bit unbalanced there in that i was wiping the floor with everyone up to that point.

I think that if you stick with the combat-only approach (ie. there wont be any sort of city exploration) you should add at least some sort of randomized item drops that can help in case Kuro dies because otherwise after the healer dies there is nothing you can really do. Also perhaps the earlier monsters should be a bit more difficult? Up until the moment three monsters appeared it was very aasy.

I couldn't get past 'Choices' :-/

Nice idea and i like the graphics and especially the music. This is the sort of game i can see myself finding in a gaming magazine cover CD  and playing as a kid for hours on my 386 :-).

I liked the intro story :-P

Gameplay-wise i think the shotgun's reload time is too long for the spawn rate of the enemies. Also it'd be nice if there was some way to  'pick up' health (like shooting a health thingie or whatever :-P).

I really liked the music on this. I want to try it on my IBM PC at some point (it is stored in a few boxes now so i can't at the moment) and see how it looks and sounds on a real CGA monitor and IBM PC speaker :-).

I played a few rounds though i'm usually getting killed by the AI. I haven't figured out how the AI works yet :-P (does it "look" at what you typed as if it was someone standing over your shoulder playing a 2 player game on the same machine and tries similar numbers?)

I think the handling needs a bit work since i always collide with the sides (i think it needs a bit more force when turning left/right). Also the physics seem to be affected by the framerate - i get wobbling at 25 fps, stuck at 300+ fps (when i run the windows version) and weirdly enough it feels most responsive and stable at 9 fps (running in high resolution) :-P.

Graphically it is impressive and i really like the music. I think it needs a bit more on the gameplay side though - even if it was something as simple as obstacle avoidance (with the appropriate widening of the track). I'd like to see more levels or perhaps a random track generator?

This looks very good, though i couldn't navigate and at some point i got stuck between a pole and a wall and no matter how much i tried, i was always getting pushed around :-/. Also initially i expected to see some people where i was supposed to go and didn't notice the huge flashing rectangle at the ground :-P

Was it inspired by Quarantine btw? Both the theme and the graphics look kinda like it.

It seems to only work in DOSBox 0.74.

I like the idea (though the movement felt a bit slow) and having the display be a rough map of what is actually there (it kinda reminds me of Thief's "rough" hand-drawn maps and i guess such an idea could be explored more). I think having a bit of more randomization would help. Are there only two levels? After beating the first level i had the second level repeat, though it looks largely the same as the first minus the cameras (...wouldn't that make more sense as the second level? :-P) and i think some bushes are moved differently but it looks largely the same.

In general i found it a very cool idea, even though i'm not really into stealth games  :-).

I had a game like that on my Atari as a kid. Later i learned about the Tron movie :-P. Sadly i can't *really* try it since it requires at least two players - it'd be nice if there was some simple AI for single player.

Regardles, what i really liked was the single-pixel-width vector graphics (i guess they are vector? They do look like vectors) and the overall aesthetic, though i think the game "board" (the screen where you are playing the game) could use some graphics too.

It'd be nice if it had some sound too, even if it was some PC speaker "brrrrt" sound :-P

I suck at asteroids :-P. I managed to get to level 5 but i was out of lives by that point and lost almost as soon as that huge blob exploded to lots of tiny blobs (because i had a stream of bullets towards it so i got a few splits almost immediatelly).

I like the handwriting graphics, though as others mentioned it'd be nice if it had a tiny bit of sound. Also i liked the antialiased lines used for the ship and lives. And, i'm sure it wasn't intentional, but the amber scheme reminded me of my first PC's CRT :-P.

I noticed that there is also mouse input, but i couldn't figure out how to control with the mouse (it seemed to rotate arbitrarily) so i only used the keyboard.

Hey, the issue you describe seems to be a bug with DOSBox 0.74. A more recent build from SVN orDOSBox-X should work fine.

Looks nice, but can you add a download option? I'd rather not install a web browser plugin.

Nice idea :-). My only suggestion is that it could have been slightly better if i had to use the cursor keys for something else than changing my course (calibrating stuff or whatever :-P) and see me falling in the background from first person.

Actually that might be a nice idea for a mini game in Occulus Rift - feel like falling from a skyscraper and try to hack your conscience with using the computer in your HUD/glasses :-P

Can you add a download option? I'd rather not install a browser plugin.

Looks nice, but do they ever stop? Or is there a way to replenish health?

I actually coded that on Windows 3.1 which had only a VGA driver, hence the low color count :-).

Implemented some initial audio code in the engine. The engine side was very simple, took only about four hours to write it, but the editor side took me some days (although tbh i did procrastinate a bit there :-P). Here is a video with some placeholder sounds and music:

In the video you can also see some other minor improvements, like loading decals from the world editor as i mentioned in my previous post (the big vertical banner things are decals placed in the editor - the editor also calculates lighting for them, although in this map it isn't very visible).

I still haven't implemented 3D audio playback. The API and script hooks are there, i just need to feed the 3D position for the listener to the sound mixer and update the mixing code to do panning based on that position.

I added decals and decided to stress it out a bit by leaving a blood of trail as i walk around:

Decals are basically done from the engine side, except that i need to write the code for importing them from the world files so manually placed decals will show up in the world (which should help to enrich a bit the environments with dirt, cracks, foliage, debris, etc). The editor needs to make decal manipulation a bit easier, but nothing big.

After that the next is making the enemies fire back. Yeah, i know that i wrote above that i'd work on this next :-P, but after having blood puffs in the world disappear i wanted shooting and killing enemies to leave something more permanent (after making the video i made the enemies spray blood in nearby walls when you shoot them :-P).

My immediate ToDo list for the game from a programm PoV is basically:

• Game menu and HUD (the engine side is done and i'll use parts of another project of mine for the scripting side)
• Weapons system (monster and player weapons) and monsters fighting back
• Pick up items (ammo, weapons, health - these need both HUD and weapons system)
• Doors and lifts with lockable versions and keys to unlock them
• Dialogs (the game wont be big on that but there'll be a couple of places where people will talk to you)
• Save/load

The engine side needs some stuff too:

• Import decals from the world file
• Add support for audio resources (the engine has no audio code at all at the moment)
• Ambient audio playback
• 3D audio playback
• Support for save/load (will need GUID generation from the editor)

Finally the editor needs:

• Better decal manipulation
• Finish the undo/redo code (not everything is undoable at the moment)
• Generate and retain GUIDs for entities so that saves can be implemented in a forward compatible way

From the content side i need to basically do everything since almost all of the existing assets are placeholders. I did some tests for level layout (the video shows one), but i need to have enough of the gameplay bits working before thinking more seriously about the level design.

And as for the models and textures, i still haven't decided 100% how exactly things will look (at least beyond the main character).

It has been a while since my last post, which makes sense since for more than a month i didn't touch the game much (worked on some other stuff and then i was messing with Vulkan a bit :-P). Then i started doing some things that do not really show in images or videos so i decided to wait until i had something to show again.

Lately i decided to put some animations in the game - up until now everything was static. The engine has code for animations, but i never actually properly tested that beyond a quick test almost four years ago when i wrote the code :-P. However it turns out it worked almost fine from the get go (although i need to work on transitions). After that i also worked on the gameplay side on NPCs that chase you and you shooting and killing them. Here is a video from a couple of days ago:

Like i mentioned before, all assets are placeholders - the enemies use the same model as the player's model with a swapped texture.

Previously to create the models in a format that the engine understood i used a command line tool i wrote that parsed a script which described how to convert the model from OBJ files i exported from Blender. That was a bit tedious and error prone, so i decided to write a new tool for editing the models:

This tool keeps all models of the game in a single "project file" and generates the .rtm (model files), .rtt (texture files) and .lil (script files) that the engine needs to use the models. Strictly speaking the script files aren't needed, but the engine doesn't know about different animations, it only knows about which frames to playback which is set up via scripts. The generated script allows any other script to apply an animation to a model by calling a single function. For example to apply the animation walk of the don2 model to an entity ent, the call would be apply_don2_anim_walk $ent. Although this isn't exactly what the script for a monster/npc would call since it is wrapped with some other helper functions that keep the current animation state, etc.

Although the game will be top down, i added a behind the back camera some time ago and it shows how silly the current model looks like:

This was before i replaced the monsters and implemented chasing.

Another thing i worked on was building the game. Since my last post i switched back to Windows (i want to play more games :-P) but wanted to keep using the previous cross compiling setup. To do that, i installed a fresh copy of 64bit Debian into a QEMU image and recreated the native compiler setup for 32bit and 64bit Linux binaries and cross-compiler setup for 32bit Win32 binaries and 32bit and 64bit OS X binaries. Then i made the Debian automatically login to the default user and gave the user sudo access without asking for a password. Then i modified the .profile script that is automatically executed at startup to download a "package.zip" file using QEMU's TFTP server which gives access to a local folder, uncompress it to the home folder and execute a shell script in it. After i had all done, i wrote a batch file that created said package.zip file on the Windows side with the latest engine source code and data files of the game and placed a shell script to be executed from inside QEMU that builds the engine for Linux 32 bit and 64bit, OS X 32 bit and 64 bit and Windows 32 bit and packages the game and files into an archive. Then it copies the archive file to a freshly created QEMU image and shuts down Debian, which causes QEMU to exit. The batch file creates the blank QEMU image, calls QEMU, which downloads the "package.zip", builds the game and places to the newly created image and then shuts down QEMU. After QEMU is shut down, the batch file uses 7zip to extract the contents of the QEMU image to get the 7zip file and places it in a special folder that i can then distribute.

The above process basically allows me to create fresh builds for Windows, Linux and OS X with a single double click which is great for copying it to different test machines i have, giving it to others to test and of course archiving the progress of the game.

Sadly there is a negative here (well, beyond that builds take 10 times more than they would under a native Linux). The MinGW version i'm using seems to have a bug which is why the particle bug i mentioned above exists. Right now i have to replace the generated Win32 exe with something else manually since there isn't a newer version of MinGW on Debian that fixes it yet, but eventually i'll either try to manually build a newer version of the compiler or try to use a different compiler for creating the Windows version of the game.

What comes next is writing a "weapon" system into the game so that the main character and enemies can use different guns. Also i need to fix a few bugs with the chasing code (especially the code that turns enemies towards you which sometimes can cause them to fly... :-P).

You can download the latest build from here (753KB). It contains executables for Windows, Linux (both 32bit and 64bit) and OS X.

FWIW it seems to be fixed now (i didn't do the cache/cookie deletion thing because i didn't want to lose existing sessions in other sites).

The SteamSpy guy seems to disagree with your comments about early access though, or at least the bits about popular genres in early access (FPS and rogue-like are far from popular if you check the tag cloud - fortunately for you, Survival seems more popular than both of these :-P) and there isn't really a "second launch". He wrote about it before too, but this article has the data to prove it - with the caveat that if you failed your first launch you *might* do better in the real one. I think you should wait until some time after you release your game to decide if it was a good idea or not :-P.

Personally i do not plan on using early access because, well, i don't like promising things while i'm taking money, mostly because i might not finish them :-P. Also i don't think it would make any difference if i built a community in early access stage vs in finished stage, if anything i'd expect the latter to be easier because people will see the final game not the patches, stitches and standins in the wip version.

And above all, i wont have whiny people complaining that i exited early access to early :-P

For some reason i cannot see the second page (or any page after the first) of the Devlogs subforum. Every other subforum that has more than one page works fine, but when i clock on the devlogs' "Next page" link i get a "There was an error with your request".

I am using Firefox 42 if that helps. The URL the forum tries to open via that link when it fails for me is "https://itch.io/board/10021/devlogs?before=297"

I worked on the Mac OS X backend... or more precisely, i rewrote the Mac OS X backend from scratch. This was done to remove the Xcode dependency - everything is now built from a Makefile. This also made the OS X code *much* smaller (only a couple of files instead of a bunch of resources, files, classes, etc generated by Xcode) and fixed a couple of issues i had. Also implemented fullscreen mode (although it doesn't change resolution yet) and, most importantly, raw mouse input. I think my engine is one of the few engines on Mac OS X to do raw mouse input since a lot of games seem to be affected by mouse acceleration. This was done by registering a callback with the HID API introduced in OS X 10.5 (and is very badly documented - probably why many people miss it) and checking for mouse motion events there (the button press and release events are still done in the regular event loop).

Another thing that i managed to do today was to setup cross-compiling for OS X from Linux, so now with a single script under Linux i can make builds for Linux, Windows and Mac OS X (32 and 64 bit for all except Windows which only has 32 bit builds since Windows has good 32-on-64 bit support). The .tar.xz i updated in the original post was made using this script. This was also the reason i wanted to remove the Xcode dependency. I used the osxcross project to build the crosscompiler (i also had to build a recent version of Clang because the one bundled with Debian Jessy is too old to be used with the latest OS X SDK).

I also added a cvar to limit the framerate. Can be helpful if you are near the 60fps that the engine updates (e.g you get 70 or 80fps) at and it doesn't feel smooth. It can be enabled with enabling the console with ~ and typing cset fpslimit 60 (or any other value). Alternatively enabling vsync might help, although the only OS so far i've seen vsync to feel good is OS X (where it feels almost perfect). I'll need to investigate that.

Game-wise there seems to be a bug with the particles not spawning in some cases in the Windows version when it is run under Windows (ie. it doesn't happen under Wine). Those are always fun to debug :-/.

Hi all, i'm working on a 3D top down shooter. The gameplay is mostly inspired by Raven's old Take No Prisoners game (ie. top down shooter with FPS-like controls). I haven't yet decided on a name, so i'm just calling it "vamp" (from vampire, see below why). The game is currently in early stages with placeholder art and there isn't much of gameplay yet, but... well, i wanted to share :-P.

Here is a screenshot from the game and the editor (the shots are from Linux, i use a classic windows-like theme for XFCE and GTK2):

Also here is a video i took from the engine today after i added a console:

The editor is brush-based, like Hammer and Radiant (although it has negative brushes which makes things a little easier when making indoor stuff) and it actually has a similar workflow to Hammer (although it is a bit easier to use). Like with Hammer and Source (or Quake and Radiant), the editor and the engine are fully separate and in fact i started writing the editor about three years prior to the engine (for another engine) :-P.

The engine is a simple engine written in C and uses my LIL scripting language (which is similar to Tcl). The console commands you see in the video above are the same commands which are used in the game scripts (the engine is script driven). It works under Windows, Linux and OS X with native backends for each (except Linux where it uses SDL 1.2 - that is because when i started the engine SDL 2 was still in beta, but eventually i'll port it to SDL 2) and has an OpenGL 1.x backend (it even works on an old Pentium 3 with an integrated Intel i850 GPU i have here :-P). There is also some code for iOS and Android with an OpenGL ES 1.x backend, but the code for those hasn't been updated in years and doesn't work. Finally at some point i also made an Emscripten build (using Emscripten's OpenGL 1.x layer) which worked ok-ish, but it was more for the "hack value" than something practical.

About the game itself... as i wrote, it is a top down 3D shooter (for debugging purposes i can also switch to first person perspective - as shown in the video above - but the final game will be top down only). Story-wise things aren't really finalized, when i started i had the idea that you were a vampire hunter storming a castle where vampires and other creatures live and prey on the nearby villages. The idea was that you'd be a Van Helsing-like character (like in the 2004 movie), shooting creatures in gothic-like castles.

Then the Incredible Adventures of Van Helsing happened :-P (actually it happened earlier, i just noticed it some months after it was released on Steam)

Now, the game isn't *exactly* like the adventures of Van Helsing, but still it is a top down shooter (even if mine has FPS-like controls and Van Helsin has twin-stick controls) and the theme was *too* close. So i decided to scrap that theme idea and go with something else.

And this something else is about a tormented character, bound to a higher being, put in a battle between two demonic factions. The game will chronicle your relationship with your captor, who groomed you as a killing machine and uses you as a weapon against the opposite faction. Style-wise the game will have a visual style similar to Gungrave on the PS2 (i'm talking about the "drawn" texture style mostly... and besides, remember, this is top-down shooter :-P).

So far that is the plan anyway :-). If it wasn't already obvious, at the moment i'm more focusing on the gameplay with the visuals and story taking a back seat for until i actually have things screaming, bleeding (well, they already do... but they don't react to that :-P), attacking you and dying (both them and you) :-P. The screaming bit (not literally), specifically, would be a bit somewhat tricky to do since the engine doesn't have yet any sound code beyond stubs to be filled later.

Generally what still needs to be done is most of the gameplay code, all the assets (right now they are placeholders) like world textures, models, animations, sounds, music (although i'm not sure yet if i'll actually have background music or i'll only do ambient sounds) and of course the levels. What is done is the engine (mostly, some bits are missing but those aren't big deals), editor (mostly) and some gameplay code. What i'm working on now is the core gameplay code (ie. what you'll do in a level) and next i'll try to start experimenting with the visual style (i mean, i want to make it look similar to Gungrave, but that doesn't mean i can actually do it :-P the only two styles i know i can kind of do is oldschool Quake 1-like graphics and still oldschool N64-like graphics :-P) and try to make a single small level that will play close to what i think the final game will be - something like a vertical slice of sorts (minus sounds).

If you want to check it as it is now (note: might crash and burn), you can download (link removed, see below). This contains executables for Windows and Linux (32bit and 64bit). The vamp.exe file is a launcher for Windows and the vamp.sh script is a launcher for Linux. The launcher will be eventually rewritten to also work in Linux and allow key rebinding without launching an external editor (currently all it does is to open notepad with the input.lil script file that contains the key binding commands). Under Windows all you need is working OpenGL drivers. Under Linux you need OpenGL drivers and SDL 1.2 (for debian you need the libsdl1.2debian package).

New executable (December 4, 2015): here it is (760K). It now contains Windows, Linux and Mac OS X executables.

Newer executable (March 5, 2016): here is that too (753K). Like above it contains versions for WIndows, Linux and OS X. Read below for the changes.