Reviewing Code

I'm currently working on a project and i was planning on putting some of my code, specifically my player controller, up in the asset store but i am still somewhat new so this may be ambitious but i would like to make sure my code is the best it can be so i was wondering if there is a way or place i can have my code looked over and be given feedback before I put it in the asset store but not have it stolen. Is there a good way of doing this so i can make sure my code is good enough to be in the asset store?

A side note:
This is my first post so I don't know if this was the right place to put it

 

What's your goal uploading it to the Asset Store? I ask because it's important to understand that anything you put onto the Asset Store is expected to be supported by you and one of the ways they try to ensure that support is to require you have a website you can be contacted through.

If you're just uploading for the sake of uploading it somewhere in the event that someone may benefit from it you should just upload it to Github with a permissive license such as MIT or zlib.

 

It is generally not worth it. "Perfect is the enemy of good". Roughly speaking once you've put sufficient amount of effort making your project work and keeping it reasonably readable you're done. It won't be perfect, but if it works, it is good enough. You can try to perfect it, but it will take infinite amount of effort, and you'll gain nothing in terms of functionality. Diminishing returns, as they say. Greatly diminishing.

As @Ryiah correctly said, it is also important to decide what you're trying to achieve it. If you want to let people use it, then github is the way to go, under permissive license (MIT, ZLIB, BSD, Apache, CC0, Public Domain, etc). By doing that you'll "set your project free" and anyone will be free to use it.

