this.myRigidbody.velocity = calculatedValue;
Do this in FixedUpdate, not LateUpdate. This way the physics engine can do it’s stuff (collision resolution, etc) but it’s only operative for one frame and it’s overwritten again on the next one.
In general since FixedUpdate can be forced to a constant frame rate I like putting all gameplay logic code there, so it’s not frame rate dependent.
Well, it could be cool! It is basically aiming to be a multiplayer Hades-like, but with more Gauntlet-style dungeons and combat, and some Divinity/Magicka environmental/elemental interaction comedy chaos. It is a long way from done. :)
Mostly it’s a little team we started getting together in Feb, there are five of us, all fairly ‘veteran’ Au devs.
We do need a couple more but it’s been hard to get good people. Especially since, and it’s a little embarrassing to talk about, we were brought on to do an NFT game… and we all know the feeling on those around here, and how that sector is going atm… :)
Throughout the year though, we aimed to make a game foremost, one we could easily pivot to something more ‘traditional’ in the event funding dries up on the Web3 side.
So yeah, that’s the project! Regardless of outcome, it’s been great fun hooking up with old mates again to do games, and making some great new contacts too.
This controller stuff is unrelated though as I’ve not been working directly on that myself. It’s more a personal project.
Ah that makes sense, the ‘speed’ thing confused me a bit, if it’s actually a velocity. :)
Great tip on the FixedUpdate game loops, too!
I sleep better last night, the thing I was pushing to do got done, so hopefully I’ll get a chance to play with this after work today.
Sounds like you’re having fun with it, @Profanicus! It’s amazing how addictive this can be.
Have you or anyone else here tried the UI Toolkit? I played around with it for a couple hours tonight. I love the idea of it. I really want a UI designer that’s completely separate from the game world, with WYSiWYG features that are more user-friendly than UGUI. But the implementation of UI Toolkit is very much a work in progress.
For example, I like to customize the Toggle button to use one texture for On and another for Off. That’s easy enough in UGUI, but in Toolkit I can’t seem to do it with the editor. Apparently it’s possible with code, but I’d have to learn UXML or whatever it is. Which I’m willing to do, but gah. Even a simple Button is a bit more convoluted. You can add hover and clicked properties, but it’s not as easy as with UGUI.
Still, I love the idea of a standalone UI maker in Unity. Every time I have to zoom out from Scene view to the gigantic Canvas view in UGUI, a little part of me pines for the fjords of Vulcan.
You are not wrong, but you can also put your UI in a prefab and go into prefab edit mode…
The distinction does not exist in Spanish (it’s speed and “speed vector”), so I tend to use the terms indistinctly, except when coding, obvs.
Heh, I didn’t even realize one could put the UI in prefab mode. But can you ever un-prefab it?
So I assume you use UGUI too? I wish the toolkit were more … finished.
Yeah you can always unpack prefabs back to groups of individual gameobjects.
We’re using UGUI but might change over once proper production begins (if it does!). The new system is nice, but more work to familiarise and get something going.
We are using the newer Input system though, but for personal stuff that seems like something that slows you down when prototyping too.
I saw some post about how you can call API directly to read keys/buttons and what not without requiring lengthy setup, and while that worked I couldn’t see any good equivalent to just doing a quick Input.GetAxis("Horizontal").
Ah I see! I’m likely having an in-lieu rest day today/tomorrow, so I’ll naturally be spending some of it working on some (basic) character controller stuff. :)
Is there a way to ‘refresh’ a render texture? I want to take a snapshot of a unit in a hex when I click it, then display it in a unit-selection box. I do this because the unit has dynamic stats that sit on top of its texture, so I can’t just put the texture in the box. (I suppose I could rebuild the unit in the box; i just thought a render texture would be easier.) The render texture looks great — except it’s always a hex behind where I clicked. I’ve tried calling Rendertexture.active twice; no help. I tried adding a coroutine to move the cam to update the render texture, then wait a frame, then repeat the camera position. No help.
I can work around this somewhat by having a render texture whenever I move the mouse, but then I get all sorts of unnecessary textures populating the selection box. Plus there is still a frame of lag when i move the mouse to the hex I really want to photograph.
Any suggestions?
I have yet to use render textures, but typically I’d start old-school and pre-render a preview image for all units myself. :)
Maybe even a scene/tool for that purpose, so you don’t need to manually do it when assets finalise.
Build a unit box as a prefab, with preview image and dynamic stats as UI elements on top.
Units should expose their data, so when clicked you can pull the stats and the preview image. Then access the unit box instance and update the data on it.
Maybe scriptable object for units, contains base data, model, preview image, that kind of thing.
Maybe I misunderstand how you want it to work though!
edit: Brackeys had a neat vid on how to hook into scriptable objects to make dynamic cards, I’d be thinking this kind of thing?
If you wanted to do render textures with no background guff, I think you’d need a separate camera for that purpose. Set it to only render certain layers like a ‘units’ layer or something.
Then make sure all the stuff you don’t want to render, is not set to that layer.
Thanks. I’ve actually watched that scriptable objects video several times already. My first effort with them was not successful, but maybe i’ll try again. But yes, an alternative to a render texture is a sprite with stats overlaying it. I started implementing that alternative yesterday.
I hadn’t thought of limiting the render texture to certain layers. Not sure how to do that, but it would be handy, because right now the render also captures my movement arrow (a line renderer).
I still wish I understood why the render texture lags behind whatever the cam is pointing at now. It’s always pointing at the last-viewed object, even after i move the rendercam. And yep i do use a dedicated render cam.
Oh cool, it popped into my head as it’s a neat vid, and scriptable objects make great ‘global data containers’.
Layers are pretty straight-forward.
Project Settings/Tags and Layers/Layers.Layer drop-down at top-right of the Prefab/GameObject.Rendering/Culling Mask select only that Units layer to be rendered. You can multi-select stuff in the drop down there if you want to include anything else.With the lagging, yeah we’ll need the experts to chime in as I’ve not actually used RenderTexture in a long, long, time and even then it was just playing around. :)
Probably hard without seeing some kind of code, too.
Ah, so that’s what culling mask does! Excellent! Thanks for the info.
I do plan to use render textures, for a minimap. For now, I’ve implemented a sprite-plus-text-overlay for the selection box, so I’m good. :-)
Now I’m working on combat algorithms. Fun!
Awesome!
I didn’t get much controller stuff done yet, turns out we got feedback on this thing we were crunching on quicker than expected, so now I’m back at it working on next phase (combat demo)!
Game dev either way, so no complaints. :)
So how much UI do you all do in the early stages of a project? I’m surprised how often I feel the compulsion to add UI. I’m working on a 2D strategy game, and I’ve got more than enough UI for me to run and test my movement and combat. Even so, I spent a couple hours yesterday adding pretty ‘attack from this arrows’ and red highlights around attacking units, plus I also did a mockup of a prettier combat UI. I should be working on combat mechanics and AI!
Also, for this game I’m using tiles and a procedurally-generated map. I have in mind a sort of Shadow Empire lite. I hope to build on this for a more traditional historical hex-and-counter wargame. For a historical game, I’d want to make a pretty bitmap map. Is the best practice then to chop that into tiles, or just to overlay a hex grid over it?
For a hobby project, work on whatever keeps you motivated.
I personally hate working on UI and always delay it as long as possible. But also, once I finally start working on those little details it’s amazing how energizing it is and how much of an impact even the tiniest bit of polish has.
This.
You have no milestones/deadlines I assume, so your biggest danger is stopping because you lose interest. Or the other common dangers: a) you have some great new idea you’d rather do, and b) constantly refactoring/redoing systems as your knowledge grows. Looking at old stuff is embarrassing. :)
For UI I tend to like having systems ‘in place as needed, but proxy’. Not that I’ve done much UI lately, but traditionally I’ll add rough UI so systems that ping it are obviously working.
With the proviso that I’ve never done one, I think a bitmap is fine as a base if you want fully unique hand-drawn maps. There is no technical reason for requiring the visual component to be tiles I don’t think, given your tiles would each be a unique image? Maybe something ‘max texture size’ related, depending on resolution?
You just need some visual way to define the terrain type for each hex. Most games that do hand-drawn maps seem to use ‘regions’ rather than hexes though…
But you’re locking yourself into constantly updating a bitmap to make any terrain tweaks, then updating the tile data for any changes, rather than shuffling pre-made tiles around in-editor.
Thanks for those replies, @jsnell and @Profanicus . Yep, this is a hobbiest project, and so yeah, I guess I should do what I like doing. I thought I would hate UI, but I actually find it kind of fun. I get to bust out Photoshop and mess around with rounded rectangles and beveled edges and such. I’m also using the new input system, and I find that kind of fun too. Still, it’s amazing how much work it is. Then again, everything in making games is a lot of work.
Profanicus, good thoughts on maps. I hadn’t thought about the hassle of redoing hard-coded hexes if the underlying bitmap changes. I will think on it more.
My current project has a huge mass of tiled prefab hexes, all game objects. I was very wary of making each hex-tile a game object, but then I read a series of posts by the guy who developed Hex of Steel, a WW2 game, and that’s the approach he took. He has huge maps and not much slowdown. So far my performance is excllent with smaller maps. My only reservation is that with each hex being a prefab, it’s harder to get references to stuff in other scripts. I find myself using “Gameobject.Find” more often than I’d like.
I think in these games you would typically have some kind of singleton map manager that contains your hex data structure, where you can pass in hex co-ords and can get back neighbours, terrain type, and other data? Just find a way to also be able to return the gameobject at that hex.
Like maybe expose a transform for the map, drag in the ‘root’ transform (which would contain all the map game objects underneath it), and then have the manager work out each object’s hex co-ords.
The manager then stores that reference inside its data structure, such that if you know the hex co-ord, you can pull the associated game object reference from the manager as well as the other stuff.
Kind of hard to explain, and just the first thought that popped up! :)