Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Vapourware Thinking about making a game

undecaf

Arcane
Patron
Joined
Jun 4, 2010
Messages
3,517
Shadorwun: Hong Kong Divinity: Original Sin 2
So, my automation engineer-studies are closing on to their goal (getting my thesis and the few remaining courses done), and I have an opportunity to take a free course on Unity and C# up until the change of the year.

I’ve been thinking about makin an RPG of sorts once I get all the shit done; mostly astract and menu based, I suppose through using either an existing PnP system or making one up.

Some of you are already well versed in the craft, so I thought I would ask some pointers to getting started, if anyone’s willing.

So how should one get started?
 

Glop_dweller

Prophet
Joined
Sep 29, 2007
Messages
1,164
Get a partner to help; once you have one, then you are not free to just put things off —indefinitely.

* I have been thinking about making a game for 30 years; I have Unity, Unreal, Dark Basic, Godot, Gamemaker, AppGameKit, and even mono develop installed; I haven't made anything but tutorial projects, and a 20-minute platformer concept—ever. The platformer concept was a favor for someone else; it's the only reason I made it.

I have the skills for it, I make mods, scripts, art; a professional artist—I never sit down and actually begin.
 
Last edited:

Nathaniel3W

Rockwell Studios
Patron
Developer
Joined
Feb 5, 2015
Messages
1,226
Location
Washington, DC
Strap Yourselves In Codex Year of the Donut Codex+ Now Streaming!
If you have all of the skills necessary to produce an RPG, and you're already familiar with all of the tools you'll be using, and you don't have to spend any time on asset creation, then it will take you at least one year of full-time work to produce a new RPG from scratch in a powerful game engine like Unity or Unreal. If you want to crank out an RPG on RPG Maker using only default settings and assets, and you've made an RPG Maker game before, then it should still take you at least a month or two to make a decent world and plot.

I have already released one game and I'm working on my next project, which I'm starting as an expansion on the first game. It reuses the graphics, sound, the basics of the save/load system, sprite character integration in a 3D world, and Steam integration including Steam Input. I don't often brag about my skills, but I will say that in this case, I know what I'm doing. I'm producing a game with systems that are faster, cleaner, and more flexible and extensible. And with maybe the equivalent of two months of full-time work, I have a character you can move around, a menu that will let you change various options, and a menu that will let you change equipment and use potions on your party members.

I tell you all that to make sure that you understand that an RPG is a LOT of work, and even when you have a huge head start, and you're not spending lots of time learning the basics or creating content, it will still take a long time.
 

bionicman

Liturgist
Joined
May 31, 2019
Messages
674
I think Unity and C# are a good starting point (for a 3d rpg), but...

If you have little or no experience in programming, I recommend you start off with 2d instead, and instead of making an rpg at first, you should make simpler programs (rpgs can get really complex in terms of code).

