koobas.hobune.stream
Is it possible to programmatically create a full simple game?
Hello, I would like to know if there is a way to programmatically create every facet of simple games (for example simple physics-based 2D games). I mean, we can for sure generate scripts code, but we do many things from the Unity IDE, from Inspector and so on, without writing code. It would be nice to have a way that allows doing everything via code. In that case, it could even be automated.
Yes, it's perfectly possible. You could have only one gameobject in your scene with your "main" script responsible for managing instantiation of other gameobject you attach other scripts and components to it.
$$anonymous$$y finger was poised over "convert to answer" before I realized it was you. I have to assume you have a reason for not having this be an answer but I cannot deduce what it is.
Hi Hellium, thanks for your reply. I still need to use UnityEditor in order to create the "main" object and attach the "superscript" to it. Am I right?
Indeed, but I guess you could do this once, for all your projects. Then, you could duplicate your "base project" for other ones.
But, I don't see what you are trying to achieve and managing your assets will be very, very hard I think. You can't reference 3D models or textures/sprites if without the editor (except if you use the Resources folder, but it's not advised to intensively use this folder)
The answer to the question you asked, the way you asked it is "nearly", as @Hellium indicated in his answer-shaped comment. There are plenty of reasons why someone might want to do this. Not the least of which might be "I'm an indie developer and I'm comfortable with programming as the means of expressing my ideas". You might even be able to hook into Unity's compiler pipeline to circumvent even the need for that one game object. I haven't checked to be sure but you can do a lot of interesting things with extensions like that.
@jummatim is definitely right that collaboration with non-programmers is enabled by breaking your code down into smaller pieces (MonoBehaviour implementations) with visible, intentional revealing parameters.
It also just plain makes sense, in certain ways and for certain kinds of games, to use the Unity editor, divide your game into meaningful instances of GameObject, and divide the "surface area" of your code into meaningful implementations of MonoBehaviour. There's plenty you get for free from the Unity editor and it's a quasi-domain-aware editor, so it's really good at making game-related editor operations easy.
I, too, had the impulse to do everything programmatically because of my background but, now that I'm accustomed to doing most things in Visual Studio and the few things that the Unity Editor is really good at in Unity, I can't imagine going back to trying to do everything.
Hi $$anonymous$$ax, thanks for your reply. Where I can find more on "You might even be able to hook into Unity's compiler pipeline to circumvent even the need for that one game object." It sounds like the cherry on the cake.
I don't know a lot about it. It seems like there's some compiler or pre-compile pipeline that Nested Prefabs leverages to do what it does. You might reach out to the developer of that product and ask them for a pointer to API documentation.
It looks like most of it is in the UnityEditor.Build namespace. For instance, IPreprocessBuild.
O$$anonymous$$. Thanks a lot $$anonymous$$ax
@FranzP3
Good day, sir!
From what I understood from your question - you prefer working in IDEs more, than in UnityEditor. It is fair enough and indeed possible to automize all your tools to the level of insanity and be able to set all the interactions, transitions and visuals directly from code. The difficulty appears when you need to give access to your tools to other collaborators. I bet artists, level designers, qa guys or even your friend would love to tweak variables and see the effects immediately on runtime, not necessarily having to poke you or other team members to change a color of the button. Other than that, there are some complex areas such as particle effects, shaders and even UI that make you realise using pre-made assets as a small team is a better solution than writing shaders on your own.
Possible, but I would recommend against that approach. Good question, love the abstraction you've managed to put it in.
Any chance you'd be willing to edit this so that your prose isn't formatted as code?
You can always create your game from scratch without using unity... there are plenty of frameworks which you can use. For c# i would recommend MonoGame
