itch.io

We don’t merge stuff from Naev anymore, no, and I would say it’s much less buggy than Naev. We try to test things pretty thoroughly before pushing out a release, and while some small bugs may of course slip thru the cracks, we’ve not so far had anything as extreme as save file corruption. (Of course, that’s assuming you don’t have faulty or fraudulent storage media, e.g. an SSD or SD card that lies about its capacity, but that would be a hardware issue if you did.)

If you do give it a try, I would appreciate it if you let us know what you think! 🙂 It’s actually quite different from Naev in many ways and we’ve been trying to develop it in a different, hopefully better direction than its former upstream project.

Awesome, that’s great! I just gave it a try and it’s very very nice with these changes.

I think this is a nice idea, and it’s clear you put a lot of effort into this, but I have a couple of complaints that render this unplayable:

1. There’s no run button. It seems to me that you’re using the same physics as SuperTux Milestone 1 to a T, but with the run button constantly held down. It’s possible to do good plantforming physics without a run button (I did so in my game, ReTux), but with such fast acceleration, some sort of fine speed control is needed. If you want to go the no run button route, might I suggest a sneak button instead?
2. There’s a severe bug or design oversight where when you hit a pair of blocks, only the one furthest to the right registers as hit or punched or whatever. It’s rather annoying and unintuitive to have to be so far to the left in order to get what’s inside of a block.

If you fix these two problems, I think this will be rather nice game.

🦇

So just to follow up, I just finished implementing a combat practice mission which will be included in version 0.4.0 when it comes out. It’ll also be available in the nightly soon.

Also, I just noticed your edit! Sorry about that. Ash is adjacent to Tuoladis, which is north of Doranthex. You not being able to find it raises an interesting point that there should probably be a map showing all the waste disposal locations, especially because two of them (including Ash) aren’t adjacent to inhabited systems. I’ll add such a map for version 0.4.0, probably a bit later today since it’s an easy thing to do.

🦇

That’s a good idea! It might also be a good idea to allow customized freeform combat practice of that nature whenever the player wants, could help not only with learning combat mechanics but also with testing ship builds. Will definitely have to look into that idea when I get back home. 🙂

🦇

Well there’s quite a lot to the point that listing the similarities would probably be easier than listing the differences. The version 0.1.0 release notes list a bunch of noteworthy differences compared to Naev ~0.8:

https://diligentcircle.itch.io/naikari/devlog/344951/naikari-010

Of course, though, Naev 0.8 isn’t the latest Naev release, and if you compare Naikari to the latest Naev release, it’s pretty clear that Naev has moved in quite a different direction, in particular introducing more and more RPG-like elements, completely changing the balance of the game, and adding things that, to my mind, amount to feature creep (like the stealth system and the visual novel interface). Naikari is deliberately eschewing a lot of that, and developing from what was roughly Naev 0.8 (actually slightly before 0.8) in a different way.

Since the point of Naikari is really where we’re taking it, I think it’s more useful to describe how our approach differs to Naev’s approach than to enumerate exact differences. In particular:

• Less focus on flashy new features, more focus on using what we already have effectively. For example, we continue to use simple text-based dialog boxes for story, rather than Naev’s visual novel interface; it’s simple and elegant, and we don’t think a miniature visual novel belongs in this kind of game.
• Focusing on making a solid space trading and mercenary sandbox game, rather than trying to make an RPG and incorporating random elements from external genres. For example, we’ve put a lot of focus on generic missions over the years and actually created the modern bounty hunting and patrol missions (which were originally locked behind story parts years ago in Naev). For Naikari, we’ve also created a new generic mission already, the Love Train mission.
• Carefully balancing and testing the game, working to ensure that all ships have a purpose and that traveling throughout the galaxy and earning credits isn’t a frustrating or tedious experience. For example, we changed the way ships jump in so that that getting ambushed and blown up by a new ship while you’re trying to jump out almost never happens.
• Ensuring the interface is as smooth and easy to learn as possible. For example, we made improvements to the aiming lines and turned both those and “fire only in range” on by default, and we added indications showing exactly what services in a system are available and which are restricted.
• Focusing on accessibility. For example, we were originally the driving force behind colorblind accessibility in Naev, and we continue to do our best to ensure colorblind accessibility in Naikari. For Naikari, we also introduced a game speed slider, to more effectively assist those with disabilities affecting motor skills, or who otherwise have difficulty with the game’s speed, than the “slow mode” we had introduced into Naev previously. We’ve also been working to improve the early game experience for newcomers. (Side note, this isn’t something we’re doing per se – rather, something we’re not doing – but Naev is really hurting its accessibility with things like distracting animations above textboxes and that horrible damage effect that gives me a headache and I can only assume must be a photosensitive epilepsy trigger.)