Game frameworks like love2d (https://love2d.org/) and pygame (https://www.pygame.org/news) are great for 2d game-making, since they utilize Lua and Python respectively (both simple and easy languages to learn, easier than C# and will introduce you to OOP concepts which are useful for making an rpg).

IMO the best way to learn to code is to just dive into coding* instead of watching tutorials, reading books, etc, but that was my approach to learning how to code, maybe the tutorial approach works better for you.

* With this approach, google is your friend if you ever stumble upon a problem, also you learn how to use 'reference manuals', every programming language and game framework/engine has one.

In general though, to make a game you have to be persistent. Yes, it is work as Nathaniel3W says, but the biggest struggle (at least mine) is to finish a project, instead you'll be tempted to start a new one when you're in the middle of one.
 

undecaf

Arcane
Patron
Joined
Jun 4, 2010
Messages
3,517
Shadorwun: Hong Kong Divinity: Original Sin 2
In general though, to make a game you have to be persistent.

Yeah, I’ve been struggling with that with other creative efforts in the past. But here I’m kinda just looking for something to tinker around with in my freetime and see if the couple of ideas I’ve had turn into something, or if the course of doing it leads somewhere else entirely. When I get around doing stuffin the first place, that is.

And definitely quite small scale and 2D where that is concerned. What ever it turns out to be, it won’t be an artistic masterpiece since I’m not an artist.
 
Last edited:

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,291
I think the biggest mistake I made when I started was that I did not study source codes of other projects. Even now I find it useful, just to see how something is done. It doesn't mean it's always the best way, in fact many older source codes are quite messy, but you have to understand it from the perspective of that time. Some source codes are not worth it, like in roguelike scene Nethack and IVAN are the kind of games you don't need to study, because there is nothing to learn from them. But I'm sure you can find readable source codes from the genre/language/etc. you are going to use. If you can read the source code and get an idea what is required and how stuff works it's way easier to start making your own project.
 

Mr. Pink

Travelling Gourmand, Crab Specialist
Joined
Jan 9, 2015
Messages
3,042
PC RPG Website of the Year, 2015 Codex 2016 - The Age of Grimoire Steve gets a Kidney but I don't even get a tag.
https://gameprogrammingpatterns.com/contents.html

Read this short book from start to finish. Every pattern in here will get used eventually.

The difficulty of creating games from scratch depends mainly on architecture decisions made early on so it's important to have a good understanding of how game architecture should work. It is also vitally important to completely grasp model view controller design pattern to abstract your gamestate into a data structure that is easy to work with and completely decoupled from the "view" and "controller" of the game. A data based approach will save you down the line because performing operations on gamestate is what a vast majority of your coding work will end up being.

All video games, especially rpgs are state machines within state machines within state machines. Expect to make state machines for everything. GUI requires a state machine, AI requires a state machine, input requires a state machine, time control (like pausing the game) requires a state machine. You will have to get very familiar with this pattern.

https://catlikecoding.com/unity/tutorials/

If you are new to computer graphics and rendering, this is the best text tutorial that exists on the topic for unity.


If you want to make a RPG, you should start by iterating upon prototypes until you have fleshed out the details enough to start writing a game doc. you will also need to either make your own dynamic and scriptable UI system or use an asset because being able to define each UI elements by script instead of painstakingly designing them by hand in the editor will save you work.

Unity pro tip: store your constants and tweakable variables in classes that inherit from ScriptableObject so you can tweak stuff in the editor and keep track of the literal hundreds of arbitrary values you will likely accumulate.
 
Last edited:

MF

The Boar Studio
Patron
Developer
Joined
Dec 8, 2002
Messages
892
Location
Amsterdam
The first rule of programming is learn how to use data structures. Think of your game elements in data structures.

Like Mr Pink said, you need to completely grasp the MVC design paradigm, but for games the view and controller parts are so integral you don't have to be dogmatic about it if it makes sense to blur the lines between the latter two every now and then. As long as you keep direct access to the data away from the user.

Unity specific:

Everything could be considered a state machine, but don't make the mistake of using something like PlayMaker. State machine editors let you paint yourself into a corner. You can use Unity's mechanim system to do easy state machines. It's intended for animation, but it gets the job done for anything that PlayMaker would do. Anything more than that and you're much better off coding it by hand. Don't be afraid of large switch statements unless it's something that runs in every frame. They're very readable, which is important.

Learn how to make a persistent scene that loads other scenes as children. Unless you're making an arcade game, you'll need this.

Open a Unity Standard Project and deconstruct it until you figure out what makes it tick.

While Mr Pink is right that tweaking variables and constants in the editor is very useful, read from XML files or raw text if you have nested data because ScriptableObjects have limits. Learn how to serialize data or get the EasySave asset, which is amazing. Preferably both. Do this before you define your architecture and data structures, because not every data type that makes sense for runtime operation makes sense for serialization and it's good to think about how you're going to cram your data into a save file. I think the newest EasySave allows serialization by reference, which is cool but might lead to terrible optimization. If you're not going for a data-heavy game, you might get away with it. You don't want to get absolutely ridiculous savegames like in BattleTech where they dump half your stack into a bloated file.

Most of all: Think of an ungodly amount of time to spend on it, then be prepared to double that.
 

Glop_dweller

Prophet
Joined
Sep 29, 2007
Messages
1,164
BTW... If anyone is interested in production Lua game code, 'Aarklash - Legacy' is available for cheap on GoG & Steam, and everything in its ..data\script folder is uncompiled Lua; plain text.

*Scratch that—it's not cheap anymore... wait until it's on sale for cheap.
www.gog.com/game/aarklash_legacy
 

Tyranicon

A Memory of Eternity
Developer
Joined
Oct 7, 2019
Messages
5,875
So how should one get started?

My advice is the most generic and popular in the industry: make a small, self-contained game. Don't worry about getting art, music, etc, just build mechanics and plot (if you want plot).

The ideal starter game would be a 1-hour game that you take a month to make. Don't build something massive, you can always do that later. I prefer the iterative approach: build on your previous games.

My games in chronological order:

  • 1-hr long game with very few gameplay elements
  • 10-hr long game with mostly combat, some story, 3 companions
  • 30-hr long game with open world(ish) and C&C, 9 companions, dozens of important NPCs, lots of gameplay systems (unfinished)
 
Developer
Joined
May 30, 2021
Messages
461
I've made an rpg using Unity3D. I can offer some info about the shitshow you're in for.

-You can't make patches except in the form of file overwrites. Unity does not aid in any patching.
-Unity does not give static IDs to the editor objects. This means you'll have to do it manually, or write a plugin to somehow do it for you. This has enormous implications on savegame upgrading and being assured of initialization order.
-Your code is completely visible if you don't use il2cpp. Try a reflector on your project and you'll see what I mean.
-il2cpp largely sucks. It doesn't configure easily and is not easy to reinstall. (this could have changed in the past few months)
-il2cpp does not provide obfuscation you would get using a native C/C++ compiler. Unity's api is well documented and both il2cpp and unity are freely available. Keep that in mind if you want believe you can resist reverse engineers.
-Don't upgrade your unity projects just cuz. It's far more probably you're getting a worse deal by updating unity at all. Find what works and don't change it.
-Prefabs are useless and confusing for anything that uses scripts. Prefabs are useful for assets that do not change.
-ScriptableObjects are a redherring as far as I can tell.
-Storing data by unity's inbuilt persistence i/o is for cucks. Just use .NET stuff where possible to do the I/O.
-1 Unique Texture = 1 Unique Material. Otherwise when you adjust a material's texture all other object that have that material have their texture changed at same time.
-Prefer GameObject fields types to be exposed to editor over Vector3 type. The reason is Vector3 won't update its info. But moving a game object the updated position is already available and you don't have to reenter coords.
-Don't be shy about Empty GameObjects. Use them to categorize parts of your scene (this will impact hierarchy traversal in some cases).
-Tags are your friend. Layers allow you to further organize your scene, and find those friends with extra precision.

To not overwhelm i'll just end the post with a few comments about gamedev
-If you want lots of freedom to iterate and customize your rpg-related formulas, go for a monolithic approach where gameobjects/gameentities store almost all of the properties they can have in the same place/data structure.
Otherwise you're going to be very upset crawling all over your code to figure out how to reference a specific property each time you change up the formula in a fundamental way.
-Unity is a great tool for prototyping. However switching away is devastatingly hard. You'll want to keep your actual game related code far away from unity's API.
I would suggest avoiding c# constructs when possible if you want to maximize portability. Code in something closer to C. Do not over-rely on unity's Important Classes (like Vector3, GameObject) to do something.
-Watch how much you rely on public exposure of your properties to the unity editor. The more you do this the more rigid your code will end up being because the UnityEditor will require you not to break links.
Also consider how would you fill those links your self if you didn't have the UnityEditor. Do you use a text file? Your own separate editor to view unity3d scenes and setup links?

edit: How could I forget, if you change your processor/motherboard, Unity3D will make you get another license in order to continue to use the editor.

edit#2: It turns out you can drag and drop textures onto a material and it will not overwrite all other materials. I'm not sure how the rules work. Experiment yourself.
 
Last edited:

bionicman

Liturgist
Joined
May 31, 2019
Messages
674
Game frameworks like love2d (https://love2d.org/) and pygame (https://www.pygame.org/news) are great for 2d game-making
why those two instead of gamemaker?

I don't have much experience with gamemaker, so I can't give much of an opinion.

Although I guess the advantage of love2d and pygame is that they're free and open-source, while game maker is proprietary (and somewhat costly?) software with DRM. There was some controversy about it long time ago where the guys working on gamemaker accidentally erased the game assets of their legitimate users in an effort to fight piracy (https://www.mcvuk.com/development-news/gamemaker-anti-piracy-bug-destroys-developer-assets/). On the flip side, game maker supports more platforms (namely phones and browsers) than love2d, and has an IDE with a simple interface I think.

There are other engines and frameworks out there, I recommended these two solely because I have experience with them and learned how to code that way. It's possible that with game maker one can learn how to code more seriously too, I just can't confirm nor deny this.
 
Last edited:

MF

The Boar Studio
Patron
Developer
Joined
Dec 8, 2002
Messages
892
Location
Amsterdam
I've made an rpg using Unity3D. I can offer some info about the shitshow you're in for.
There's some wisdom in here, but it seems like you either experienced Unity 4 way back when, or you never really took the time to wrangle the engine.
-You can't make patches except in the form of file overwrites. Unity does not aid in any patching.
You can use git difs or something like the Steam API to partially patch. It's not very elegant, but it works.
-Unity does not give static IDs to the editor objects. This means you'll have to do it manually, or write a plugin to somehow do it for you. This has enormous implications on savegame upgrading and being assured of initialization order.
I think you've been using the editor objects wrong if that's an issue.
-Your code is completely visible if you don't use il2cpp. Try a reflector on your project and you'll see what I mean.
-il2cpp largely sucks. It doesn't configure easily and is not easy to reinstall. (this could have changed in the past few months)
-il2cpp does not provide obfuscation you would get using a native C/C++ compiler. Unity's api is well documented and both il2cpp and unity are freely available. Keep that in mind if you want believe you can resist reverse engineers.
All true. Then again, you can reverse engineer pretty much anything with modern tools.
-Don't upgrade your unity projects just cuz. It's far more probably you're getting a worse deal by updating unity at all. Find what works and don't change it.
I upgraded from 5.6 to 2017.3 halfway through development. Took me two days to migrate. Wasn't exactly seamless, but performance improvement alone was worth it. undecaf asked about how to start, and Unity's 2020 branch is fine. Do check if the update is worth it, though. Sometimes they only add VR functionality or something that might not be necessary for you.
-Prefabs are useless and confusing for anything that uses scripts. Prefabs are useful for assets that do not change.
You can spawn an instance and make a runtime reference to a script that is unique for that instance. Altering stuff directly is a recipe for disaster, but that's not how prefabs are meant to be used. You even get warnings if you do that.
-ScriptableObjects are a redherring as far as I can tell.
Mostly true. Like I said above, they have their limits. If you are aware of those, they're pretty useful.
-Storing data by unity's inbuilt persistence i/o is for cucks. Just use .NET stuff where possible to do the I/O.
Absolutely true. Like I said, get EasySave for proper serialization if you don't want to roll your own filestream I/O.
-1 Unique Texture = 1 Unique Material. Otherwise when you adjust a material's texture all other object that have that material have their texture changed at same time.
A texture can be shared by infinite materials. You can change a material's texture array on the fly by instancing it, although that's bad practice and I've only done that for some optimized animation tricks and for generating composite textures for character models and clothing.
-Prefer GameObject fields types to be exposed to editor over Vector3 type. The reason is Vector3 won't update its info. But moving a game object the updated position is already available and you don't have to reenter coords.
Not sure what you're getting at here. A GameObjects position fields are Vector3 types.
-Tags are your friend. Layers allow you to further organize your scene, and find those friends with extra precision.
Layers are not for finding stuff in the editor, layers are for bitmasking raycasts and camera culling.
-Unity is a great tool for prototyping. However switching away is devastatingly hard. You'll want to keep your actual game related code far away from unity's API.
I would suggest avoiding c# constructs when possible if you want to maximize portability. Code in something closer to C. Do not over-rely on unity's Important Classes (like Vector3, GameObject) to do something.
-Watch how much you rely on public exposure of your properties to the unity editor. The more you do this the more rigid your code will end up being because the UnityEditor will require you not to break links.
Also consider how would you fill those links your self if you didn't have the UnityEditor. Do you use a text file? Your own separate editor to view unity3d scenes and setup links?
That's not a productive way to think about this. If you want to switch away from it at some point, just don't use Unity to begin with, not even for prototyping. Mono is virtualized so portability is a non-issue.
How could I forget, if you change your processor/motherboard, Unity3D will make you get another license in order to continue to use the editor.
You can easily manage your seats and add a new machine in the portal. Has been the case since at least 2016.
 

Nutria

Arcane
Patron
Joined
Mar 12, 2017
Messages
2,252
Location
한양
Strap Yourselves In
I don't know what you should do, but I know what you should not do:

* The UI is gonna take up way more of your time than you'd ever imagine.
* Project management is gonna be way more important than you'd ever imagine.

So imagine the task ahead of you as a pyramid and the actual gameplay stuff that you care about is at the top. Everything below that is most of what you'll be doing.

Maybe try to get other people involved, at least to the extent that they keep nodding while you babble about what you're doing. They don't necessarily need to understand wtf you're talking about. It's just a lot easier to keep up momentum when you feel like you've got someone to answer to.
 

The Avatar

Pseudodragon Studios
Developer
Joined
Jan 15, 2016
Messages
336
Location
The United States of America
-Unity does not give static IDs to the editor objects. This means you'll have to do it manually, or write a plugin to somehow do it for you. This has enormous implications on savegame upgrading and being assured of initialization order.

I solved this issue by making my own base class for every object that would need to be saved, and automatically giving that a GUID. Easy enough.

-il2cpp does not provide obfuscation you would get using a native C/C++ compiler. Unity's api is well documented and both il2cpp and unity are freely available. Keep that in mind if you want believe you can resist reverse engineers.

Stay away from IL2CPP if you want your game to be moddable. IIRC, you need to use the traditional mono framework to make your game moddable like Pathfinder: Kingmaker is with Unity Mod Manager.

-ScriptableObjects are a redherring as far as I can tell.
Not just ScriptableObject, but in general Unit's serialization is horrible. I use Odin which fixes serialization and the editor experience in general. This does tie me to using Unity and a third-party solution, but honestly, having an actual good editor instead of manually editing json or xml is almost worth it.

I've been using Unity for 10 years, but I've grown to dislike it more and more. If I had to start over, I'd choose Unreal Engine because it "Just works" out of the box without additional plugins. But I can see how Unity would be a good choice for a beginner as C# is far more friendly than C++.
 

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,086
Location
デゼニランド
Start with a small and focused project. If your first project is going to be a huge RPG with 60+ hours of content, your chances of actually delivering it are low, and your chances of making a good game out of it are even lower. Focus on quality over quantity -- learn how to make short but finished games, make them compelling, and only then start thinking about making them bigger.

Invest in your toolset and don't rush through the early stages of development. The foundation of your game should work without issues and your tools should allow you to create content fast with little to no room for human error.

Even if you're planning to use third-party plugins, I strongly suggest at least trying to write your own solutions first to understand the way things work under the hood. Studying the source code of other games is not a bad idea, but it's key to understand the logic and not just copy the code.

That said, avoid being an arrogant fuck that tries to reinvent the wheel on each and every step, ignoring the built-in features and documentation will bite you in the ass sooner or later.
 
Developer
Joined
May 30, 2021
Messages
461
MF

"All true. Then again, you can reverse engineer pretty much anything with modern tools."
I apologize if i'm misreading your point.

You can forward engineer anything with modern tools too. If you have years and years.

Question is the difference of difficulty when it comes to RE for whole of the project. Because reality check, we'd derive every game's source much quicker (seconds) as opposed to (years and years) if everything was managed code. Before il2cpp this is what using Unity meant. Code obfuscators are a joke, unless you know how to custom-build one. Remember its seconds and some junior programmer could begin passing off their frankenstein as yours thanks to a .NET reflector.

It's about inflicting cost upon the would be reverse engineer, their time and/or their money. Let me be clear i'm not saying you can't get lucky and decode this or that class structure in a day. It's about protecting *YOUR* source code not some shadow of it the compiler produces. Nor is it about some delusion that anyone with a hex editor and some RE knowledge could'nt reverse any part of the game.

"You can use git difs or something like the Steam API to partially patch. It's not very elegant, but it works."
My point is partial patching as you say, isn't built-in and is UNDOABLE by any clever invocation of Unity API or C#.NET API. (note: yes i’m aware of run reflection, it doesn’t scale as patching mechanism if you have many classes)

The UnityScene cannot be ignored, and so if an update happens and a script is now attached to this as opposed to that, your partial patching options are nill.

I'd file this under worth knowing. There is no built-in way to partially patch the scene. I'm sure there's some unity script bundle from its store that addresses this, I don't care. That's some i got too much time on my hands to figure out
unity's own scene representation format bullshit.

"I think you've been using the editor objects wrong if that's an issue."
Unity GUIDs are not static, they're just relatively unique to every other ID.
Even if a GUID appears static in some context that's likely the hashing of an asset (maybe among other things), so when the asset changes, you've lost a reliable upgrade path. When Object/Asset X changes, so does its ID after that point. Thus you can't do a reliable save game upgrade.

You need a reliable way of identifying game-objects at the very least, but even if you do that how
can you be certain of initialization order if starting pool of game-objects (determined by the editor) change?

Fact is you need the editor itself to keep static id assignments to have any certainty at all.

"Not sure what you're getting at here. A GameObjects position fields are Vector3 types."
Preferring to use GameObjects to store info about position data, means you drag and drop a marker once.

This is superior to updating the coords fields directly, because with the gameobj the coords update automatically when you move the marker (the game object).

"Layers are not for finding stuff in the editor, layers are for bitmasking raycasts and camera culling."
Wrong you can arbitrarily set the layers in the editor. You can create custom layers too.
A game-object layer info is available for edit and viewing in editor mode but also when running the game via script access.
It does serve as a way to further classify what a game-object is. And yes raycast can be sensitive to specific layers.
You can use knowledge of what layer something is on to organize how your scene breaksdown. You might create a layer
that is labeled "Offscreen". There could be game objects that are on this layer, but also tagged GameEntity.
By tagged I don't mean named, I mean the tags it has. There may be many GameEntities, some named bob or sally, but all tagged “GameEntity”.

Anyway when you do a raycast, you may wish to detect GameEntities but only on certain layers.
But you can also use layer info when doing game object finds. Suppose you create a giant list of all GameObjects tagged GameEntity. Ok but what if you want just those that are on a certain layer? Well camera culling and raycasting are irrelevant computations to knowing that. Just read the layer property and sort.

"You can easily manage your seats and add a new machine in the portal. Has been the case since at least 2016."
In my case it was the dev machine itself that changed. How can you add a "seat" for a machine Unity doesn't know exists until you repair/assemble it?

Telling a portal anything sounds just as annoying as regrabbing the license itself. How about not revoking our damn license in the first place?


In regard to the OP, I am reminded of few other important facts.

1) GameObjects in unity if disabled, can no longer be found. You have to keep your own reference or it's lost forever. LOL.
2) GameObject find commands are slow. The most important class of all has a soft spot on being located in memory. LOL.
3) Certain properties like position/scale/rotation “lie” if a game object is a child of another, and there's no display of their true absolute values in the editor. This means you're in for quite a ride if you write a script not accounting for the object's parent(s).
 