Publishing on asset store makes sense if you're trying to earn money. Because (default) license of asset store is restrictive, for example, people cannot improve upon your code. Well, they can, but they are not allowed to redistribute the changes in any form. You can put bsd licensed asset onto asset store, of course, but then it is unclear what's the point, as package manager currently can pull data straight from github. ( https://docs.unity3d.com/Manual/upm-ui-giturl.html )

 

My goal is to sell it on the asset store so I could make a little money hopefully. I dont see an issue with me supporting it as I intend to use it myself.
Do I need a website for myself or is it just a means of being contacted that is needed?

 

Thank you for the reply and the advice. I do sometimes try to perfect things but what I had in mind here was more making sure I keep good practices and put something out there people can use and have it flexible of needed. Also I was hoping to earn money from this which is why I want it on the asset store. I just feel unsure if it will good enough. I dont want to put it up in the store and have people spend money on something bad.

 

This is an opinion.

Realistically speaking, internal code quality matters more when you're making something that people can modify and extend. Meaning an open github asset. If you're making a project for asset store, then you're designing a product instead and thats' different.

(opinion) In this scenario, people won't, in general, hack internal code (because they can't redistribute modified version, so there's no point), or even read internals, and you largely need to design clean user-facing side. That means gui if this is bunch of components/windows, or API if it is code/library. Regarding "people spending money on something bad"... there are a lot of awful code in assets in general, as not all people designing them are professional programmers. In general, clean user facing side should suffice. In contrast, internals can be lovecraftian, because people will try to reach YOU to fix their problems, and as long as you can make sense of it and are available for contact, that's decent.

Additionally the point is to save user's time and money. For example, programmer's wage in USA seems to start at $30 per hour. A decent programmer would be able to replicate absolutely anything currently available on set store, but the catch is that it will take time, and time is money, and lost opportunity cost is involved. For example, said programmer comes home to work on his pet project, and he needs a leaderboard. He can make one himself, but let's say (for the sake of argument) that it will take him 2 hours from start to finish. That's $60 in lost opportunity and 2 hours of lost time. Now let's say that there's an asset that does what he needs and it costs $10. IF the asset works as intended, the programmer can buy it, and save himself 2 hours of time, and spend $10 instead. That, in my opinion, is the role of asset store.

On more complex system, cost to replicate skyrocket. Something like Final IK or Gaia can take 1 or 2 months of full time work (that's assuming the dude in question already knows what features he wants, meaning no research is involved. Cloning takes less time than initial work.), and with the $30/hr guy that's already thousands of dollars of lost opportunity cost. So for an US programmer rather than trying to implement those systems by himself it makes more sense to just buy an asset, even if it is not under open license and even with the risk of the asset becoming unsupported in the future. The situation can be a bit different if the programmer in area from significantly lower salaries, in this case the dude might decide not to pay $100 for IK, and just jury rig a replacement tech.

So, in my opinion, if you're publishing for asset store, and your assets are code, that's your role. Allow someone to save time by paying money instead of reinventing the wheel.

Like I said, that's my opinion, and that's how I see it.

 

I'll be a little bit blunt here but if you aren't too sure about your code, why put it on the store?

That's not to say you need to have perfect or even great code to put stuff on the store that people can use. But there's a sort of implicit assumption that if you put something there, it's because you know what you're doing.

At a minimum, you should have some idea of what good or bad code looks like and how to measure it.

I'm not trying to discourage you, if you want to put it up then by all means. When I put my space kit on the store I had never had a proper programming job, or someone looking over my shoulder criticizing my code. But the fact is that when it went up I had no doubt that the code was good and better than the code of other well-received assets, since I had measured it by specific standards of performance and usability, and searched it relentlessly for logical faults. As a critical customer of my own product (which I was, since I was developing a game with it) I could not find specific things to complain about.

But if I had been sitting there with the vague feeling that my code might have just been crap, I would have had to conclude that I wasn't ready to release a product (though that may not have stopped me).

I would also say that there are many more ways you can test your product than you think. How fast and easy is it to create a new character in an empty project? How easily can it integrate with other products that work closely with its functionality? If someone wanted to add a feature to a specific part, which and how many classes or functions have to be untangled and overridden (try it for yourself, don't just abstractedly consider it)? Are there logical reasons for all functionalities that are not fully encapsulated?

When you have spent long enough looking critically at things and making consequent changes, you just know that things are good.

 

If it is asset store, quality of their code doesn't matter, its utility and usability is what's important.

It could be spaghetti under the hood, and it wouldn't change anything.

Additionally "good code" and "bad code" are often subjective.

 

Yes and no. There are a lot of people who want to modify code or affect functionality in fairly simple ways that still requires things to be done in a clean and modular way. Many of them have beginner or intermediate coding knowledge and know how to modify some code if it's not tangled up but still aren't up to designing the architecture of an entire project.

I also have quite a few customers who are programmers with little game experience who appreciate the quality of my code, since they probably want to learn about Unity from a well-built project.

Also, when the asset gets big enough and new updates and features get built on a good foundation, you will thank your past self for having done things in a way that is pleasant to work with.

But it's very true that usability is the biggest factor, many people simply want something that works without having to worry about what goes on under the hood.

In the end the best test is using your own asset in your own project, and being honest with yourself about whether it's easy to use or whether you're just kidding yourself because you know how to code your way out of anything.

 

One other thing worth keeping in mind is that you are not your customers. Something that is easy to use for you might not be easy to use for everybody else.

 

True, I had to rewrite loads of code to get rid of a lot of interfaces because a lot of people didn't know what they were. But if you assume that your customers are not coders, and test your asset by how easily you can use everything in it inside the editor and the inspector, you won't be far off the mark.

 

I think this is the first mistake.

Don't put your code on the Asset Store. I mean in the sense: do not try to sell the tool you need, sell what other people need.
Realistically how many other people is making the game you're making? The exact same game?
Are you sure, other projects need whatever you have? I don't think so. It is rare.

I would like to discourage people to put up on the store all the secondary systems they are making for their own games and encourage people to actually design their tools for other people.
All the greatest tools on the store are designed for people, not for a game.

 

You could just post your code in the scripting forum and ask for tips. The chances you lose a sale because someone considering buying your script stumbles upon your own thread on it are likely very low.

 

The original point still stands, though. If you don't know what qualities about your product are important to your customers and how to measure whether or not they're good enough then you're not ready to commercialise your product. You should have a solid idea of both of those things.

That doesn't mean you have to be perfect, because nothing is. If you're confident* that internal code can be spaghetti as long as your stuff works reliably and you've got a solid public interface then cool, you do indeed know what quality you need to aim for, and you can tell when you've got there. "Quality" is not just a spectrum between "bad" and "good".

* I would not be confident of that. If it's spaghetti then even if my customers don't want to modify it, I know it'll cause me problems in support down the track.

 

There's spaghetti, and then there's spaghetthi you understand.

There's a good rule "If it ain't broke, don't fix it". So, for example, if you're implementing some sort of tech, and get working prototype that is truly horrific sight to behold, you absolutely can leave it as is, as long as it performs its function. Yes, you can set aside some time and try to untangle and make it pretty, but making it pretty will not improve the final product. Because prettification does not add any features to your product, and does not improve anything user interacts with. It is hidden in the black box under the hood. So realistically, in order to start untangling the mess, there has to be a sufficient chance of it causing problems later down the line. In many cases you can simply postpone it.

 

Calling it "prettification" is trivialiaing the situation. I care a lot less about how it looks than I do about how fragile it is and how difficult it may be to make changes. Reasonable maintainability is absolutely a "feature" that I want a piece of code to have if I'm sharing it with other people on a commercial basis and plan to provide useful support to my customers.

I'm not saying it has to be perfect, but we're talking about a "mess" described as "spaghetti" here.

If I were keeping it in house and it passed relevant tests then sure, I'd leave it alone. That cost can be deferred, and maybe ignored if changes are never needed. But I'm doing myself and my customers a disservice if I release a product which isn't in a meaningfully supportable state.

 

Eh, no, it isn't. "Making code pretty" is one of the insidious programmer's traps. Because making it pretty does not achieve any functionality. "Reasonable maintainability" cannot be measured and is a result of subjective judgement that can be wrong. If you're sharing that piece of code on commercial basis, than that feature offers no value to the customer, because they're going to deal with other things, meaning public api and not the stuff under the hood.

Tons of products are a mess under the hood. In reality the situation means that if you make a mess but it works, then you can ship it now, and if you try to fix the mess, it will take time, and you'll ship later, but at this poitn it will have exact same feature set as the mess did, meaning your efforts will not be visible to the consumer.

Surely you should try to keep things clean since the beginning, but if you decide to "make it pretty" there's a good chance that you're being distracted from other things you need to fix.

 

Not to mention that you can ship today and you will "make it beautiful" gradually later. Small portions at a time when you add some features.

 

I was talking specifically about supportability. You're the one who introduced the idea of being pretty, seemingly just to make a big deal of shooting it down. Have fun there.

 

Take a look at successful asset store code products. Most of them are under continued active development. Positive reviews often cite good support and fast response times, and poor reviews the opposites.

 

I think I fairly clearly stated that I whatever it is you doing should have a reason, and if you're refactoring code, that needs a reason too, otherwise you might be playing beautification game which is a trap. Also this:

Does not exactly correlated with code quality. Good support is a matter of having people handling phone/email, and not about not having any spaghetti under the hood.