![[FPE Kit Logo]](img/fpekitCover.jpg)
The latest version is available in the Unity Asset Store.
Download the demo for Windows (alternate download host), or watch a detailed walkthrough on youtube.
All demo scenes are included in the package.
First Person Exploration Kit is a complete package to create a First Person Environmental Exploration or Adventure game.
If you have any problems using this package, please check out the Common Issues section. If you need further assistance, or have tweaks or new features you'd like to see included, please email me with the details.
Thanks,
Richard
A series of tutorial videos is available on youtube playlist here.
Q: I have changed some of the source code that was in the previous version. Will my changes be overwritten when I upgrade?
A: YES! Your changes will be overwritten. Please be sure to back up your project before upgrading. Refer to the migration guide for detailed steps on upgrading your project: Migrating your project from v1.2 to 2.0
Q: Is there a bullet proof way to modify the existing source code to ensure future upgrades will never break my project?
A: No. BUT, you can do things like extend existing 'FPE' classes, which will help. I will always try to avoid "breaking changes" to the core code, but cannot guarantee it. It is best to make note of all changes you make to the source code. You can do this with code regions, comments, track them in a text file, etc.
Q: Is this asset package compatible with other player controllers like UFPS?
A: Not out of the box, no. Some customization is required. Please refer to the Player Configuration documentation.
Q: Does First Person Exploration Kit work in VR?
A: Not really, no. You could port it to work in VR, but it was not designed with VR in mind. As a result, much of the UI and interaction methods won't work the same way in VR. For example, the screenspace UI will not work with stereoscopic cameras. And actions like examining objects require the player movement and view are locked, which is not really good practice in VR.
Q: Will First Person Exploration Kit work on Mobile and/or with [Some Specific Touch Input package]?
A: For mobile, the primary consideration is controls. Assuming you're using a touchscreen, there will be some work to ensure that the FPEInputManager talks with whatever touch screen control system you're using. The FPEInputManager system was designed with this in mind, so you can hook up virtual touchscreen "buttons" and "axes" to it, but it doesn't have this built in. The hooks are all there, but there are tons of touch screen input libraries and packages out there, so the core product can't really include specific considerations.
As for the rest of the package, everything else should "just work" on mobile. There will be design decisions that will dictate things like supported devices, aspect ratios, and so on, but none of that is unique to FPE Kit. Other design considerations for touch screen controls include what you should do for actions like Object Examination that require the player presses and holds a button. How do you want to translate this to touch screen control?
Finally, depending on how much you want to allow game saving and loading (quick saves vs. "complete level" saves vs. no saving at all), ensure you're familiar with your target platform's most recent File I/O libraries. By default, FPE Kit uses Application.persistentDataPath as its default path, and writes using the BinaryFormatter class. The file parts of the kit are modular, so all the upstream code won't care if you change how you actually write to the files themselves if you need to change. For example, if your target platform needs to handle things like SD card removal and insertion, and that impacts file paths, that will need to be handled as it falls outside the scope of the kit's "off the shelf" capabilities. Or if you want to use something like Newtonsoft JSon for files, you can do that instead.
Q: What are the license terms of this asset? Can I ship it in commercial games and applications?
A: Absolutely you can. BUT, you cannot re-sell or re-distribute the source code or raw 'asset package' in any form. Basically, the thing you ship must be an executable, not an editable "Unity Project". Please refer to the Unity Asset Store terms of service.
Q: Why does this asset cost so much?
A: Depending on your skill level and comfort with Unity, this asset will save you hundreds of hours of development time. The price is designed to be fair for what the asset provides, without freezing out indies or hobbyists. It is important to me that the asset remains affordable, while also providing enough return so I can continue to support and maintain it.
Q: Can I have a Voucher Code for a free copy of First Person Exploration Kit?
A: Typically, the answer here is an unfortunate "No". The reasons is that Unity's current voucher system is very limited (unlike steam keys, for example), and there are only have a handful a year available to give out so they are usually reserved for special events and targeted giveaways. Until the voucher system changes, it is unlikely a voucher code can be provided. However, you are encouraged to watch out for Asset Store sales. They can provide a huge discount sometimes (up to 90% in some cases!) and happen multiple times a year.
Q: How do I integrate FPE Kit into a Multiplayer game, or make it work with [Some Multiplayer Unity Asset]?
A: This question is hard to answer, as it depends greatly on your design goals for your Multiplayer experience.
Depending on your design goals, you may want to track things like Pickup interactions as networked objects. Currently, when a player picks something up, it is flagged as "picked up". But in a multiplayer world, you would presumably want a picked up item to be visible to other players in the game, and also prevent them from picking up that same object. As such, you may want to track these items as part of your client-server design. Similarly (and again depending on your design goals), you may want to add a flag to the base Interaction object type that tracks whether or not it is "in use" (in a general sense) if you wish to prevent multiple players from interacting with the same object at the same time. For example if you had a chair players could sit in, and player A sat down, you might want to mark that chair as "in use" so player B cannot sit down in that same chair. These considerations really depend on the type of gameplay experience you're after. As far as player to player tracking and things like that, all the games systems would operate as they do now in single player, with the added logic that interactions must not work if they are marked as unavailable/in use/picked up/etc. by the server. Otherwise, each player should be able to walk around in the game without issue.
I would also recommend discarding the default FPE Kit Saved Game system entirely, as it doesn't really make sense when applied in a multiplayer environment. Perhaps each player's inventory could be saved, but you may want to somehow safeguard that against hacking or other exploitation so the save data may have to live as part of the server's game state information. Some of the code can be reused, but it's going to require some work depending on your goals. Similarly, saved game data integrity cannot be managed remotely across player computers with ease. If the server wanted to track where objects were, I think reusing most of the included save game system would work in terms of saving/loading object states and locations for the multiplayer levels before adding the players to the world. But player-specific states probably shouldn't be saved (e.g. if player A has an apple in their hand and quits the game, presumably that apple should remain in the world, not go with the player, and things like that).
So, multiplayer won't work 100% as expected "out of the box". But with some thoughtful design choices and testing, you should be able to make something compelling for players in this space. I would strongly recommend having team members on your project with Multiplayer implementation experience, as I cannot provide very much support on this topic as it applies here.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.