MF

The Boar Studio
Patron
Developer
Joined
Dec 8, 2002
Messages
892
Location
Amsterdam
MF
It's about inflicting cost upon the would be reverse engineer, their time and/or their money. Let me be clear i'm not saying you can't get lucky and decode this or that class structure in a day. It's about protecting *YOUR* source code not some shadow of it the compiler produces. Nor is it about some delusion that anyone with a hex editor and some RE knowledge could'nt reverse any part of the game.
Fair enough.

The UnityScene cannot be ignored, and so if an update happens and a script is now attached to this as opposed to that, your partial patching options are nill. I'd file this under worth knowing.
Scenes are atomic, yes. I don't have a monolithic scene structure so it's not that impactful, but I can see how that can be a major pain in the ass. If I make changes to my biggest scene, no matter how insignificant, the update will be at least 100MB.

Unity GUIDs are not static, they're just relatively unique to every other ID.
Even if a GUID appears static in some context that's likely the hashing of an asset (maybe among other things), so when the asset changes, you've lost a reliable upgrade path. When Object/Asset X changes, so does its ID after that point. Thus you can't do a reliable save game upgrade.

You need a reliable way of identifying game-objects at the very least, but even if you do that how
can you be certain of initialization order if starting pool of game-objects (determined by the editor) change?

