You can grab nightly releases on the nightly release page, which is automatically rebuilt at roughly UTC 09:00 every day. Note that this build is likely to contain some bugs and save files may break in between nightlies.
As Naikari is not digitally signed and notarized or on the Mac App Store, you will receive this error.
Please refer to the following Apple Support Article (HT202491) to allow you to run Naikari.
Some Windows sound drivers don't provide OpenAL. If you have no sound, download and install OpenAL from here.
This almost always means that your hardware doesn't support a recent enough version of OpenGL. Naikari requires OpenGL 3.1 or later to work; for reference, the oldest Intel integrated graphics controllers which support OpenGL 3.1 or later are Intel HD 2000 and Intel HD 3000 (of the Sandy Bridge micro-architecture, first released in 2011). On Linux, you can confirm what OpenGL version your system supports by using glxinfo, e.g.:
glxinfo | grep OpenGL | grep versionIf you have a graphics controller or graphics card which doesn't support at least OpenGL 3.1, you unfortunately will not be able to run Naikari. Depending on your machine, you may be able to get around this by getting a graphics card which supports OpenGL 3.1 or later. Even fairly old graphics cards should suffice.
Other than that, if anyone would be willing to contribute a compatibility option so that Naikari can run on OpenGL 2.1, please get in contact with us.
While not ideal, on Linux, you can run Naikari in software mode if absolutely necessary by setting the LIBGL_ALWAYS_SOFTWARE environment variable to true:
LIBGL_ALWAYS_SOFTWARE=true ./naikari-0.10.0.AppImageIt's plausible that this method could also resolve hardware compatibility issues, but we can't guarantee this.
SDL doesn't use its Wayland video driver by default, but Naikari may require the Wayland video driver when run in a Wayland environment, depending on your distro and/or setup (we don't know exactly what factors cause the problem). The reason for the X11 driver being the default is a bit complicated, but explained in the commit that reverted the change that would have made the Wayland video driver the default (libsdl-org/SDL@254fcc9). SDL 2.0.22 has a mechanism in place to define Wayland as preferred, which should theoretically solve the issue, but older SDL versions will continue to be in use for some time, so that solution is not feasible for official builds in the short-term. In the long-term, we suspect this issue will go away on its own as things mature on the Wayland front.
For now, if Naikari will not start up for you because you are using Wayland, you can fix the problem by setting the SDL_VIDEODRIVER environment variable to wayland, e.g.:
SDL_VIDEODRIVER=wayland ./naikari-0.1.0.AppImageThis should work, though colors may be distorted depending on your system; you can correct this by adjusting gamma in the Options menu if it occurs.
"Naikari" was picked as a portmantô of the Japanese words ない ("Nai" – is not) and 光 ("Hikari" – light).
In short, the reason for the fork is irreconcilable disagreements with Naev's lead developer over the direction the project should go and what kind of game it should be. Naikari is simply us continuing the same work we were doing for Naev previously.
That's a difficult question to answer because Naikari doesn't define itself in relation to the current Naev project. Naikari's only relation to Naev is past versions. In fact, Naikari is so different from current Naev versions that there are significant API incompatibilities between the two.
The most significant difference between Naev and Naikari is what each project's intention is. In our years contributing to the Naev project, we never actually learned what exactly Naev's design direction is supposed to be, but what we do know is that it's modeled after Escape Velocity, just like Endless Sky is, and that Naev's lead developer doesn't seem to take Naev's writing all that seriously.
Naikari, on the other hand, isn't based on Escape Velocity at all, and we haven't even played Escape Velocity before. It's of course indirectly influenced by Escape Velocity, but our actual intention for Naikari is for it to be a freeform mystery game, with writing similar to something like Star Control 2 (The Ur-Quan Masters) or The Expanse. We've been transforming Naev's Escape Velocity derived system into something of a hybrid between Endless Sky and Starsector, and the intention is to then use that (which is intended to be a solid freeform space trading and mercenary core gameplay loop) to deliver a compelling mystery.
These differing design philosophies lead to a number of significant differences between the two games (as of Naikari 0.11):
- Where Naev uses measures like standing caps, "chapters", and withholding ships and weapons to force progression thru the storyline, Naikari doesn't contain any such restrictions on gameplay. If you wanted to, you could entirely ignore Naikari's story and still have access to high-end ships and weapons. We prefer a more natural story progression system, more similar to what Star Control II does.
- In our quest to embrace the larger systems inherited from Naev while fixing its problems, Naikari's combat system has been substantially overhauled. Weapon ranges are much longer, and bounties are awarded automatically as a reward for winning battles.
- Taking a page from Starsector, we've been making spontaneous system events more common in Naikari to make the large systems more interesting.
- Where Naev opens with an opaque tutorial and sends the player wandering, Naikari instead begins by leading the player into a questline which naturally teaches how to play (via what's known as a hidden tutorial) within a mystery plot about the expansion of pirate activity.
Other than that, Naikari has gotten a lot of polish from us ever since we started the project. Polish isn't especially flashy or headline-grabbing, but it's important for cultivation of an enjoyable experience in any game. Some examples of polish include overhauls to the interface, a decluttered news feed, a clearer "radar range" system, improved distribution of outfits thruout the universe, and much fewer "dead-end" systems.
No.
When we (Diligent Circle, Naikari's lead developer) started this project, we initially attempted to continue collaborating with the Naev project. This naturally gradually decreased over time as the projects diverged and the two projects became less and less compatible, but we entirely ceased submitting pull requests when in Naev PR #1801, Naev's lead developer, bobbens, accused us of taking a "narrow and egotistical view of open-source development", not acting in good faith, and "knowingly" risking "introducing bugs to Naev". All of these accusations were in response to a sentence we included in the PR which stated that the bug the PR was fixing may have not covered cases that weren't shared between the two projects.
After this, we continued to participate in some discussions on Naev's issue tracker and Discord server, but were banned both from Naev's GitHub page and from Naev's Discord server for our posts under Naev Issue #2062 expressing disagreement over sound design. The reason we were banned wasn't for any actual violation of Naev's Code of Conduct; rather, bobbens claimed that our "insistence" was "toxic" and ordered us to "refrain from non-productive discussion". When we responded to that by complaining that bobbens was actually in violation of his own Code of Conduct, he blocked us from Naev's GitHub page, indicating said response as his reasoning. A few moments later, he also banned us from the Naev Discord server.
Given our experience with Naev's lead developer, bobbens, which is succinctly summarized by our final interaction with him in Issue #2062, even if we're unbanned from Naev's GitHub page and Discord server, we have no further intention of collaborating with him.
In short, no. Naikari is designed in such a way that the rate of passage of time is routinely adjusted as a part of its normal gameplay. This makes any sort of multiplayer impractical without completely redesigning the game. Endless Sky, whose design is somewhat similar to Naikari's, is likely more suited to being turned into a multiplayer game than Naikari ever will be.
That said, if someone wants to implement it, we are not opposed to accepting a contribution adding either a sort of cooperative gameplay with additional players piloting escort ships, or a sort of deathmatch gameplay mode. These sorts of minor multiplayer additions would be feasible.
Naev, which Naikari was originally forked from, has been working on supporting rendering ships as 3-D models. Supposedly the 3-D model rendering works, although sprites are still being used. We are willing to accept contributions toward fixing remaining problems and pulling improvements to the 3-D code from upstream, but have no plans to directly work on the problem at this time due to limited resources and other tasks being a higher priority. The only true benefit 3-D rendering would give us is slightly decreased download size (likely about a 50 MB difference) and decreased VRAM usage (likely a difference somewhere in the range of 50–500 MB).
That's actually a diaeresis, not an umlaut, and it has a different meaning. An umlaut (as used in languages like German) modifies the pronunciation of a single vowel. By contrast, a diaeresis doesn't modify pronunciation; rather, it indicates that two consecutive vowels (like the "a" and "i" in "naïve") are pronounced separately, rather than as a unit.
Naikari uses this convention, which most people consider antiquated or "obsolete", as a matter of style. To be more specific, we use it for any vowel hiatus which is made up of one of the following pairs of letters:
- "ai" (as in "naïve")
- "ee" (as in "reëxamine")
- "oa" (as in "koäla")
- "oo" (as in "coöperate")
Naikari also makes use of the grave accent within the context of the Siriusites: they have a special class called the "touchèd". The grave accent here indicates that the letter is pronounced where it normally wouldn't be, as in the real English words "learnèd" and "blessèd".
While American English spelling is generally used, Naikari intentionally uses some spellings that are generally regarded as "incorrect". Here is a list:
- "Thô": An alternate spelling of "though". The circumflex is a call-back to a period of time when "-ough" was occasionally respelled "-ô" to save on paper.
- "Thru": A popular alternative spelling of "through".
- "Miniscule": A common alternate spelling of "minuscule" which is usually regarded as an error.
- "Persue": A common "misspelling" of "pursue".
- "Rondévu": A different spelling for "rendezvous" we made up.
We intentionally chose these spellings just because we like them better. This is especially the case for "thru" and "thô", as these alternative spellings avoid both of these words looking so similar to each other and to "thorough".
These are all known launch options for Naikari when run from the commandline:
| Launch Option | Description of Usage |
|---|---|
| -f, --fullscreen | activate fullscreen |
| -F n, --fps n | limit frames per second to n |
| -V, --vsync | enable vsync |
| -W n | set width to n |
| -H n | set height to n |
| -j n, --joystick n | use joystick n |
| -J s, --Joystick s | use joystick whose name contains s |
| -M, --mute | disables sound |
| -S, --sound | forces sound |
| -m f, --mvol f | sets the music volume to f |
| -s f, --svol f | sets the sound volume to f |
| -G, --generate | regenerates the nebula (slow) |
| -d, --datapath | specifies a custom path for all user data (saves, screenshots, etc.) |
| -X, --scale | defines the scale factor |
| -h, --help | display this message and exit |
| -v, --version | print the version and exit |
| OS | Path |
|---|---|
| Windows | %APPDATA%\naikari\ |
| macOS | ~/Library/Application Support/naikari/ |
| Linux | ~/.local/share/naikari/ |
Saves and screenshots can be found in the saves and screenshots directories, respectively.
| OS | Path |
|---|---|
| Windows | %APPDATA%\naikari\conf.lua |
| macOS | ~/Library/Preferences/naikari/conf.lua |
| Linux | ~/.config/naikari/conf.lua |
Not as such. However, the Lua console (accessible with F2) allows you to modify many things, including adding credits, refuelling, and adding outfits.
Some simple examples:
player.pay(1000000) -- This will give you 1,000,000 credits.
player.refuel() -- This will fully refuel your ship.
player.teleport("Gamma Polaris") -- Teleports you to Gamma Polaris.
player.outfitAdd("Turbolaser", 6) -- Adds 6 Turbolasers to your owned outfits.And a slightly more complex set:
player.pilot():setInvincible() -- Makes you invulnerable until you next reload.
player.pilot():setInvincible(false) -- Makes you vulnerable again.
player.pilot():setHealth(100, 100, 0) -- Restores all shield and armor, and undisables you.
player.pilot():setEnergy(100) -- Fully recharges your battery.
player.pilot():fillAmmo() -- Refills all of your ammo to max.
faction.get("Empire"):setPlayerStanding(100) -- Makes your Empire standing 100%.For (much) more, see the full Lua API documentation.
Naikari uses gettext for translation. The translation files are found in the po subdirectory.