It mainly comes down to performance. If it's small/resource-safe enough that having everything loaded at the same time doesn't cause lag/slowdown/framerate issues then it's fine to keep it all loaded. But if you're seeing even a little bit of performance issues due to resource drain, you're better off just loading what you need. I know Unity has been improving its ability to stream in levels/areas/content, but I'm not an expert so I can't say how effective/efficient their systems are compared to other engines.
Definitely break it up. For one, there are lighting issues with huge meshes, and there's a vertex limit.
If you're interested I'm working on a procedural terrain generator that uses the DOTS system to generate terrain tiles as entities. Coincidentally it creates a big mesh (which uses a trick to get past the vertex limit) for the distance, then loads streamed entity tiles on top.
If you don't go procedural, you can use the subscene workflow to similar effect.
The impact on speed is HUGE.
One thing I've not explored is using the built-in terrain, and that may actually cover your needs.
Definitely break it up. For one, there are lighting issues with huge meshes, and there's a vertex limit.
If you're interested I'm working on a procedural terrain generator that uses the DOTS system to generate terrain tiles as entities. Coincidentally it creates a big mesh (which uses a trick to get past the vertex limit) for the distance, then loads streamed entity tiles on top.
If you don't go procedural, you can use the subscene workflow to similar effect.
The impact on speed is HUGE.
One thing I've not explored is using the built-in terrain, and that may actually cover your needs.
Do you move everything back to 0,0 when the player enters a new tile, or do you set each tile at a position such that the player doesn't have to be reset?
(I know floating point problems accumulate at large position values, but I don't have concrete numbers about where it starts to matter)
Do you move everything back to 0,0 when the player enters a new tile, or do you set each tile at a position such that the player doesn't have to be reset?
(I know floating point problems accumulate at large position values, but I don't have concrete numbers about where it starts to matter)
I've come across the effect you mentioned (mainly with rotation)but iirc I was badly scaling everything too large. (Do not scale anything, at all, as you might get shader issues. I did!)
If your distances are reasonable it should be OK.
I have an endless runner where the planet is a rotating barrel 4000 units in radius, I've moved the barrel down 4000 units and have the player at 0. This does not seem to be a problem so far and rotation would be the first thing where the fp issue would show up.
In all of my other games I move the player through a fixed world, moving the 'tile' entities around is not worth the hassle imho.
Again, there's built-in LOD functionality you can use to stream the meshes or have the tile not shown. I've done it with my own script and even a little of it goes a long way.
One issue I have come across is that Unity forces memory cleaning even when it's not needed, with a big bump in processor activity. This is not a problem with the gameobject > entity workflow.
How it all comes together:
before starting: set up classic prefabs with LOD and meshes. Save in the Resources folder.
1: generate the terrain data
2: instantiate gameobject 'tiles' from 'classic' prefabs and apply any modifications (i.e. texture changes, combining etc.)
3: for each tile create an entity prefab (you can find the script for this in the ECS/DOTS example files, it's SpawnerFromMonoBehaviour) and add to list
4: instantiate the entityManager (from same script) and move it to the first position with SetComponentData
5: from the terrain data, grab the tile type, instantiate the corresponding entity prefab (entityManager.Instantiate(prefablist[x])
6: move the entitymanager to the next position and repeat
I'm still exploring variations on this theme...
If you want a much larger world, it wouldn't be hard to create a bunch of meshes, create entity prefabs from the meshes, and instantiate the entitites when you reposition the player.
Again, the other way to do it is to have a landscape prepared and divided into subscenes.
Or, mesh tools for DOTS are not available as far as I've followed it, but they might come along. In that case you can simply apply distortion to a few meshes. Instead of moving meshes around you then apply distortion from mesh 1,0 to mesh 0,0 and relocate the player whenever he comes to the edge.
Hardcore? Apply distortion to a single mesh through a scrolling shader.
Do you move everything back to 0,0 when the player enters a new tile, or do you set each tile at a position such that the player doesn't have to be reset?
(I know floating point problems accumulate at large position values, but I don't have concrete numbers about where it starts to matter)
I've come across the effect you mentioned (mainly with rotation)but iirc I was badly scaling everything too large. (Do not scale anything, at all, as you might get shader issues. I did!)
If your distances are reasonable it should be OK.
I have an endless runner where the planet is a rotating barrel 4000 units in radius, I've moved the barrel down 4000 units and have the player at 0. This does not seem to be a problem so far and rotation would be the first thing where the fp issue would show up.
In all of my other games I move the player through a fixed world, moving the 'tile' entities around is not worth the hassle imho.
Again, there's built-in LOD functionality you can use to stream the meshes or have the tile not shown. I've done it with my own script and even a little of it goes a long way.
One issue I have come across is that Unity forces memory cleaning even when it's not needed, with a big bump in processor activity. This is not a problem with the gameobject > entity workflow.
How it all comes together:
before starting: set up classic prefabs with LOD and meshes. Save in the Resources folder.
1: generate the terrain data
2: instantiate gameobject 'tiles' from 'classic' prefabs and apply any modifications (i.e. texture changes, combining etc.)
3: for each tile create an entity prefab (you can find the script for this in the ECS/DOTS example files, it's SpawnerFromMonoBehaviour) and add to list
4: instantiate the entityManager (from same script) and move it to the first position with SetComponentData
5: from the terrain data, grab the tile type, instantiate the corresponding entity prefab (entityManager.Instantiate(prefablist[x])
6: move the entitymanager to the next position and repeat
I'm still exploring variations on this theme...
If you want a much larger world, it wouldn't be hard to create a bunch of meshes, create entity prefabs from the meshes, and instantiate the entitites when you reposition the player.
Again, the other way to do it is to have a landscape prepared and divided into subscenes.
Or, mesh tools for DOTS are not available as far as I've followed it, but they might come along. In that case you can simply apply distortion to a few meshes. Instead of moving meshes around you then apply distortion from mesh 1,0 to mesh 0,0 and relocate the player whenever he comes to the edge.
Hardcore? Apply distortion to a single mesh through a scrolling shader.
Wow, thanks! I appreciate the data and analysis
At this stage, I'm just trying to get the platforming feel right on a 2D game, so I don't expect my world is going to be that huge. I have 1 unit = 1 meter. So a Castlevania-sized map is probably 45x60 rooms, at 9-ish meters tall, rounded to 10, makes it... 800 x 450 units?
If I really spread things out for a faster platforming style, that's still only 1600x900 units. Huh, that's the first time I've done that math, and it's less than I thought.
GDQ has been immensely entertaining, as always, but that didn't stop me from getting a lot of work done this week because sometimes you just gotta work on making a game instead of watching people play them, however well. On a meta-level I also practiced getting into the habit of making micro-commits to my Git repository; one feature's worth of changes per commit instead of a weekly rollup of multiple things that, assuming I ever actually wanted to revert them, would take out multiple features at the same time were I to do so.
From the commit log:
- I tweaked the logic that handles what happens when a collision volume experiences a blocking collision, which was intended to keep from allowing an immediate re-collision due to overlap but could actually introduce one instead in some corner cases.
- I also gave up and accepted that due to mathematical precision problems, an immediate re-collision due to overlap after moving a collision volume will happen in some circumstances, and added a test for whether the blocking collision we're resolving is an overlap interaction between collision volumes that just collided with one another. In this case, no record of the collision is written but it's handled normally otherwise. (This prevents a collision volume from storing multiple records of the same collision at the same timestamp.)
- Observed that performing the bounding box tests outside of the collision detection methods was marginally faster, so I kept it that way.
- Collision events are now stored in an array that's globally available and collision events now store their "next event for entity" references as indexes into that array rather than real actual references. (This is because reference values don't play nicely with the serialization engine.)
- The depenetration phase (which attempts to identify collision volumes that are overlapping with other volumes that block them, either because someone else moved them around outside of the collision detection system or because the collision system goofed) was heavily revised. Previously it checked for any possible overlap, moved the affected volumes, and then iterated until no further overlaps were detected (an entity that gets moved a maximum number of times is flagged as "Crushed" and automatically fails all collision tests). The new approach performs the initial test for all overlaps, but then only tests pairs of entities for overlap that exist in the broadphase grid nodes that moving volumes move into/through. This seriously cut down the number of tests performed.
- I installed a Roslyn analyzer from Microsoft that issues warnings when you do things that might unintentionally cause heap allocations, like boxing operations on structs. This produced a lot of false positives, but also helped me catch a case that was making the GC go berserk. (https://github.com/microsoft/RoslynClrHeapAllocationAnalyzer)
- I made my broad-phase system thread-safe, and subsequently made almost everything in the collision detection system use the threaded work system. The result? My 5000-passive-object-5000-moving-object stress test went from an average frame time of 65 milliseconds to an average frame time of 64 seconds. It's as good as it's going to get, I think.
This week, I'm putting the finishing touches on the collision detection system (depenetration can be multi-threaded, but not as trivially as other steps) and going back to the level editor, which fell into a state of disrepair after I got into all this stress-testing nonsense.
My favorite musical instrument is the air-raid siren.
It is possibly the biggest hack and maintenance nightmare I've ever seen. A lot of it is copy-paste-edit like in that bit
It's something you can get away pretty much only in throwaway game dev where you write it once, never reuse it and never have to change anything
I forget if VVVVVV was one of the games ported this way, but I was under the impression that this code was machine generated from a flash script or something like that.
That's still not awesome to maintain, but it explains the mind boggling boilerplate going on there
What would be a better way to deal with a big set of states and variables?
Say, an x,y array of fields corresponding to an interface where different button coordinates do different things based on states?
Asking for a friend.
Make your x and y conditions hashable into unique keys and register actions to into that lookup table. This way any action just calls your state machine and is redirected to what it needs to do. The maintenance for this is simply looking the the registration of a key action pair.
The action itself can be a function pointer or just the information necessary for the next step to do the right thing. But this way the state machine itself is generic and reusable.
In the case of VVVVVV they could have a table with all those case numbers that are assigned to triggers in the world but each entry in the table would just need which script to run, is the trigger removed or not and maybe a custom action for those special cases that did extra stuff. The switch statement is replaced by one method call looks like the piece of code that was copy/pasted 1000 times plus a smaller switch statement for the special actions.
If every state truly executes a unique piece of code that cannot be generalized then the registration/lookup is still better than a switch statement. Look at how a windows application handles the menu bar. Each entry executes a custom piece of code. The menu itself from the visual editor get turned into menu_id/function pointer pairs in the generated code. In your code you implement those functions one by one. So when a menu item is clicked that menu_id gets converted into a function pointer and executed.
I finalized my UE4 blueprint interface to a Twine Interpreter. I decided to use local variables as the way to communicate between Unreal blueprints and the twine scripts. Now there can be dialog results/options that give you stuff, unlock new map areas, and mark certain map areas.
Also I rearranged a bunch of dialog in Twine. Doing this by editing spreadsheets or JSON would have a taken a lot longer, so I should give some money to the twine guy (Chris Klimas)
Ironically, it isn't GDQ week itself that kills my productivity, but the week afterward; during the event, there are breaks between runs when I can focus on something else for at least ten minutes at a time. But in the week after, I have VoDs that I can play one after the other and just throw all my attention at that.
But.
I did get two things worked on this week:
First, I updated the Project Editor to use the kind of model I should have been using from the start to open sub-editors. Previously I had an individual control to display each hard-coded content type (animations, characters, and levels), which manually opened the editor for that content type. I switched to a model where I keep a map of object types to editor types that can be arbitrarily filled with new mappings in the constructor. Then I just added a tree view that displays the contents of the content folder that you can select files out of and it just opens the right editor for that type. I still need to add the "New item of this type" and "delete item" logic, but the interface is much smaller and more general now.
Then, because I am an addict, I took one last tilt at the windmill and tried to parallelize the "resolve collisions" phase of the collision detection system. I discovered, through a series of hilarious bugs involving a use-after-free, that the only part of that entire operation chain that could safely be performed outside of the main lock was a pair of "add to end of list" operations that became more complicated due to the fact that I could no longer guarantee that the lists I was adding to the end of were well-ordered. So, for real this time, next week's work, assuming there is any, is going to involve anything but my collision detection system.
My favorite musical instrument is the air-raid siren.
+2
Options
SurfpossumA nonentitytrying to preserve the anonymity he so richly deserves.Registered Userregular
edited January 2020
So I'm mucking about with this idea I had, trying to create something where you can grab cards or tiles, drag them through another thing to apply an operation to them, and then drop them off in a target spot to play them.
Here's a post describing the idea:
Due to my recent and nearly crippling Solitairica binge, I've started idly plotting out a game based on factoring polynomials. Some main ideas based on this incredibly garish mockup (just to mess around with potential layouts):
1. the "enemies" either are or produce polynomials into the target (4)
2. sliding stuff up the three "attack" paths (2) performs the corresponding operation on the target (4): addition, subtraction, and division
-- division attacks can fail, the others cost resource
3. you draw cards into your hand (1) and can either
-- slide them directly up an attack path (2)
-- drag them through an operation into the bay (3), where they perform the operation on whatever is stored in the bay
4. you can drag whatever you have stored in the bay (3) up an attack path
5. when you've reduced the target as much as you can, you can clear it by swiping it off the screen
-- this will either generate or cost resource based on how much is left
The blue bits are potential popup menu locations for items/abilities/menus, health etc. go on the left.
I'm thinking maybe each level can have additional polynomials pile up, and there could be multiple storage bays so that you can plan ahead.
Now to never actually get around to coding any of it.
My brain has gotten completely hung up on the scaling of things. I desperately want to use Unity's rect transform stuff to make each collider take up a percent of the screen so that everything resizes dynamically, but... I guess it's only really meant for UI elements, not colliders and stuff?
Anyway! I'm beginning to suspect that my approach is Not The Best, so I'm wondering if anyone has any suggestions.
The X and Y are tiles to drag around, the space in the middle is "bay" you can drag the tiles into to "store" them and then drag the bay, up top is the target, and the operators in the middle are what you drag things through to apply an operation. Here's a shot of the hierarchy:
So... any good tutorials or reading that I should look into? I just don't know if I should be working with the canvas to make a card game with some physicality, or if I should be working entirely in 3D with colliders and stuff, or what questions I should even be asking.
Anyway this page keeps freezing so that's all I guess.
edit:
Note to future self: google more things before opening up Unity.
...except... everything is wonky on the actual webpage? The "/" panel isn't registering stuff and the others have all swapped their functionality, and the top target doesn't do anything anymore? Weird, it all works in Unity and the panels that are registering seem to have accurate bounding boxes so... what the heck.
omg apparently deleting a tag works fine inside Unity, but if you build it then the array of tags still has the deleted tag in it or something (and objects end up with the wrong tag) until you re-open the project.
Zavianuniversal peace sounds better than forever warRegistered Userregular
The Unity 3D platformer engine Ive been using, Corgi Engine, just added a new Rooms feature for Super Metroid/Castlevania style games; I've been slowly learning the ropes of Unity but having an engine with a lot of built-in features has really helped me out (my programming/scripting skills are rather minimal). Ive been having a lot of fun today messing around with the new Rooms feature though and thought it was worth sharing https://www.youtube.com/watch?v=6-RsgvG_ids
The Unity 3D platformer engine Ive been using, Corgi Engine, just added a new Rooms feature for Super Metroid/Castlevania style games; I've been slowly learning the ropes of Unity but having an engine with a lot of built-in features has really helped me out (my programming/scripting skills are rather minimal). Ive been having a lot of fun today messing around with the new Rooms feature though and thought it was worth sharing https://www.youtube.com/watch?v=6-RsgvG_ids
Oh, nice! I bought Corgi when it was on sale, but it didn't work for my platformer feel. I might revisit it if it keeps getting new features like that!
Is anyone else going to participate in the GGJ this month? I'm feeling pretty caught up in my own head on my current projects, and I'm thinking I should join a team doing something small.
I bought Control and have been playing it compulsively all week, so I didn't get much done.
The one thing I did this week was make a very small revision to my "simple job" class that I use to coordinate multi-threaded tasks. To start from the beginning, I wrote a budget thread pool that I'm calling the "work coordinator" which I use to do parallelized work. You hand the work coordinator a collection of job objects, and it hands them out to however many worker threads it has, which then call a method called Process() on the job and mark it as completed. The main thread (the one that called into the work coordinator to begin with) blocks until all the jobs are done. A "simple job" is one that operates on a range of indexes in the buffered entity query of the system class it was defined in, such that the only thing you have to define in it is how it processes the entity at its current index. Ultimately what that means is after defining the per-index operation within the simple job class, setting off the parallelized work is one-liner like this:
However, besides modifying the query buffers, there will occasionally be "out of band" writes into the component storage-- like, if there's a component that makes child entities spin around their parent, the child entities aren't readable or writable through the main query, they have to be written through my old indirect ("write this new component value to that entity") writing system. However, one of the features I wanted in my architecture is "same inputs, same outputs", meaning that those out-of-band writes have to appear in the same order, since there's a possibility (though I'd hope to avoid this situation) that two components might have a reference to the same remote entity, and therefore the order of their changes matters. But since jobs are being processed in parallel, I can't guarantee that they'll be registered to the component storage in the same order (and the component storage isn't thread-safe in that respect either). So, I added a system to the Simple Job where you can enqueue out-of-band writes and apply them only after the jobs are all done, which winds up applying the transformations in a reliable order.
I've accrued a number of microtasks that I want to knock out before I proceed to writing some actual game-logic components and systems, so this week will be a maintenance week (and, if Control doesn't last me the whole weekend, likely mean something of a small novel for next week's report).
My favorite musical instrument is the air-raid siren.
I wrote a bunch of stuff to let you start NPC quests and check when you've finished them. My next goal is to set up the complete sequence of quests to make up the entire game "plot". The quests themselves are just stubs for now and I can fill them in later.
Here's my floaty icon that says "this NPC wants to talk to you". I thought about copying the WoW exclamation mark but that seemed TOO blatant.
God I'm such a huge Spiderweb fan. I even was a Scorched Earth Party fan for the bit of time another milqetoast 20 year old would have been an objectivist.
That was such a great vid, I wrote all the highlights (to me) down.
-get into a trough in the business cycle-"real artists ship"-if you double the time you spend perfecting, you need to double your sales to cover for it-be lucky (at one point someone will have to step up to vouch for you)-have a professional accountant-"my story was going to be about two things: making a back catalogue and getting myself some fans."
-If it's a decent icon that looks like a wolf, in the next game it will still look like a wolf. I look at the worst 25% of a game and I redo that. I'm the leanest and meanest.
-opengameart.org ; freesound ; shockwave .sound-pick up an evergreen genre, a new genre becomes underutilised every year-there's nothing more furious than a scorned fan-"if something stops me from working, I cut it out mercilessly"-people keep telling me my graphics suck, i put money in, people keep telling me my graphics suck. that was the last time I ever made an effort-'the only thing that can decide what the market likes is the market'
-LESSON: BE THE EASY PERSON TO WORK WITH
-there is one prerequisite to make it as an artist: "you should always make your art so compelling that people forget to pee". (this is hard)
-don't quit your day job until you can afford to
-when you make a change you need to make sure the thing you bring adds fans to replace the ones you'll lose
-a good mailing list is a button that you press and a thousand dollars fly out. Always reply to fans, if anyone likes your stuff enough to mail you, take the effort tot reply.
-if at all possible, own the source code for your stuff. If you own your source code, find a hungry student out of college, give him a basket of dollars, pay him to make sense of your mess.
Aaaanyway, I'm getting close to releasing Endless Azure and so I was wondering how much of a hassle it would be to add a credits shop to the game. (Using Unity, for iOS). Does anyone have experience with this?
I want a designer to be able to create a standard Toggle and point its OnValueChanged event at a method on one of my MonoBehaviour classes. Then the method called by that event should take a static value for that Toggle (so that each Toggle may pass in a different value, designated by the designer), and then I want the method to respond to the combination of toggle state and that static value.
This also applies to a situation with Button objects, in which I want to pass in the Button object to change its appearance based on a state in my MonoBehaviour, but I want that Button to also pass in a value written by the designer.
Is there a way to get both toggle state (or the UI object itself) and the static value?
I want a designer to be able to create a standard Toggle and point its OnValueChanged event at a method on one of my MonoBehaviour classes. Then the method called by that event should take a static value for that Toggle (so that each Toggle may pass in a different value, designated by the designer), and then I want the method to respond to the combination of toggle state and that static value.
This also applies to a situation with Button objects, in which I want to pass in the Button object to change its appearance based on a state in my MonoBehaviour, but I want that Button to also pass in a value written by the designer.
Is there a way to get both toggle state (or the UI object itself) and the static value?
I want a designer to be able to create a standard Toggle and point its OnValueChanged event at a method on one of my MonoBehaviour classes. Then the method called by that event should take a static value for that Toggle (so that each Toggle may pass in a different value, designated by the designer), and then I want the method to respond to the combination of toggle state and that static value.
This also applies to a situation with Button objects, in which I want to pass in the Button object to change its appearance based on a state in my MonoBehaviour, but I want that Button to also pass in a value written by the designer.
Is there a way to get both toggle state (or the UI object itself) and the static value?
(I rolled my own touch-based button system because of Unity UI issues with transparency)
Thanks for the link!
That seems to use the static value approach, but it doesn't pass in the button itself. Populating a monobehaviour public value in the inspector with a button / toggle would give me some of that functionality, but it still requires me to write a new script for every menu.
I'm looking for an approach that a designer could use in any combination without my intervention.
Hmm, though that did give me an idea for trying it with a Scriptable Object...
I said I was going to give y'all a small novel but I'm in no mood. At least I have four things to report:
1. I fixed the way the matrix I pass into the sprite renderer is calculated such that it now correctly centers on the camera. I actually don't know how some of the math works out, but it produces the desired result so ¯\_(ツ)_/¯
2. Rather than using the extents of the window for rendering purposes, I now actually render to a texture with the configured "native" resolution and then render that to the screen with one of two stretching strategies: cap out on one dimension and stretch the same amount on the other, or only scale up by the minimum whole-integer factor that the window will support (falling back to the former strategy if the ratio is less than 1).
3. I started work on the "Play This Level" feature for the Level Editor. The idea is to be able to just go into the File menu and click "Play This Level" to boot the game up with the level being edited. You can already pass some command-line arguments into the game application to override default settings, but I thought it was going to be harder to do; I thought I might have to get the path to the executable and launch another process instance and wait on it to exit, but I forgot that games in Monogame are just a whole class unto themselves, and the Project Editor has to be re-built for each game, the actual game class is in scope to be instantiated directly. So I can just put some feigned command-line arguments together, instantiate the game class, and off it goes.]
3a. While doing the above, I discovered that the Project Editor was busted in a lot of ways thanks to a number of changes I made previously. I unbusted it.
4 the Future: I had an epiphany about how to parallelize the handling of collision detection events, but it entails completely re-thinking the whole approach. The essence of it is that I previously treated collision events as unique; for each pair of collision volumes in play; a collision between two collision volumes would be a single object referred to by both of them. But in actual practice any given collision volume only cares about the collision events that apply to itself. No collision volume is going to need to know what the next event that applies to the other entity involved in one of its own events is. So it may be possible to parallelize by creating a timeline of collisions for each individual collision volume and selectively negating the portions of each one that might be affected by a blocking event. So yeah, I'm probably going to wind up having one more go at it this weekend. I'm an addict.
My favorite musical instrument is the air-raid siren.
+4
Options
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
After a long long break and the biggest botch in history with WC3:Reforged... I want to jump back in to development because I have some neat ideas for projects involving multiplayer.
I'm used to Unity still so I think I'll stick there, but a quick read suggests that Unity's Multiplayer options are being deprecated and something new called 'Connected Games' is coming soon. Anyone have anything concrete on that? Should I wait for Connected or just go with UNet/Mirror for now?
It is possibly the biggest hack and maintenance nightmare I've ever seen. A lot of it is copy-paste-edit like in that bit
It's something you can get away pretty much only in throwaway game dev where you write it once, never reuse it and never have to change anything
I hear the "write once, change never" thing all the time about Game Dev but I don't see how it can be true. I've work on some very simple games and I still find myself iterating like hell on that code once I get some player feedback.
I work professionally as a programmer, mostly on full stack software products and I really emphasis being able to change my code through good architecture and tests. My limited experience with game code had me changing even more code then I do at my day job. Being able to introduce, adjust and throw away features quickly and without breaking things made "good" code really important.
That being said, real artists ship and VVVVVV is a great game. I'd love to have more insight into his design and iteration workflow. Maybe he is just copy and pasting mass amounts of code and that just works for him.
(The 'enabled = false' was there to see if I was in actual fact targeting anything even remotely like the button component I wanted but yes indeed I was targeting that very button)
After a long long break and the biggest botch in history with WC3:Reforged... I want to jump back in to development because I have some neat ideas for projects involving multiplayer.
I'm used to Unity still so I think I'll stick there, but a quick read suggests that Unity's Multiplayer options are being deprecated and something new called 'Connected Games' is coming soon. Anyone have anything concrete on that? Should I wait for Connected or just go with UNet/Mirror for now?
The newest hotness is Unity NetCode. Its built on top of the new DOTS framework and is currently still in preview. There is also the Dots Sample if you want to dig through a working multiplayer project with a lot of the new bells and whistles.
It is possibly the biggest hack and maintenance nightmare I've ever seen. A lot of it is copy-paste-edit like in that bit
It's something you can get away pretty much only in throwaway game dev where you write it once, never reuse it and never have to change anything
I hear the "write once, change never" thing all the time about Game Dev but I don't see how it can be true. I've work on some very simple games and I still find myself iterating like hell on that code once I get some player feedback.
I work professionally as a programmer, mostly on full stack software products and I really emphasis being able to change my code through good architecture and tests. My limited experience with game code had me changing even more code then I do at my day job. Being able to introduce, adjust and throw away features quickly and without breaking things made "good" code really important.
That being said, real artists ship and VVVVVV is a great game. I'd love to have more insight into his design and iteration workflow. Maybe he is just copy and pasting mass amounts of code and that just works for him.
IIRC, VVVVVV was originally made in flash, and that infamous switch statement was actually the result of an export tool.
I don't know how much work they did on it *after* the export, but that must be like shutting all your mess in a closet and then being buried alive next time you open it
I spent most of this week with a head cold that left me with only marginal amounts of brain to apply to anything, much less the fragile practice of computer programming, so I only got a few things done this week, mostly bugfixes that don't bear documenting.
Last week I mentioned that philosophically it would be easy to implement the "Play This Level" feature for my level editor. Well, philosophy is mostly bullshit, so I had the rare pleasure of encountering a type of exception message that I've never seen before; it turns out that Windows doesn't like it when you try to register a message pump twice on the same thread, and the Game class in MonoGame registers a message pump in its Run() method when built for Windows, so you can't just new one up and run it from a Windows Forms application, at least on the main thread. I was not confident enough that putting it on another thread would solve the problem (in fact, the idea didn't even occur to me at the time), so I went with my initial plan of just running the game as a separate process entirely. Which, because that was what I was building toward from the beginning, was still relatively easy to do, so now you can say "Play This Level" and jump straight into gameplay out of the level editor. Huzzah.
Plans for this week involve evicting this damn rhinovirus from my head and then continuing down the checklist of minor concerns.
My favorite musical instrument is the air-raid siren.
It is possibly the biggest hack and maintenance nightmare I've ever seen. A lot of it is copy-paste-edit like in that bit
It's something you can get away pretty much only in throwaway game dev where you write it once, never reuse it and never have to change anything
I hear the "write once, change never" thing all the time about Game Dev but I don't see how it can be true. I've work on some very simple games and I still find myself iterating like hell on that code once I get some player feedback.
I think the emphasis is more on the reuse bit - most of the reusable pieces are in the game engine, so what you end up writing is specific to the game and will never be used in a different project. So some sins are a bit more forgivable because you know you don't need to make the code flexible. As an example, I have a tendency to write cumbersome data storage interfaces for my games, and it was freeing when I realized that as the dev, I knew I'd only ever use SQL, so I code code straight to it and not worry about needing to pivot to Mongo or whatever.
0
Options
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
Posts
If you're interested I'm working on a procedural terrain generator that uses the DOTS system to generate terrain tiles as entities. Coincidentally it creates a big mesh (which uses a trick to get past the vertex limit) for the distance, then loads streamed entity tiles on top.
If you don't go procedural, you can use the subscene workflow to similar effect.
The impact on speed is HUGE.
One thing I've not explored is using the built-in terrain, and that may actually cover your needs.
Do you move everything back to 0,0 when the player enters a new tile, or do you set each tile at a position such that the player doesn't have to be reset?
(I know floating point problems accumulate at large position values, but I don't have concrete numbers about where it starts to matter)
I've come across the effect you mentioned (mainly with rotation)but iirc I was badly scaling everything too large. (Do not scale anything, at all, as you might get shader issues. I did!)
If your distances are reasonable it should be OK.
I have an endless runner where the planet is a rotating barrel 4000 units in radius, I've moved the barrel down 4000 units and have the player at 0. This does not seem to be a problem so far and rotation would be the first thing where the fp issue would show up.
In all of my other games I move the player through a fixed world, moving the 'tile' entities around is not worth the hassle imho.
Again, there's built-in LOD functionality you can use to stream the meshes or have the tile not shown. I've done it with my own script and even a little of it goes a long way.
One issue I have come across is that Unity forces memory cleaning even when it's not needed, with a big bump in processor activity. This is not a problem with the gameobject > entity workflow.
How it all comes together:
I'm still exploring variations on this theme...
If you want a much larger world, it wouldn't be hard to create a bunch of meshes, create entity prefabs from the meshes, and instantiate the entitites when you reposition the player.
Again, the other way to do it is to have a landscape prepared and divided into subscenes.
Or, mesh tools for DOTS are not available as far as I've followed it, but they might come along. In that case you can simply apply distortion to a few meshes. Instead of moving meshes around you then apply distortion from mesh 1,0 to mesh 0,0 and relocate the player whenever he comes to the edge.
Hardcore? Apply distortion to a single mesh through a scrolling shader.
Wow, thanks! I appreciate the data and analysis
At this stage, I'm just trying to get the platforming feel right on a 2D game, so I don't expect my world is going to be that huge. I have 1 unit = 1 meter. So a Castlevania-sized map is probably 45x60 rooms, at 9-ish meters tall, rounded to 10, makes it... 800 x 450 units?
If I really spread things out for a faster platforming style, that's still only 1600x900 units. Huh, that's the first time I've done that math, and it's less than I thought.
GDQ has been immensely entertaining, as always, but that didn't stop me from getting a lot of work done this week because sometimes you just gotta work on making a game instead of watching people play them, however well. On a meta-level I also practiced getting into the habit of making micro-commits to my Git repository; one feature's worth of changes per commit instead of a weekly rollup of multiple things that, assuming I ever actually wanted to revert them, would take out multiple features at the same time were I to do so.
From the commit log:
- I tweaked the logic that handles what happens when a collision volume experiences a blocking collision, which was intended to keep from allowing an immediate re-collision due to overlap but could actually introduce one instead in some corner cases.
- I also gave up and accepted that due to mathematical precision problems, an immediate re-collision due to overlap after moving a collision volume will happen in some circumstances, and added a test for whether the blocking collision we're resolving is an overlap interaction between collision volumes that just collided with one another. In this case, no record of the collision is written but it's handled normally otherwise. (This prevents a collision volume from storing multiple records of the same collision at the same timestamp.)
- Observed that performing the bounding box tests outside of the collision detection methods was marginally faster, so I kept it that way.
- Collision events are now stored in an array that's globally available and collision events now store their "next event for entity" references as indexes into that array rather than real actual references. (This is because reference values don't play nicely with the serialization engine.)
- The depenetration phase (which attempts to identify collision volumes that are overlapping with other volumes that block them, either because someone else moved them around outside of the collision detection system or because the collision system goofed) was heavily revised. Previously it checked for any possible overlap, moved the affected volumes, and then iterated until no further overlaps were detected (an entity that gets moved a maximum number of times is flagged as "Crushed" and automatically fails all collision tests). The new approach performs the initial test for all overlaps, but then only tests pairs of entities for overlap that exist in the broadphase grid nodes that moving volumes move into/through. This seriously cut down the number of tests performed.
- I installed a Roslyn analyzer from Microsoft that issues warnings when you do things that might unintentionally cause heap allocations, like boxing operations on structs. This produced a lot of false positives, but also helped me catch a case that was making the GC go berserk. (https://github.com/microsoft/RoslynClrHeapAllocationAnalyzer)
- I made my broad-phase system thread-safe, and subsequently made almost everything in the collision detection system use the threaded work system. The result? My 5000-passive-object-5000-moving-object stress test went from an average frame time of 65 milliseconds to an average frame time of 64 seconds. It's as good as it's going to get, I think.
This week, I'm putting the finishing touches on the collision detection system (depenetration can be multi-threaded, but not as trivially as other steps) and going back to the level editor, which fell into a state of disrepair after I got into all this stress-testing nonsense.
It is possibly the biggest hack and maintenance nightmare I've ever seen. A lot of it is copy-paste-edit like in that bit
It's something you can get away pretty much only in throwaway game dev where you write it once, never reuse it and never have to change anything
I forget if VVVVVV was one of the games ported this way, but I was under the impression that this code was machine generated from a flash script or something like that.
That's still not awesome to maintain, but it explains the mind boggling boilerplate going on there
Say, an x,y array of fields corresponding to an interface where different button coordinates do different things based on states?
Asking for a friend.
The action itself can be a function pointer or just the information necessary for the next step to do the right thing. But this way the state machine itself is generic and reusable.
In the case of VVVVVV they could have a table with all those case numbers that are assigned to triggers in the world but each entry in the table would just need which script to run, is the trigger removed or not and maybe a custom action for those special cases that did extra stuff. The switch statement is replaced by one method call looks like the piece of code that was copy/pasted 1000 times plus a smaller switch statement for the special actions.
If every state truly executes a unique piece of code that cannot be generalized then the registration/lookup is still better than a switch statement. Look at how a windows application handles the menu bar. Each entry executes a custom piece of code. The menu itself from the visual editor get turned into menu_id/function pointer pairs in the generated code. In your code you implement those functions one by one. So when a menu item is clicked that menu_id gets converted into a function pointer and executed.
https://impromptu.games/
Also I rearranged a bunch of dialog in Twine. Doing this by editing spreadsheets or JSON would have a taken a lot longer, so I should give some money to the twine guy (Chris Klimas)
Ironically, it isn't GDQ week itself that kills my productivity, but the week afterward; during the event, there are breaks between runs when I can focus on something else for at least ten minutes at a time. But in the week after, I have VoDs that I can play one after the other and just throw all my attention at that.
But.
I did get two things worked on this week:
First, I updated the Project Editor to use the kind of model I should have been using from the start to open sub-editors. Previously I had an individual control to display each hard-coded content type (animations, characters, and levels), which manually opened the editor for that content type. I switched to a model where I keep a map of object types to editor types that can be arbitrarily filled with new mappings in the constructor. Then I just added a tree view that displays the contents of the content folder that you can select files out of and it just opens the right editor for that type. I still need to add the "New item of this type" and "delete item" logic, but the interface is much smaller and more general now.
Then, because I am an addict, I took one last tilt at the windmill and tried to parallelize the "resolve collisions" phase of the collision detection system. I discovered, through a series of hilarious bugs involving a use-after-free, that the only part of that entire operation chain that could safely be performed outside of the main lock was a pair of "add to end of list" operations that became more complicated due to the fact that I could no longer guarantee that the lists I was adding to the end of were well-ordered. So, for real this time, next week's work, assuming there is any, is going to involve anything but my collision detection system.
Here's a post describing the idea:
1. the "enemies" either are or produce polynomials into the target (4)
2. sliding stuff up the three "attack" paths (2) performs the corresponding operation on the target (4): addition, subtraction, and division
-- division attacks can fail, the others cost resource
3. you draw cards into your hand (1) and can either
-- slide them directly up an attack path (2)
-- drag them through an operation into the bay (3), where they perform the operation on whatever is stored in the bay
4. you can drag whatever you have stored in the bay (3) up an attack path
5. when you've reduced the target as much as you can, you can clear it by swiping it off the screen
-- this will either generate or cost resource based on how much is left
The blue bits are potential popup menu locations for items/abilities/menus, health etc. go on the left.
I'm thinking maybe each level can have additional polynomials pile up, and there could be multiple storage bays so that you can plan ahead.
Now to never actually get around to coding any of it.
My brain has gotten completely hung up on the scaling of things. I desperately want to use Unity's rect transform stuff to make each collider take up a percent of the screen so that everything resizes dynamically, but... I guess it's only really meant for UI elements, not colliders and stuff?
Anyway! I'm beginning to suspect that my approach is Not The Best, so I'm wondering if anyone has any suggestions.
Here's where I'm at currently:
http://surfpossum.com/applets/dragTiles/
The X and Y are tiles to drag around, the space in the middle is "bay" you can drag the tiles into to "store" them and then drag the bay, up top is the target, and the operators in the middle are what you drag things through to apply an operation. Here's a shot of the hierarchy:
So... any good tutorials or reading that I should look into? I just don't know if I should be working with the canvas to make a card game with some physicality, or if I should be working entirely in 3D with colliders and stuff, or what questions I should even be asking.
Anyway this page keeps freezing so that's all I guess.
edit:
Note to future self: google more things before opening up Unity.
https://docs.unity3d.com/2019.1/Documentation/ScriptReference/EventSystems.IDragHandler.html
editagain:
Somewhat rebuilt using the above tutorial. Not quite the same functionality yet but holy moly it's easier to keep track of things this way.
...except... everything is wonky on the actual webpage? The "/" panel isn't registering stuff and the others have all swapped their functionality, and the top target doesn't do anything anymore? Weird, it all works in Unity and the panels that are registering seem to have accurate bounding boxes so... what the heck.
omg apparently deleting a tag works fine inside Unity, but if you build it then the array of tags still has the deleted tag in it or something (and objects end up with the wrong tag) until you re-open the project.
Oh, nice! I bought Corgi when it was on sale, but it didn't work for my platformer feel. I might revisit it if it keeps getting new features like that!
I bought Control and have been playing it compulsively all week, so I didn't get much done.
The one thing I did this week was make a very small revision to my "simple job" class that I use to coordinate multi-threaded tasks. To start from the beginning, I wrote a budget thread pool that I'm calling the "work coordinator" which I use to do parallelized work. You hand the work coordinator a collection of job objects, and it hands them out to however many worker threads it has, which then call a method called Process() on the job and mark it as completed. The main thread (the one that called into the work coordinator to begin with) blocks until all the jobs are done. A "simple job" is one that operates on a range of indexes in the buffered entity query of the system class it was defined in, such that the only thing you have to define in it is how it processes the entity at its current index. Ultimately what that means is after defining the per-index operation within the simple job class, setting off the parallelized work is one-liner like this:
However, besides modifying the query buffers, there will occasionally be "out of band" writes into the component storage-- like, if there's a component that makes child entities spin around their parent, the child entities aren't readable or writable through the main query, they have to be written through my old indirect ("write this new component value to that entity") writing system. However, one of the features I wanted in my architecture is "same inputs, same outputs", meaning that those out-of-band writes have to appear in the same order, since there's a possibility (though I'd hope to avoid this situation) that two components might have a reference to the same remote entity, and therefore the order of their changes matters. But since jobs are being processed in parallel, I can't guarantee that they'll be registered to the component storage in the same order (and the component storage isn't thread-safe in that respect either). So, I added a system to the Simple Job where you can enqueue out-of-band writes and apply them only after the jobs are all done, which winds up applying the transformations in a reliable order.
I've accrued a number of microtasks that I want to knock out before I proceed to writing some actual game-logic components and systems, so this week will be a maintenance week (and, if Control doesn't last me the whole weekend, likely mean something of a small novel for next week's report).
Here's my floaty icon that says "this NPC wants to talk to you". I thought about copying the WoW exclamation mark but that seemed TOO blatant.
God I'm such a huge Spiderweb fan. I even was a Scorched Earth Party fan for the bit of time another milqetoast 20 year old would have been an objectivist.
-If it's a decent icon that looks like a wolf, in the next game it will still look like a wolf. I look at the worst 25% of a game and I redo that. I'm the leanest and meanest.
-opengameart.org ; freesound ; shockwave .sound-pick up an evergreen genre, a new genre becomes underutilised every year-there's nothing more furious than a scorned fan-"if something stops me from working, I cut it out mercilessly"-people keep telling me my graphics suck, i put money in, people keep telling me my graphics suck. that was the last time I ever made an effort-'the only thing that can decide what the market likes is the market'
-LESSON: BE THE EASY PERSON TO WORK WITH
-there is one prerequisite to make it as an artist: "you should always make your art so compelling that people forget to pee". (this is hard)
-don't quit your day job until you can afford to
-when you make a change you need to make sure the thing you bring adds fans to replace the ones you'll lose
-a good mailing list is a button that you press and a thousand dollars fly out. Always reply to fans, if anyone likes your stuff enough to mail you, take the effort tot reply.
-if at all possible, own the source code for your stuff. If you own your source code, find a hungry student out of college, give him a basket of dollars, pay him to make sense of your mess.
Aaaanyway, I'm getting close to releasing Endless Azure and so I was wondering how much of a hassle it would be to add a credits shop to the game. (Using Unity, for iOS). Does anyone have experience with this?
I want a designer to be able to create a standard Toggle and point its OnValueChanged event at a method on one of my MonoBehaviour classes. Then the method called by that event should take a static value for that Toggle (so that each Toggle may pass in a different value, designated by the designer), and then I want the method to respond to the combination of toggle state and that static value.
This also applies to a situation with Button objects, in which I want to pass in the Button object to change its appearance based on a state in my MonoBehaviour, but I want that Button to also pass in a value written by the designer.
Is there a way to get both toggle state (or the UI object itself) and the static value?
I haven't tried it myself but this:
https://answers.unity.com/questions/1270907/how-to-assign-a-value-to-buttons-every-button-woul.html
(I rolled my own touch-based button system because of Unity UI issues with transparency)
Thanks for the link!
That seems to use the static value approach, but it doesn't pass in the button itself. Populating a monobehaviour public value in the inspector with a button / toggle would give me some of that functionality, but it still requires me to write a new script for every menu.
I'm looking for an approach that a designer could use in any combination without my intervention.
Hmm, though that did give me an idea for trying it with a Scriptable Object...
I said I was going to give y'all a small novel but I'm in no mood. At least I have four things to report:
1. I fixed the way the matrix I pass into the sprite renderer is calculated such that it now correctly centers on the camera. I actually don't know how some of the math works out, but it produces the desired result so ¯\_(ツ)_/¯
2. Rather than using the extents of the window for rendering purposes, I now actually render to a texture with the configured "native" resolution and then render that to the screen with one of two stretching strategies: cap out on one dimension and stretch the same amount on the other, or only scale up by the minimum whole-integer factor that the window will support (falling back to the former strategy if the ratio is less than 1).
3. I started work on the "Play This Level" feature for the Level Editor. The idea is to be able to just go into the File menu and click "Play This Level" to boot the game up with the level being edited. You can already pass some command-line arguments into the game application to override default settings, but I thought it was going to be harder to do; I thought I might have to get the path to the executable and launch another process instance and wait on it to exit, but I forgot that games in Monogame are just a whole class unto themselves, and the Project Editor has to be re-built for each game, the actual game class is in scope to be instantiated directly. So I can just put some feigned command-line arguments together, instantiate the game class, and off it goes.]
3a. While doing the above, I discovered that the Project Editor was busted in a lot of ways thanks to a number of changes I made previously. I unbusted it.
4 the Future: I had an epiphany about how to parallelize the handling of collision detection events, but it entails completely re-thinking the whole approach. The essence of it is that I previously treated collision events as unique; for each pair of collision volumes in play; a collision between two collision volumes would be a single object referred to by both of them. But in actual practice any given collision volume only cares about the collision events that apply to itself. No collision volume is going to need to know what the next event that applies to the other entity involved in one of its own events is. So it may be possible to parallelize by creating a timeline of collisions for each individual collision volume and selectively negating the portions of each one that might be affected by a blocking event. So yeah, I'm probably going to wind up having one more go at it this weekend. I'm an addict.
I'm used to Unity still so I think I'll stick there, but a quick read suggests that Unity's Multiplayer options are being deprecated and something new called 'Connected Games' is coming soon. Anyone have anything concrete on that? Should I wait for Connected or just go with UNet/Mirror for now?
Twitch: KoopahTroopah - Steam: Koopah
I hear the "write once, change never" thing all the time about Game Dev but I don't see how it can be true. I've work on some very simple games and I still find myself iterating like hell on that code once I get some player feedback.
I work professionally as a programmer, mostly on full stack software products and I really emphasis being able to change my code through good architecture and tests. My limited experience with game code had me changing even more code then I do at my day job. Being able to introduce, adjust and throw away features quickly and without breaking things made "good" code really important.
That being said, real artists ship and VVVVVV is a great game. I'd love to have more insight into his design and iteration workflow. Maybe he is just copy and pasting mass amounts of code and that just works for him.
Button setButton = PopUpPanel.gameObject.GetComponentInChildren<Button>(); //setButton.enabled = false; GameObject targetButton = setButton.gameObject; targetButton.GetComponent<Button>().onClick.AddListener(delegate { this.gameObject.GetComponent<Hangar_Canvas>().goResetsave(); });(The 'enabled = false' was there to see if I was in actual fact targeting anything even remotely like the button component I wanted but yes indeed I was targeting that very button)
What I was promised should work was:
The newest hotness is Unity NetCode. Its built on top of the new DOTS framework and is currently still in preview. There is also the Dots Sample if you want to dig through a working multiplayer project with a lot of the new bells and whistles.
IIRC, VVVVVV was originally made in flash, and that infamous switch statement was actually the result of an export tool.
I don't know how much work they did on it *after* the export, but that must be like shutting all your mess in a closet and then being buried alive next time you open it
I spent most of this week with a head cold that left me with only marginal amounts of brain to apply to anything, much less the fragile practice of computer programming, so I only got a few things done this week, mostly bugfixes that don't bear documenting.
Last week I mentioned that philosophically it would be easy to implement the "Play This Level" feature for my level editor. Well, philosophy is mostly bullshit, so I had the rare pleasure of encountering a type of exception message that I've never seen before; it turns out that Windows doesn't like it when you try to register a message pump twice on the same thread, and the Game class in MonoGame registers a message pump in its Run() method when built for Windows, so you can't just new one up and run it from a Windows Forms application, at least on the main thread. I was not confident enough that putting it on another thread would solve the problem (in fact, the idea didn't even occur to me at the time), so I went with my initial plan of just running the game as a separate process entirely. Which, because that was what I was building toward from the beginning, was still relatively easy to do, so now you can say "Play This Level" and jump straight into gameplay out of the level editor. Huzzah.
Plans for this week involve evicting this damn rhinovirus from my head and then continuing down the checklist of minor concerns.
Twitch: KoopahTroopah - Steam: Koopah