Fact is you need the editor itself to keep static id assignments to have any certainty at all.

That's only a problem if you store references in your savegames. I just serialize the values and keep track of my own identifiers. When loading a game, I populate the data and create new references.
Unity doesn't really support the idea of having a persistent identifier out of the box. I see what you mean now.

As for initialization order, that's always top-to-bottom, depth-first. If you change that, you change the order, that's true. It caused a few race condition bugs in my game so I ended up setting up semaphores. A lot of them.

You can give certain scripts execution priority, but that's a little finicky. Relying on the hierarchy for initialization order isn't the best idea. So we agree on that.

Preferring to use GameObjects to store info about position data, means you drag and drop a marker once.

This is superior to updating the coords fields directly, because with the gameobj the coords update automatically when you move the marker (the game object).
The position fields ARE Vector3 types. GameObject > Transform > 'public Vector3 position'. I don't understand what you mean. The position data is always stored in a Vector3, no matter how you access it.

"Layers are not for finding stuff in the editor, layers are for bitmasking raycasts and camera culling."
Wrong you can arbitrarily set the layers in the editor. You can create custom layers too.
Of course you can set tags and layers in the editor, that's not what I meant.

They're not there as a crutch in the editor, they have a specific logical purpose.

Layers are best for determining what is hit by a raycast and what is viewed by a camera due to the way they work under the hood. Eg.
int layerMask = ~((1 << specialLayerIndex) | (1 << superduperLayerIndex)); sets up a raycast mask, ignoring the two mentioned layers. It allows for optimized culling.