Hopefully that gives an okay idea of what distinguishes Naikari from Naev. Feel free to ask if you have any further questions. 🙂

Yep, indeed it is! We were one of Naev’s most active contributors for several years and started to have major disagreements with Naev’s lead developer over what direction the development should take, so Naikari is us taking the game’s development in the direction we want it to go. 🙂

Yes, ~/.local/share/retux is right (specifically save_slots.json). Of course, configuration is separately stored in ~/.config/retux.

Do you mean one of these?

https://diligentcircle.itch.io/pacewar/download/GWHt9A6ZTmbMhoVRRndWwR5pvVIpAURzQwzAxIM4

If so let me know if you got it or if someone else “claimed” it before you could. I assume no one will since activity here is low, but if that does happen I can send it to you some other way (I don’t see a system for DMs but you can let me know how).

This is all new to me. 😅

I’m not sure I understand what you mean. This is a free game, so no key is required; you can download it already. The same goes for GameJolt, another platform this game can be found on.

I think I recall the Desura bundle you’re talking about but that was something someone else was doing and that we just said we were ok with (since Pacewar, like all of our games, is open source). We provided them with a bunch of Desura keys or something so they could give them away. Other than that we had no involvement in that.

Hm… DLL errors are hard from my end. There’s a whole lot that could’ve went wrong and I both have very little familiarity with Windows and create the Windows binary in Wine. And there’s always the possibility that cx_Freeze or Pygame is at fault, which I have no idea how to test. I kinda wish PyInstaller worked in Wine, that seems in general to work way more easily. :/

Regarding this problem for you specifically, I think my best suggestion is if you still have this after making sure you have the Microsoft Visual C++ redistributable runtime installed, just run the game from source code instead. To do this, you’ll have to install the latest version of Python, download the ReTux source code, run the following command in Command Prompt (you may need administrator privileges for this step):

python -m pip install pygame sge uniseg xsge_gui xsge_gui xsge_lighting xsge_path xsge_physics xsge_tiled

More broadly, we’ll look into our freezing methods when we release a new ReTux update soon. Maybe it’ll produce a Windows binary that works better.

🕵️

Yes. 🙂 Hexoshi is also receiving further attention, though I’ve been working on Naev stuff so much that I haven’t gotten to actually doing anything in a while. 😅 It’s like I want to do everything at once now.

🕵️

Oops! Thanks for pointing this out. It’s fixed now.

🕵️

The warning seems, from a quick search, to mean that you need to install the libasound plugins.

But that's not likely the cause of your crash. The crash is probably because of a compatibility problem between my GNU/Linux binaries (which are built on gNewSense) and OpenSUSE. I would recommend using the source code distribution in that case. It's not difficult to set up; just install Python and Pygame, and everything else is included.

If you want to see the errors that occurred, you can use get_errors.py, or just find stderr.txt in ~/.config/retux.

So it's not just me then. Thank you; perhaps a bug report should be made to the PyInstaller developers.

To be clear, the binary *does* work... with older distros. I don't know for sure what is, but something about newer distros (including mine, Ubuntu 16.04) prevents any binary made by the development version of PyInstaller from working (though I think the stable version is unaffected). Even a simple Hello World script segfaults in the same way. I'll do some tests and make the bug report, and if/when the problem is resolved, I'll rebuild ReTux (and the other two games I've built with PyInstaller).

In the meantime, I recommend using the plain source code. It works out-of-the-box as long as you have Python and Pygame installed.

Yes, it would be possible. I actually chose that position so that it would be possible to add a second player (for split-screen co-op), but just didn't end up doing that.

I don't think it's worth it to make a new release for this change (especially since there's still a chance I might add 2-player in the future, though unlikely, and I don't see the additional use of vertical space as harmful), but if you would like the change, you can replace these lines in retux.py (around line 530):

text = "{}\n{}\n\n{}\n{}".format(
_("Score"), score_text,
_("Time Bonus") if time_bonus >= 0 else _("Time Penalty"),
abs(time_bonus))
sge.game.project_text(font, text, sge.game.width / 2, 0,
color=sge.gfx.Color("white"),
halign="center")

with these new lines:

text = "{}\n{}".format(_("Score"), score_text)
sge.game.project_text(font, text, sge.game.width / 2, 0, color=sge.gfx.Color("white"), halign="center")
text = "{}\n{}".format(_("Time Bonus") if time_bonus >= 0 else _("Time Penalty"), abs(time_bonus))
sge.game.project_text(font, text, sge.game.width, 0, color=sge.gfx.Color("white"), halign="right")

The download links here are all messed up. The one labeled as 32-bit Windows points to 64-bit Windows, the one labeled as 64-bit Windows points to OS X, and the one labeled to OS X points to what looks like source code. Could you fix this, please?