System Shock 2 VR

[673f3394731c1Hardkern]

Nope. They are probably too far along to add someone new anyway.

I've written a readme and you all can go judge my code over at github.
https://github.com/Oribow/SystemShock2VR

[673f33947336dValet2]

Need more info. Did as you said in the manual.

Image: http://valet2.com/images/unityerror1.png

[673f3394734aeHardkern]

So here is what the error means: The .mis file for the level you want to import objects from was not found.

The issue is that all your .mis files are upper case. Mine are all lower case. While windows doesn't care about case in file paths, the index I build for files does. For level files I forgot to transform all cases to lower. I've fixed and commited that to the repo. Please pull and try again.

[673f3394737bcsarge945]

Do you mind explaining some of the structure of your project? I am currently making a VR game in Unity and my lack of previous project experience means I am having trouble making things interact in ways that aren't overly convoluted or tightly coupled.

For instance, I need to make the inventory screen appear when the player presses a button on their controller. But only if they aren't holding anything in their hand. Currently my inventory script checks if there's anything in the hand before opening, but this means the inventory UI is inherently dependent on the hand object, which I don't want.

[673f3394739e6Hardkern]

On the one hand do not fall into the trap of overengineering. GameDev, especially Indie GameDev is not like Corporate coding. Your code isn't going to be used for the next 10 years. It does not need to present a stable API for others to use and it does not need to be reusable. You are probably not going to reuse most of your code ever again in another project.
So don't worry too much about clean code. You don't have the time for it and the end consumer doesn't care.

On the other hand clean code helps prevent bugs and can speed up developement by enabling reuse. You have to find a middle ground and invest time in important (=reusable, often used) scripts, while not caring about one-of scripts.

For the inventory example, if the player is the only thing in your game that has an inventory its 100% fine for it check if the player has something in his hand. That may not be very decoupled, but that doesn't matter.

If other things have an inventory too, like chests, boxes, npc and the like then you want to do a little more work here. To make the basic inventory code reusable across all these things.

In my code I've split the inventory data from the inventory display. (That pattern is called MVC, expect M = C)
Every NPC, Player, Box and Chest can have the same basic Inventory script with the basic store, remove, search operations.

Then for the player you write a specific PlayerInventoryDisplayer script. It uses the data from the inventory to display the inventory. This script only ever has to run for the player so it is fine for it to check the players hand.

So:

Inventory:
# item storage and item management
 - addItem()
 - removeItem()
 - hasItem(anItem)

PlayerInventoryDisplayer:
# displays data from Inventory. Checks if the players hand is free before displaying
 - Display()

[673f339473b89icemann]

*Puts University programming teacher hat on*

Creating good clean code is always far superior to spaghetti code. Use comments before or at the start of every function. Do that and you'll be able to look at your code 6 months later and quickly know exactly what each section does. Will save you hours of work and eliminate potential errors (from misinterpreting what code does).

Never use hardcoded values (eg if(blah==22)), and never use while(true) statements or recursion. Bad programming practice. Just because it's code that works does not mean that it is good code.

[673f339473e6cZylonBane]

Creating good clean code is always far superior to spaghetti code.

Only when all other things are equal. When something needs to go into production RIGHT NOW, you push the code you have.

[673f339474085Hardkern]

"Creating good clean code is always far superior to spaghetti code. "
True, but its not always worth the effort. Judging when its worth it is an advanced skill though.

"Use comments before or at the start of every function. "
Please DO NOT do this. Its a massive waste of time and promotes bad practices. Code should always be self explanatory. If you need a comment on every function, you failed. You failed at naming, you failed at structuring and you failed at setting consistent expectations. Comments will get outdated so quickly you will spend more time writing comments then code. This is a very academic piece of advise that isn't followed in the real world, not even in open source projects. (Look up some open source projects if you don't believe me)

Sarge, I really don't know at what skill level you are at. Really all I can advise is for you to have fun coding and never stop seeking to improve your skills.
Don't overengineer and drop out out of boredom or frustration, but also don't stop growing. (Look up YandereDev if you want a horror of someone who stopped improving.)

[673f339474467sarge945]

My favorite bad comments are ones that look like this:


///<summary>
///Computes two numbers
///</summary>
///<param>the first number to compute</param>
///<param>the second number to compute</param>
///<returns>the computed number</returns>
int ComputeTwoNumbers(int first, int second)
{
...

They both convey no information, and are very verbose. I try to only comment when it's necessary, but there are probably some of these in my code base


To respond to some of your advice hardkern (thanks by the way), I've generally gone with a style where I have each mechanic (inventory, health system, movement system etc) in their own little box (technically just a folder), with my game objects being able to reach in and grab the mechanics they need.

The main reason I did this is because it makes my test cases easier and isolates functionality. The big advantage is I can use editor mode tests and just create native c# objects, simulating things like time passed in a discrete manner. This isn't just easier, it let's me actually test, since the SteamVR interaction system has a problem where, for some reason, all play mode tests instantly complete successfully even if the entire test is

AssertTrue(false);

It still passes.

Anyway my fear is that this is already starting to show signs of overengineering as I have to wrap things.

For instance, if I want to have a trigger that responds to everything implementing the IInventoryItem interface, then I have to basically wrap my inventory c# object in a monobehavior (which may also have other behaviours like events so it's not entirely blindly wrapping, there's extra stuff that can happen too, especially if mechanics interact). A lot of it will just be

Class AwesomeInventoryItem : monobehavior, IInventoryItem, IPhysicsObject
{
    InventoryBehaviur inventoryBehaviur;
    PhysicsBehavior pb;

    void AddToInventory(Inventory I) => inventoryBehaviur.AddToInventory(I);

    void Move(Transform newPos) => pb.Move(newPos);

etc
}


It's supposed to be an implementation of the humble object pattern, but something feels off because I find myself having to write too much boilerplate code.

My guess is the game objects are too close to the mechanics in terms of functionality.

I'm hoping you can tell me why I'm an idiot for going down this path and suggest an alternate path.

Also I came to a similar conclusion with inventory, but using ScriptableObjects. Basically an inventory (players or containers or npcs etc) can be defined as an asset and my inventory display acts on it, as does my inventory interaction zone (the trigger zone when you put an object over your shoulder etc). So they are both working on the same inventory but don't have to know about each other.

[673f339474924Gawain]

sarge945https://docs.unity3d.com/ScriptReference/RequireComponent.html

You should reconsider the interfaces and just get the InventoryBehaviour and PhysicsBehaviour from the target object when needed.
RequireComponent can help to make sure your gameobjects are setup correctly to have what is required.

[673f339474b0eHardkern]

I have to admit, I don't quite understand your example.

Sounds like you have gone overboard with making everything a plain class and then creating a monobehav that "holds" it. You are coding against the framework like that.
Unity is component based so you should get into the mindset of writing components. Components should be like lego bricks. Building complex behaviour by combining them.

Your inventory script should be a component, not a Scriptableobject. ScriptableObjects are for sharing configurable data across GameObjects. If data can vary from instance to instance, it should not be stored in a scriptableobject. An inventory will have different items stored across instances and thus can't be a ScriptableObject.

An inventory should be a Component. Added to a GameObject to add to it the ability to store items.

You already have SteamVR installed, read a little in its source code. Valve does not create holder components for pure c# classes. Valve uses a lot of MonoBehavs.

MonoBehavs make it harder to write test. But I can't really help you with that, I don't write tests. I don't think the SteamVR plugin has tests either. If they do, it might be worth checking out how Valve is doing it.

(I hate the word behaviour. Always make spelling mistakes.)

[673f339474c00sarge945]

Thanks for the advice everyone. I think you're right, I need to think about my structure a bit more.

[673f339474d63Hardkern]

Hi everyone.

I've decided to do one last thing with the project. I've compiled all (really all earth - shodan) levels into a VR sightseeing tour.

Features:
- Walking
- Collisions
- NoClip
- Working Doors
- Working Buttons (most of em anyway)
- Working elevators
- Working level load triggers

A minute of silence for the features that would have required a lot of manual placement and had to be cut:
- working grav shafts
- working ladders

Does someone know how to best publish 450mb worth of data? It includes a small DRM check that requires earth.mis to be present. I hope thats enough to not get sued. If anyone thinks otherwise, please stop me!
[screenshot.png expired]

[673f339474ee0Kolya]

You can upload it to google drive for a start.

[673f339475341sarge945]

A minute of silence for the features that would have required a lot of manual placement and had to be cut:
- working grav shafts
- working ladders

Please step into the grav shaft to proceed to the street level recruitment

*Cries*

Does someone know how to best publish 450mb worth of data? It includes a small DRM check that requires earth.mis to be present. I hope thats enough to not get sued. If anyone thinks otherwise, please stop me!

Any sort of hosting will be fine. Best case is probably your own website (costs money, may have bandwidth limits, but you control the file completely), Google drive/Dropbox/etc, or itch.io.

[673f33947544cicemann]

I still say to stick with the project. Much like Citadel it's your own slant on VR in SS2. Some will like it and others may not, and that's fine. For all you know, Night Dive's attempt at it may fail or go to wayside after a while.

[673f339475551sarge945]

Do you have any plans to release the actual Unity project? I understand if you don't, as it's effectively your work. I guess looking at it's structure would be cool, but I guess Unity themselves provide plenty of projects already

[673f3394756ecHardkern]

Can someone give me feedback if the DRM check is working? I'm not sure my earth.mis is "untouched".

Here is the link to the game. As zip its only 125mb so very small.


https://drive.google.com/file/d/10L_ZzOlzff4r68_M8e0oNB34ywq3lSoe/view?usp=sharing

It uses SteamVR as backend and only has bindings for Vive controller. If you have something else, you have to create your own bindings. Its easy I promise. https://steamcommunity.com/sharedfiles/filedetails/?id=2029205314

On second thought, I may as well auther some bindings my self. Even if I can't test them. Will do that later.

[673f339475a9eHardkern]

sarge945I've posted this before: https://github.com/Oribow/SystemShock2VR

But I don't think you can learn much from it. Its like 99% non-unity importer code. Importer code is also not very polished, because it has no affect on the game.

icemannI can't justify spending so much time on a project without some sort of kickback anymore. I'm grateful for every modder who does, but I'm not in a position in my life right now to do so. NightDive's announcement made this an easy conclusion.

[673f339475b82icemann]

Kickback as in money?

[673f339475c65Hardkern]

Kickback as in "kick in the back" obviously. 

[673f339475d98icemann]

Ah. Kickback has different meanings in different cultures. In my culture to get a kickback = get a investment or cash from something.

Google definition of kickback:

A kickback is a bribe or payment that's given to someone as a reward for their help with something. ... It's a particular type of bribe in which the person receiving the money (or candy) and the person giving it are both participating knowingly in something illegal.

[673f339475e95Hardkern]

I'm not a native speaker. I've only ever heard "kickback" in the sense of voluntary giving something back for a service or product. (US english) Thats why your question confused me.