Tags are mostly used to ignore or accept GameObjects, especially in the physics engine.

You can also use them to sort or narrow a find, but that's just not their main purpose. At least as far as I know.

"You can easily manage your seats and add a new machine in the portal. Has been the case since at least 2016."
In my case it was the dev machine itself that changed. How can you add a "seat" for a machine Unity doesn't know exists until you repair/assemble it?

Telling a portal anything sounds just as annoying as regrabbing the license itself. How about not revoking our damn license in the first place?
It's three clicks. The portal is on the Unity website, you could do it on your phone if you had to. I understand why you think this is lame, but it really isn't a big deal.

In regard to the OP, I am reminded of few other important facts.

1) GameObjects in unity if disabled, can no longer be found. You have to keep your own reference or it's lost forever. LOL.
2) GameObject find commands are slow. The most important class of all has a soft spot on being located in memory. LOL.
3) Certain properties like position/scale/rotation “lie” if a game object is a child of another, and there's no display of their true absolute values in the editor. This means you're in for quite a ride if you write a script not accounting for the object's parent(s).

1 ) Always keep a reference. That's good practice in any language that has garbage collection. It's not C. You can always use Resources.FindObjectsOfTypeAll to include disabled objects, but you're better off just keeping a reference to it.
2) GameObject.Find() is a last resort and terribly slow. Just keep references. If you must, use component types (eg findobjectoftype) to search.
3) You can tell it whether to display absolute or local values. Toggling the tool handler to local/world or center/pivot also changes the inspector values. You always have to be conscious of an object's hierarchy when scripting. It's mostly an annoyance in the animation system, where the CTRL-6 editor likes to alternate between relative and absolute positions based on god knows what.

