|
Kaedric posted:This is why I like to use events. The fireball example above I wouldn't put any screenshake code in there at all, I would just emit a 'fireballExploded' event with appropriate data attached and anyone who wants to subscribe to that can do so. So I'd have a function in the camera to listen for the event and shake. This is the actual way to separate these kinds of concerns in a video game. If I had two cameras, my explosion code that used to call camera.screenshake() would instead call camerasManager.screenshake(). I wouldn't instantiate each object with knowledge of which camera it was on and then have each object responsible for tracking cameras. With the event system, I can add in chromatic aberration or whatever other effects that care about explosions in the code responsible for handling those kinds of effects. Dr. Stab fucked around with this message at 21:22 on May 3, 2020 |
#
?
May 3, 2020 21:13
|
|
|
|
| # ? May 12, 2024 14:01 |
|
|
Suspicious Dish posted:How are either of these related to the GameplayCamera? Ideally this is just a math class that can build proper view and projection matrices. Screens shouldn't matter here. It's not "just a math class", you may end up having to render twice, you might have to deal with different pixel dimensions, you can't always solve that without invalidating the original instance. You might even not want to shake in the same way in VR because it causes simulation sickness.
|
|
#
?
May 3, 2020 21:52
|
|
|
In this episode of "Rocko's smallest victories" he finally gets this custom Python interpreter to run this code in Unity:code:
|
|
#
?
May 4, 2020 08:13
|
|
|
I've been stuck so long in this script embedding world that my Unity skills have atrophied, but I think this particular question is a little more involved. How would you set up a diagnostic to color game objects in code? It's not as simple as changing the mesh renderer's color because the material doesn't necessarily even care about it. I'm guessing I need to create a separate material with its own shader, and a _Color input that I mess with as needed.
|
|
#
?
May 10, 2020 07:38
|
|
|
I use the debug draw functionality to stick a colored ray at the object's origin because I'm lazy.
|
|
#
?
May 10, 2020 08:22
|
|
|
Yeah, use the Gizmos library for that kind of thing IMO.
|
|
#
?
May 10, 2020 14:46
|
|
|
I had to kind of turn my brain around for gizmos to stick in my head since I got fixated on doing something with the renderer in my script already. I think I'll get more flexible with this the more confidence I get in my drat interpreter. It's ... working better than I expected, but I'm still handling it with kid gloves and acting like empires rose and fell to make each line possible.
|
|
#
?
May 10, 2020 18:31
|
|
|
If you don't break it now, your players will later.
|
|
#
?
May 10, 2020 20:43
|
|
|
I'm just trying to figure out if it works at all, not how it doesn't work. I wanted to create a contagious script that would schedule copies of itself to everything the current game object collides with, and turn that yellow. It just turns out setting the renderer material's color to yellow doesn't seem to do anything even in normal C#. That wasn't the whoopsies I was expecting to find.
|
|
#
?
May 10, 2020 22:30
|
|
|
I'm not sure if this is the right thread but I'd like some advice. I'm old and know nothing about coding beyond the HTML I used to hand-code websites in the 90s. Can someone hold my hand and throw me at some resources to teach me how to make little games that even a turbo-idiot like me could understand? I used Construct for a few days but that's largely drag-n-drop.
|
|
#
?
May 14, 2020 20:07
|
|
|
Inzombiac posted:I'm not sure if this is the right thread but I'd like some advice. How much coding do you want to learn? If the answer is "a lot," I recommend One Lone Coder If the answer is "some, but not as much as that guy holy poo poo," I recommend looking at Unity or Godot or one of the other free-ish commercial game engines out there. If the answer is "very little to none," I recommend something with a visual scripting interface like Unreal or RPG maker or something.
|
|
#
?
May 14, 2020 20:17
|
|
|
I already have a full-time job and a house to maintain so free time is certainly a luxury. Someone at work, whom I respect, says that I should be learning Python "just because" but they are coming from a much more technically minded place with a lot more experience. (I don't work in game development, just to be clear.)
|
|
#
?
May 14, 2020 20:26
|
|
|
Inzombiac posted:I already have a full-time job and a house to maintain so free time is certainly a luxury. Watch some videos on Youtube. Start with One Lone Coder and go from there to see if it's interesting or not to you.
|
|
#
?
May 14, 2020 20:34
|
|
|
KillHour posted:Watch some videos on Youtube. Start with One Lone Coder and go from there to see if it's interesting or not to you. I appreciate it. His videos seem to have the right vibe for me. I have ADD and it takes a somewhat particular environment for me to learn new and complex things.
|
|
#
?
May 14, 2020 20:37
|
|
|
Inzombiac posted:I appreciate it. I picked him over some of the other options because I find his voice soothing and easy to listen to. Quill18 is smart and tackles some more complex/complete projects, but he sounds like a cartoon character on crack.
|
|
#
?
May 14, 2020 20:43
|
|
|
I found Unity's Create with Code course really easy to pick up: https://learn.unity.com/course/create-with-code I tried it sometime last year and got about halfway through before fizzling out. Two months into lockdown, I started again and have managed what the live version of the course claims is six weeks of modules in twelve days. Apparently all my procrastination needed was a couple of months off work.  So I might actually have something to show in a while! I miss game jams, I want to get back into those and just loving around with games like I used to, many moons ago.
|
|
#
?
May 14, 2020 21:02
|
|
|
I have a project idea that I want to be able to deploy to mobile devices, I'm comfortable with C# or JS so I'm leaning towards either Unity or React Native but I wanted to see if there were any other real options. Only planning on 2d pixel art, no 3d graphics.
|
|
#
?
May 14, 2020 21:11
|
|
|
I have add real bad, programming really scratches that hyper focus itch. So get ready for that!
|
|
#
?
May 14, 2020 21:23
|
|
|
BoneMonkey posted:I have add real bad, programming really scratches that hyper focus itch. So get ready for that! I sure hope so. The only thing that can reliably wrangle it is doing an art project with a very specific goal in mind (which is what made me a good freelancer back in the day).
|
|
#
?
May 14, 2020 21:34
|
|
|
Unity has so many features, it abstracts everything to such a degree that you basically have to learn what it's doing on top of what you're supposed to be doing. I think it' a bit bloated to learn for someone with little spare time, got burned out on it myself to some extent. Switched to Godot and I've had a much easier time. Especially if what you're doing is 2d, since it's 2d offering is pretty sweet. The UI was built out of it's own UI tools for example.
|
|
#
?
May 14, 2020 21:37
|
|
|
Inzombiac posted:I already have a full-time job and a house to maintain so free time is certainly a luxury. This person's full of it. 'it' in this case is an entirely justifiable love for Python and an entirely unjustifiable belief that you will have as much fun making games in it as they do making other crap in it.
|
|
#
?
May 14, 2020 23:59
|
|
|
I had what I thought was a pretty great release window for my game up until I got coronavirus and was knocked on my rear end for two months straight. Now we're delayed, and running out of money, and it looks we're going to have to launch around the same time as the steam summer sale. I feel like it would probably be a bad plan to launch during the sale, as even an aggressive launch discount will be overshadowed by games that are like 60% off. After the sale I feel like people are going to be all spent out for a while, with a bunch of new games to play. But I have no idea how much that actually affects the launch of a new game, or for how long. Am I overthinking this? Anyone have any insight?
|
|
#
?
May 15, 2020 06:31
|
|
|
Inzombiac posted:I appreciate it. You might just try out a bunch of different engines and the languages that tend to go with them until you find a combination that clicks with your brain and is fulfilling. I'm saying that here without even listing any. If you don't have an immediate objective then you may even find fulfillment modding a game you already enjoy.
|
|
#
?
May 15, 2020 06:48
|
|
|
Tip posted:I had what I thought was a pretty great release window for my game up until I got coronavirus and was knocked on my rear end for two months straight. Now we're delayed, and running out of money, and it looks we're going to have to launch around the same time as the steam summer sale. I'm terribly sorry and I'm sure your game is great, but if you're trying to make money off an independent game on steam you either need a time machine to 2015 or a slot machine that always hits jackpot
|
|
#
?
May 15, 2020 07:53
|
|
|
more falafel please posted:I'm terribly sorry and I'm sure your game is great, but if you're trying to make money off an independent game on steam you either need a time machine to 2015 or a slot machine that always hits jackpot by this I mean: don't hurt yourself, ship your game when it's ready, do what you can for promotion, have a backup plan. Please don't burn yourself out on this.
|
|
#
?
May 15, 2020 07:54
|
|
|
What's the best strategy to launch an independent game in 2020 or so? Kickstarter leading into itch.io? Assuming a successful kickstarter I imagine that's about as much success as you could hope for.
|
|
#
?
May 15, 2020 08:17
|
|
|
more falafel please posted:by this I mean: don't hurt yourself, ship your game when it's ready, do what you can for promotion, have a backup plan. Please don't burn yourself out on this. I appreciate the advice. I'm mainly just looking to avoid loving everything up at the last minute after we've spent years working on this. I know game development is always a gamble but I'm feeling cautiously optimistic about our chances. We're doing something very new that players have been loving and people get really excited about. I also know game developers always think this lol. I'm actually a second generation indie game developer, literally grew up inside an indie game studio that my dad ran out of our house.
|
|
#
?
May 15, 2020 08:24
|
|
|
Nolgthorn posted:What's the best strategy to launch an independent game in 2020 or so? Kickstarter leading into itch.io? Assuming a successful kickstarter I imagine that's about as much success as you could hope for. IMO Itch.io doesn't do anything and kickstarters have not been very successful lately. Steam is the best place to sell, there still are some funding deals out there too. If you're game is big enough consider talking with the platforms (Xbox, Sony, Epic, Stadia) to see if someone will help you out. Can you explain your game and your current plans. IMO Kickstarter into Itch.IO is a bad plan just launching on Steam with no marketing would be more successful.
|
|
#
?
May 15, 2020 15:49
|
|
|
My game specifically is a casual multiplayer base building strategy, it's just the easiest way to describe it. It's meant to be played against friends while you chat, as it seems to me this is going on a lot on discord. So it's a PC game for sure, a lot of pointing and clicking and scrolling. The in my mind distribution model is give it away for free but only unlock multiplayer for some $$. Or maybe the free version you have to connect directly via IP, doesn't have friends lists, doesn't protect against cheating, that kind of thing.
|
|
#
?
May 15, 2020 19:54
|
|
|
Rocko Bonaparte posted:You might just try out a bunch of different engines and the languages that tend to go with them until you find a combination that clicks with your brain and is fulfilling. I'm saying that here without even listing any. If you don't have an immediate objective then you may even find fulfillment modding a game you already enjoy. That's a good idea. Back in my youth I spent a lot of time making maps in Radiant but back then you had to carve polygons by hand. It was interesting but incredibly time-consuming.
|
|
#
?
May 15, 2020 21:15
|
|
|
I'm someone who abandoned object oriented programming a long time ago after I finished post secondary. Now with game development I'm finding that although it's pretty necessary, I'm running into a lot of the same basic problems I always did before. So I want to pose one of my general questions about OOP and you guys can tell me what the best way to handle it is, I think I'd find it useful. I've got a rts-style scene with a bunch of stuff everywhere. While I pan and rotate the camera around, there are key things in the scene that need some UI on the screen related to those things. So therefore in those UI elements should I need to keep a reference to the object they are feeding the user information about? If it were something that was being built it needs to have a little bar that's showing progress of construction. Since the UI element is neither child nor parent of the object there is no formal relationship between the two things. The object is somewhere in the scene and the UI is somewhere within a totally separate viewport container essentially. My understanding is that creating a lot of persistent references to things is bad. But is this what I'm supposed to be doing? Saving a reference to the object in the UI element? Or, should I be only sending basic information to the UI via signals? This will be happening for potentially a lot of objects every frame.
|
|
#
?
May 18, 2020 03:33
|
|
|
Nolgthorn posted:My understanding is that creating a lot of persistent references to things is bad. This is not something I have ever worried about. It's nice if you don't have a massive web of everything knowing about everything else, because that makes it harder to make changes. But code that has a legitimate need to know about a specific game object should know about that game object! It absolutely makes sense for a build queue display to know about the structure that's doing the building, how far along your build is, how much it costs to add a unit to the queue, etc. Code is mostly about getting data to the logic that consumes that data. If you find yourself saying "I need to get this data to this logic, but this logic can't know about this data", then you have a fairly fundamental conflict that needs to be resolved.
|
|
#
?
May 18, 2020 03:38
|
|
|
I was thinking in order to eliminate the need for references to things in this specific case I could build a subsystem that just looks at all the objects in the scene, compiles the data that's needed every frame, and sends it to the UI all at once. Then the UI being a dumb data consumer would then spit it all out on the screen. But I have a feeling that would only work in this specific case. Like later when I click on a object and I need UI that interacts with it in more complex ways. So there'd be not much reason in avoiding the references for this, if I'm going to use references for that anyways.
|
|
#
?
May 18, 2020 03:48
|
|
|
Nolgthorn posted:I was thinking in order to eliminate the need for references to things in this specific case I could build a subsystem that just looks at all the objects in the scene, compiles the data that's needed every frame, and sends it to the UI all at once. Then the UI being a dumb data consumer would then spit it all out on the screen. UI is essentially a super user so be prepared to do things that feel icky, because good UI practices don’t always match not-UI practices. But you’re on the right path: what’s on the UI needs to be driven by the game, but it needs to know what it’s representing so it can tell it things like “hey I’ve been clicked”
|
|
#
?
May 18, 2020 04:06
|
|
|
I'm not convinced there's any benefit in the UI not knowing about the object. If it's like, a building progress widget, it's not going to be repurposed for something completely different that now has an invalid dependency. It's a specific use case. I'd rather be able to use "find references" on Building::GetProgressPct() to see where that's used ("oh, the progress widget grabs it in its update") than have to go through a morass of BuildingProgressUpdateDelegate assignments and unitID and poo poo like that. Generic code can be just as much as a pitfall as overly-specific dependencies. Adding an event dispatcher thing also introduces a dependency -- if nothing is generating BuildProgressUpdateEvents and sending them to the generic dispatcher, then the widget is never going to work. The API: is just more convoluted. I guess I consider unnecessary generality to be an instance of You Ain't Gonna Need It. The exception is when one piece is in the engine layer and another is in the game-specific layer, then you probably want to abstract the relationship between those components so you don't have that bleed into other stuff using that engine (or, maybe more regularly, so you don't have to make engine mods that make upgrading engine version more difficult)
|
|
#
?
May 18, 2020 06:46
|
|
|
Nolgthorn posted:I was thinking in order to eliminate the need for references to things in this specific case I could build a subsystem that just looks at all the objects in the scene, compiles the data that's needed every frame, and sends it to the UI all at once. Then the UI being a dumb data consumer would then spit it all out on the screen. I'm normally one of those OOP hippies so I'm going to say if it isn't too fussy to code for your circumstances then you might as well try it your way first since it sounds like your mind is wired up for that representation already. That being said, a lot of the OOP hippy stuff came out of UI stuff. Well, particularly a lot of design patterns that Xerox PARC devised came out of the necessity of dealing with user interfaces. Regarding, say, an RTS scenario where something is being constructed, this is pretty much just like keeping a progress bar going for some time-consuming task in a GUI. Some ideas: 1. Have something responsible for drawing progress based on an event that anything that generates progress would event. Attach when selected. Detach when deselected. I don't think I'm reaching to say this would be the common UI case that Normal Joe Application Programmer would do if this were just some application they were writing. Edit: ...and this is what I'm doing for UI elements in Unity right now too. 2. Feed all selected things that take progress to a subsystem that will do all the drawing in a big batch. This would be less normal as a UI approach but would still fit under something like an ECS setup and would be pretty efficient due to the batching. So it's still in the world of objects and the like. What you ultimately probably want to avoid is polling literally everything all the time to determine if you need to draw a progress bar for it or not.
|
|
#
?
May 18, 2020 07:14
|
|
|
In many cases you have an explicit dependency between two objects, and in this situation it's perfectly fine to have tight coupling between them. For example, in my game the PlayerRenderer needs a PlayerBody, since the renderer needs to know the location of the body all the time to place it on the right position on the screen. What I do here is pass the PlayerBody to the constructor of the PlayerRenderer, and let the renderer deal with getting the position of the body every frame. In the case of the UI, the dependency is not so explicit. It's not a good idea for example to pass the PlayerComponent to the UIComponent, since the components are tightly coupled and you create fragility when making changes or rewriting parts of the game. What I do in this case is that I have a game-wide message passing system, where each component can send messages and other components can subscribe to them. For example, if the player takes damage, the PlayerComponent emits a message to the EventSystem, such as code:code:
|
|
#
?
May 18, 2020 08:23
|
|
|
My head is still in enterprise development in a way, where you should always make the code as robust and easy to work with as possible and more or less who cares how often you need to look at everything. In game development this is not feasible because you're doing a lot of things every single frame. For this UI question I'm leaning toward signals/events that the UI would listen to, say "construction_started" and so on that would create a reference to the object within the UI which is then removed again when another signal, "built" or similar is fired. My concern is just that this will all be difficult to make changes to later. I guess there aren't many ways around that. Probably just a simple state would help. A signal called "state_changed" with states like "blueprint", "construction", "built" etc. That would clean it up. I'll try. Nolgthorn fucked around with this message at 13:24 on May 18, 2020 |
|
#
?
May 18, 2020 13:21
|
|
|
Thanks for the momentary freakout about a dead pixel on my newish monitor.
|
|
#
?
May 18, 2020 23:56
|
|
|
|
| # ? May 12, 2024 14:01 |
|
|
After working pretty much exclusively with JS for the last year for work (with some Python thrown in), I forgot how many good features C# has in newer releases.code:
|
|
#
?
May 21, 2020 02:49
|
|