Anyway, we're getting off track here. I guess it boils down to two guys holding a hammer differently. There's someone here asking how to start hitting a nail and the advice is mostly sound.

Also, in regards to the OP, don't get deterred by this arcane Unity talk. It's probably the best engine for what you're trying to do. Just get in and start doing stuff. God speed :salute:
 
Developer
Joined
May 30, 2021
Messages
461
Speaking of two hammers.

I actually chose the route of storing everything in one single scene file.
I only felt the sideeffects when I added all the terrains.

I thought multiple-scene files might be warranted when the random encounters for my game were added.
Because they occur on their own terrains, they showed up in world map and/or viewable in distance.
Ditto for underground dungeons or interiors. Ideally these shouldn't pollute your main scene file.
Luckily there was enough space I could get away with them being in same scene file, anyway.

I always resented the original Fallouts hiding containers offscreen to serve as npc shop inventories.
But everybody cuts corners and settles at some point.
 

Quilty

Magister
Joined
Apr 11, 2008
Messages
2,406
I'd say choose a relatively small game that you like and that you have played enough to know really well and then try to remake it. It's what I'm currently doing with Gangsters: Organized Crime and I find that it keeps me motivated far more than working on some of my other projects which are based on my own ideas. Most importantly because I'm no game designer, and by choosing to remake something that already exists and that was designed by someone else, I can pick it apart and think about what works and what doesn't: it's all there, I just need to check it, think about it, and then modify it if I think it needs fixing.

A few tips to keep in mind if you choose to go that route:

1. If it's a big game that you want to remake, reduce it to its minimum and remake that: for example, could you make an entire RPG that consists of only one level/area? If you really like Fallout 1, could you make a short RPG that is only located in something like Vault 13? I'd love to play something like that, since I have less and less time for long games. An RPG that took less than 10 hours to complete would be great!

2. Steal and steal a lot: ideas are out there, grab what you like and change it to suit your preferences. Who cares if Fallout was among the first to use the idea of a post-nuclear society living in a vault! If that's what you like, take that idea and make it uniquely yours.

3. Don't think about what the market needs or what people want to play. If YOU would play your game, there's people out there who'd also like to play it.

4. Know your strengths and make a project that shows those strengths off: I am bad at graphics/modelling/art, so I do what I can to avoid that part of game development or use simple graphics and free assets. The Unity asset store is amazing. Use it.

5. Use shaders to achieve nice effects. I know very little about writing shaders, but there are those who do and who make their work (or tutorials) freely available. I use that and adapt it to suit my needs.
 

Falksi

Arcane
Joined
Feb 14, 2017
Messages
10,538
Location
Nottingham
I'm just adding a few touches to my first game. I've no idea how to make one properly, so did it on RPG maker. It's purely designed for my mates to play and a homage of our childhood, but I had a great time making it and I'm fairly happy with the results in that it achieved what I set out to - something to play that's a bit of a laugh and takes the piss out of folk I know.

I'm glad I didn't try and make a "proper" game, but the best advice I got on here was to keep it short-ish. I aimed for a 2 hour game, but it's probably in the region of around 5-6 hours (just adding a few more bits, so not sure yet)

Ultimately I think the first few games you do should be bitesized, and purely for fun & to fuck about with whilst you learn your craft (like most crafts). Otherwise they'll break you like they have Tavernking, who's clearly now a spineless homo.
 

Moaning_Clock

SmokeSomeFrogs
Developer
Joined
Feb 7, 2021
Messages
655
In my experience it all comes down to motivation and discipline. I created a couple of games in different roles (writer in the first, writer+marketing+sound in the couple next projects, now almost completely solo) and every time it was only a question of motivation and discipline. No motivation but much discipline = you can finish your current game but likely won't start the next. No discipline but much motivation = you start hundreds of side projects which slowly rot on old hard drives.
Tools are not an issue any more, performance isn't an issue if you stick to 2D and simple 3D games. I personally would aim for something in the start (after a tutorial project) that I could finish in 1-3 months. If you have a dream game, maybe make a 5-10 minute version of it and dabble around. Or jump into game jams!

It's great to build your own stuff. Have fun!

:buildawall:
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom