|
Unperson_47 posted:Went through another one of those phases where I work really hard on a project, coding and making assets a couple hours a day and even thinking about ideas while I'm driving or trying to fall asleep. Keeping a notebook handy and taking notes in a Google doc. I do this everyday for a few weeks until I end up doing maybe an hour of work on the project every OTHER day and then I just...stop. And by stop, I mean i find myself forgetting about it and and not launching Unity for months. Sedgr posted:Yep. I have a similar issue where I start a project, figure out how to implement it, and then my interest drops off a cliff because mentally I've got the problem mostly figured out, so actually taking the project to completion just sounds like...work. That's the thing, you get like diminishing returns on the 'high' of designing your thing. Then you get to where its all grunt work and you have to just grind out to get to the thing you already know you want, and you start to really question if its worth it. One solution can be trying to design something simpler. Like, instead of a video game, maybe design a board game, or a roleplaying game supplement. I was in a rut with game programming being such a chore so I wrote my own RPG tabletop ruleset, taking my favorite system and shamelessly ripping it off while transforming it with all the house rules I've built up over the years. I put together a pdf and polished it, and it barely took me a couple weeks. Then I was able to skip straight to actually playing the game with friends and playtesting it and tweaking it and balancing it, experiencing the thing that I'd imagined and designed without all the huge programming and art effort. Similarly, a board game can do a lot of things video games do, but is waaaay cheaper and faster to prototype and play. You're limited in how much you can do real-time wise, but these days there's ways to store any variable or rule or RNG in board game form as a card or a die roll or something. Beyond that, I ended up committing to #devtober and it feels like its a pretty good push to force myself to work on something a little every day. By the end of the month I should have something that's already built up enough that the real heavy lifting is over and I can just tool around on it here and there for awhile without it being so much of a daunting task.
|
#
?
Oct 16, 2019 02:27
|
|
|
|
| # ? May 9, 2024 07:34 |
|
|
Does anyone have links to documentation/examples/tutorials for the pixel rendering and physics style that Noita is using? After playing around with this game I am fascinated by it now but have not had a lot of luck in various searches. I have horrible ideas of applying this to something I am messing with 
|
|
#
?
Oct 17, 2019 18:53
|
|
|
CodeJanitor posted:Does anyone have links to documentation/examples/tutorials for the pixel rendering and physics style that Noita is using? After playing around with this game I am fascinated by it now but have not had a lot of luck in various searches. I have horrible ideas of applying this to something I am messing with Its basically 2D voxels, I bet their physics system is partially custom. But you just need to build objects out of blocks/particles/voxels/whatever, have 2d physics, allow for objects to deform if certain forces are applied and then break them and spawn objects that compose some of the broken bits and dynamically resize the physics to match the new object with bits broken off. Until you get down to the pixel level and then you don't allow for further breaks. Destructible objects, with pixel sized voxel elements.
|
|
#
?
Oct 17, 2019 19:00
|
|
|
Zaphod42 posted:Its basically 2D voxels, I bet their physics system is partially custom. But you just need to build objects out of blocks/particles/voxels/whatever, have 2d physics, allow for objects to deform if certain forces are applied and then break them and spawn objects that compose some of the broken bits and dynamically resize the physics to match the new object with bits broken off. Until you get down to the pixel level and then you don't allow for further breaks. Thanks! I wondered if this was a voxel solution, but based on the size of the levels I wasn't sure if the performance of tracking every individual pixel would be doable. Have to pull out some old, old code and adapt it to see if I can get it running again.
|
|
#
?
Oct 17, 2019 19:15
|
|
|
CodeJanitor posted:Thanks! I wondered if this was a voxel solution, but based on the size of the levels I wasn't sure if the performance of tracking every individual pixel would be doable. Have to pull out some old, old code and adapt it to see if I can get it running again. Like I was saying, you can optimize by chunking the voxels. So like, you have a box. You treat the box as a single object for physics collisions with other objects, until it gets to the point where it breaks, and then it subdivides into smaller objects. You still render the pixels (although you could potentially render to texture and cache) but you just have a single box for all other purposes, until it breaks, and then you have like 3 box-pieces, and then like 10 box-piece-pieces, and so on, until you grind them down. So each pixel doesn't become a collidable object until its completely ground down to dust. I'm just speculating out of my rear end, its hard to say for sure, and they probably are doing some clever optimizations for the large terrain. But from tests I've done, in a 2d setting on a modern GPU you can have a loving ton of particles before you get performance concerns. The hardest part would be handling when things do get turned into dust, but in Noita it seems like sometimes those things are more cosmetic. I wonder how far you could get without any optimization at all, but if you wanted to improve performance you'd just find ways to glomp groups of voxels together and treat them as a single unit for purposes of collisions and physics. Kinda like handling a large crowd of units in an RTS and doing pathfinding for all of them at once. E: The other way to go about doing something like this, what games like Worms do, is use a bitmask to create deformation from an original object. But I don't think that'd help Noita much because you still have to keep whatever you break off, and once you're handling all those bits you may as well just have the whole level be bits to begin with. Zaphod42 fucked around with this message at 19:57 on Oct 17, 2019 |
|
#
?
Oct 17, 2019 19:50
|
|
|
It's what, 800x600? 1024x768? Computers are fast, you can totally track that many pixels, especially if most of them are dormant.
|
|
#
?
Oct 17, 2019 19:57
|
|
|
Suspicious Dish posted:It's what, 800x600? 1024x768? Computers are fast, you can totally track that many pixels, especially if most of them are dormant. That's the other thing, it doesn't look very high resolution, right. So even if the whole screen is filled with voxel elements that are moving and bumping into each other, its probably not a big deal.
|
|
#
?
Oct 17, 2019 19:59
|
|
|
If people are seriously interested in how it was done maybe someone could ask the dev? Hempuli maker of Baba is You and fellow SA member was part of the team that made Noita I think.
|
|
#
?
Oct 17, 2019 20:00
|
|
|
Some technical details here: https://80.lv/articles/noita-a-game-based-on-falling-sand-simulation/
|
|
#
?
Oct 17, 2019 21:03
|
|
|
Apparently Glider PRO's source code and data were open sourced a few years ago, so I'm gonna try doing a Windows port, and I'll be doing some writeups on it since it'll be a fun time machine trip back to 1994-era Mac tech. (The code is ~30% calls to the Mac system API and zero C standard library.)
|
|
#
?
Oct 18, 2019 18:27
|
|
|
Yeah my hell with game dev is content. I love coding and designing systems. I'll happily debug, do gameplay programming, and build tools. Actually sitting down to crank out levels or items or whatever I just get overwhelmed and disheartened. If I was less of an idiot I'd focus on making local coop arena games or something with less content. Actually I should totally make Unlimited Adventures 2.0. A toolset for making your own whatever rpgs I've practically already finished and even if it sold poorly I'd be happy to have something on Steam.
|
|
#
?
Oct 20, 2019 00:21
|
|
|
FuzzySlippers posted:Yeah my hell with game dev is content. I love coding and designing systems. I'll happily debug, do gameplay programming, and build tools. Actually sitting down to crank out levels or items or whatever I just get overwhelmed and disheartened. If I was less of an idiot I'd focus on making local coop arena games or something with less content. I feel like there are a lot of people floating around begging to have someone take the programming and debugging away from them so they can focus on design.
|
|
#
?
Oct 20, 2019 00:27
|
|
|
Absurd Alhazred posted:I feel like there are a lot of people floating around begging to have someone take the programming and debugging away from them so they can focus on design. Your post made me think that the best 'idea guy' possible is one that has experience with the programming and debugging so they can follow along with progress and understand what the capabilities and weaknesses of the codebase are.
|
|
#
?
Oct 20, 2019 00:36
|
|
|
Absurd Alhazred posted:I feel like there are a lot of people floating around begging to have someone take the programming and debugging away from them so they can focus on design. The difficulty is how do I know if any of the many idea guys online are gonna really do the endless spreadsheet/etc work required. While someone with proper game design experience would probably prefer to work with a programmer with game industry experience (not me). I'm hoping one day as I muddle along and maybe publish a few (crappy) games I'll stumble onto a design collaborator. It'd be a lot easier to pick up a writing collaborator but I do okay there. It's that space between writing and programming filled with items, levels, encounters, enemies, etc that really defeats me.
|
|
#
?
Oct 20, 2019 01:26
|
|
|
taqueso posted:Your post made me think that the best 'idea guy' possible is one that has experience with the programming and debugging so they can follow along with progress and understand what the capabilities and weaknesses of the codebase are. That's called a software architect  FuzzySlippers posted:Yeah my hell with game dev is content. I love coding and designing systems. I'll happily debug, do gameplay programming, and build tools. Actually sitting down to crank out levels or items or whatever I just get overwhelmed and disheartened. If I was less of an idiot I'd focus on making local coop arena games or something with less content.  I just found out the friend of mine who had volunteered to help build levels while I did programming is moving out of state and that's probably the end of that. I can't be mad because we're just working on it for fun, not like I'm paying him. But I invested a good bit in this project already and did so with the idea he would be helping. I'm kinda tempted to start a new project with a very different approach so it would play more to my strengths as a pure programmer, but I need to start a new project like I need a hole in the head. I've just about gotten to where I can produce a demo for this game, I should keep at it. I have sometimes considered doing a kickstarter or a patreon where I offer to just build a simple game engine and then release it open source so other people can use it to build games off of. Not sure how many people would go for it, probably lots of sample game projects / engines anyways, but IDK...
|
|
#
?
Oct 20, 2019 02:03
|
|
|
There is this which has been semi-actively developed for awhile now to where it is decently mature, some modules(Hearkenwold) getting there as well: https://www.iceblinkengine.com/
|
|
#
?
Oct 20, 2019 13:10
|
|
|
FuzzySlippers posted:Actually I should totally make Unlimited Adventures 2.0. A toolset for making your own whatever rpgs I've practically already finished and even if it sold poorly I'd be happy to have something on Steam. Yes, do it. Get something on Steam! Even if it's not a success the process is extremely worthwhile. You'll learn far more than you think and no matter how little you expect you still go through launch gitters/stress. It's far better to have that happen with a smaller product then potentially destroy a major product. Do it, get it on Steam!
|
|
#
?
Oct 21, 2019 16:37
|
|
|
the big secret of game development is that 99% of it is manual labor with hand-placed trigger volumes and such like that.
|
|
#
?
Oct 21, 2019 17:00
|
|
|
Suspicious Dish posted:the big secret of game development is that 99% of it is manual labor with hand-placed trigger volumes and such like that. Sequencing game events in Hammer is the source of many developer nightmares.
|
|
#
?
Oct 21, 2019 17:04
|
|
|
I just completed the final(-ish) revision of my chip8 game for this year's Octojam: An Evening to Die For. In a nutshell, this is a more graphical re-imagining of a DOS game I loved as a kid called Sleuth, with a few extra surprises including several easter eggs, a shocking climax to your investigation, and five distinct endings. Full source code (about 4000 lines of assembly language and data) is available in the cartridge on the Itch page. If anyone's curious, I could do a writeup about how the internals of the game work. The short version is tooling, tooling, tooling. Beyond my IDE itself, I wrote three specialized tools that aided in data-preparation. When working with limited resources, choosing the right data representation is always half the battle. I may do a more complex take on this game concept in the future. Working within the creative limitations of xo-chip was a good way to keep my ambitions at a reasonable scale for a prototype, and I think I have a much better idea of what's important about the design and where to go from here.
|
|
#
?
Oct 23, 2019 05:36
|
|
|
I'm trying to migrate my RTS code to Unity's ECS framework little by little, and I'm trying to figure out how to tag stuff. I have units with some different components(MonoBehaviours right now) like CanMove, CanAttack, CanBuild. Right now the logic for moving, attacking and building are in UnitCommands, which I'm not sure is the appropriate place for that. In ECS, would you have those three tags, and then have tags for IsMoving, IsAttack, IsBuilding, and stuff like that, handling the logic in system classes?
|
|
#
?
Oct 23, 2019 13:22
|
|
|
Boz0r posted:I'm trying to migrate my RTS code to Unity's ECS framework little by little, and I'm trying to figure out how to tag stuff. I have units with some different components(MonoBehaviours right now) like CanMove, CanAttack, CanBuild. Right now the logic for moving, attacking and building are in UnitCommands, which I'm not sure is the appropriate place for that. In ECS, would you have those three tags, and then have tags for IsMoving, IsAttack, IsBuilding, and stuff like that, handling the logic in system classes? I don't think you have to redo your tags, it's just that you group together your transforms or other alike structures so the CPU can iterate really fast over the same datastructures. I mean a unit building or moving is not important for the CPU, it just needs to have fast access to all transforms that it needs to change during a frame. At least, that's what I make out of it.
|
|
#
?
Oct 23, 2019 16:07
|
|
|
Speaking of ECS, does anyone happen to know if it's possible to run a world entirely off the main thread? I'm in the early stages of a project that could potentially benefit from it in the simulation, but my simulation layer runs in it's own thread completely separate from the presentation layer, and I'd prefer to keep things that way.
|
|
#
?
Oct 23, 2019 16:54
|
|
|
chglcu posted:Speaking of ECS, does anyone happen to know if it's possible to run a world entirely off the main thread? I'm in the early stages of a project that could potentially benefit from it in the simulation, but my simulation layer runs in it's own thread completely separate from the presentation layer, and I'd prefer to keep things that way. Of course it is, that's how most every Unity game (main only, specifically update and fixedupdate) are made, but why would you want to? Keeping your simulation away from main thread is much better.
|
|
#
?
Oct 23, 2019 16:58
|
|
|
Stick100 posted:Of course it is, that's how most every Unity game (main only) are made, but why would you want to? Keeping your simulation away from main thread is much better. I think you misunderstood my question. I don't want the simulation on the main thread. I want to run ECS in my simulation thread. Edit: Basically, what I want to know is if I can run ECS in a way that the rendering thread is never blocked waiting on it, no matter how slowly the simulation happens to be running. chglcu fucked around with this message at 17:13 on Oct 23, 2019 |
|
#
?
Oct 23, 2019 16:59
|
|
|
chglcu posted:I think you misunderstood my question. I don't want the simulation on the main thread. I want to run ECS in my simulation thread. The physics thread already runs this way.
|
|
#
?
Oct 23, 2019 17:45
|
|
|
chglcu posted:I think you misunderstood my question. I don't want the simulation on the main thread. I want to run ECS in my simulation thread. To my very limited understanding of ECS, that's a built in aspect of ECS. No matter how bad you mess up ECS it shouldn't block frames/rendering/physics since they all run on separate threads. If you have multiple cores they shouldn't impact each other. I have not experimented with it however.
|
|
#
?
Oct 23, 2019 18:07
|
|
|
Is there any good material on how Obra Dinn achieved its style at a technical level? I kind of want to see if I can recreate PC-88 style in 3D, and I feel like Obra Dinn would be a good starting point since they're different but not entirely dissimilar. I could probably knock it out myself but starting material is always nice. I'm guessing (other than the obvious edge detection filter), it's mostly just some kind of noise map and post-processing masking based on things like shadow weight and distance, but I have a suspicion it'd look like flickery poo poo in dynamic free camera 3D without some sort of correction/smoothing between adjacent frames. E: Looks like there's some devlog/forum posts on the TIG forums, it wasn't showing up when I first searched for some reason. https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742 Linear Zoetrope fucked around with this message at 23:07 on Oct 31, 2019 |
|
#
?
Oct 31, 2019 22:56
|
|
|
Linear Zoetrope posted:Is there any good material on how Obra Dinn achieved its style at a technical level? I kind of want to see if I can recreate PC-88 style in 3D, and I feel like Obra Dinn would be a good starting point since they're different but not entirely dissimilar. I could probably knock it out myself but starting material is always nice. I'm guessing (other than the obvious edge detection filter), it's mostly just some kind of noise map and post-processing masking based on things like shadow weight and distance, but I have a suspicion it'd look like flickery poo poo in dynamic free camera 3D without some sort of correction/smoothing between adjacent frames. googling "obra dinn shader" came up with this in the results, seems informative https://www.alanzucconi.com/2018/10/24/shader-showcase-saturday-11/ Then I found this post by the dev Lucas Pope: https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742 Ruzihm fucked around with this message at 23:07 on Oct 31, 2019 |
|
#
?
Oct 31, 2019 23:04
|
|
|
Epic Games is hosting another Unreal Engine 4 game jam from the 14th to the 21st https://itch.io/jam/2019-epic-megajam
|
|
#
?
Nov 1, 2019 03:07
|
|
|
Does anyone know of a lightweight entity-component-system library for Java that isn't based on libgdx? Or are Ashley and ArtemisODB my only real options? The intention is to write a headless server orchestrating game sessions while clients can drop in and out of sessions, interacting with other clients in the same session. I also want to actually finish something basic and have it running publicly before 2021/the heat death of the universe, which means relying on the Java stack that I'm actually familiar with and can make a (probably much slower than Unity DOTS but fast enough for my needs) decent ECS backend solution. ECS is desired since I can just send clients snapshots/deltas of component changes as needed, whether I'm using web sockets or UDP or whatever, and more easily reuse/port the component data structures and systems logic for frontend ECS of any flavor, be it libgdx-ashley or unity-dots or some abomination of react+phaser. Anyone got opinions/advice on any of that, or multiplayer development considerations in general?
|
|
#
?
Nov 9, 2019 07:27
|
|
|
Tempora Mutantur posted:Does anyone know of a lightweight entity-component-system library for Java that isn't based on libgdx? Or are Ashley and ArtemisODB my only real options? If C# is similar enough to Java for your purposes, and you're willing to take a risk on an alpha implementation, you might try Encompass. Otherwise I got nothin'.
|
|
#
?
Nov 9, 2019 19:45
|
|
|
Bongo Bill posted:If C# is similar enough to Java for your purposes, and you're willing to take a risk on an alpha implementation, you might try Encompass. Otherwise I got nothin'. Eh, I'm resisting C# just because if I'm going to use C#, a headless Unity server lets me directly use DOTS, which would make client stuff waaaay easier since I can directly reuse huge chunks of DOTS for both client and server... I probably should, just to get more familiar with the Unity ecosystem if nothing else. My initial focus is making multiplayer card games, which I can rapidly prototype using just a java backend and a js frotend without having to learn new languages/server deployment needs, plus anyone with a browser can play my games. I will absolutely want to do something more graphically intense/real-time-ish after that, so uh... I should probably follow the whole indie dev lesson I read about of "just make a thing" and work with what I know instead of, uh, not. I dunno, it's similarly stupid for me to resist just using ashley and libgdx if I'm gonna use java. Slay the Spire was made with libgdx and the original minecraft was like, straight java, so really I either make games people like or I don't, regardless of the tech, so I know deep down I should stick with what I know until it really doesn't suit my needs, which can only happen if I actually Finish A Thing, or even get it to the point where I need to think about any kind of performance (whereas right now I have a whole lotta docs and minimal code). Hell, Terraria is like one of the best-selling games ever, and regardless of the language I remember someone showing that the original code for every block was some insane series of like 100+ if conditions to manually check for each state the block could be in, which reeeeally highlights how little the tech matters, heh. Sorry for the stream of consciousness, but thanks for the Encompass link! The main implementation is TypeScript, so that's probably going to be useful for me anyway for any makeshift js client I cobble together.
|
|
#
?
Nov 10, 2019 21:14
|
|
|
Great. Unfortunately, I don't know anything like this for Java. The tech matters insofar as it impacts the cost of adding features that you didn't originally have in mind. Games are software like any other, and paying attention to architecture pays off when the program is big and old.
|
|
#
?
Nov 11, 2019 02:34
|
|
|
Every bad thing I’ve heard about Terraria source code is based on the decompiled source code leak. Decompiling source code has a tendency to greatly alter the original and I’m reluctant to say "lol that programmer was bad" based on it.
|
|
#
?
Nov 11, 2019 07:07
|
|
|
That sounds like some kind of inlining or unrolling to me. It's not impossible, but the compiler very well may have seen some clever better written class or enum-based stuff and "solved" that it could be implemented as basically a jump table.
|
|
#
?
Nov 11, 2019 08:00
|
|
|
I've finally decided to get into Unity, and I've been watching a ton of tutorials and I just want a bit of a sanity check here. I'm kind of blown away by what you can do with it, all the systems it gives you for basically free, it's very inspiring. But I look at the kinds of games I'm planning on making with it, stuff like roguelikes, 3d puzzles and whatnot and things with a lot of procedural generation and it looks as though I'm going to be generating a lot of my stuff from code, still. Rather than you know, pull an asset from the asset store, position it in a level, give it a rigidbody and throw physics at it, the whole "grab a bunch of premade stuff and combine it to make a game" model it seems to be funneling me towards. Is that a crazy way to use Unity? Just as basically an event handling, render pipeline setup, ui overlaying front end on something that's very driven by hand-carved procedural generation code? Should I try harder to get into that mindset of leaning heavier on it or just go with what my instincts are telling me here, cos I'm very much a coder at heart, just not one that can be hosed to troubleshoot making an engine from scratch in TYOOL 2019.
|
|
#
?
Nov 11, 2019 16:40
|
|
|
HauntedRobot posted:I've finally decided to get into Unity, and I've been watching a ton of tutorials and I just want a bit of a sanity check here. I'm kind of blown away by what you can do with it, all the systems it gives you for basically free, it's very inspiring. But I look at the kinds of games I'm planning on making with it, stuff like roguelikes, 3d puzzles and whatnot and things with a lot of procedural generation and it looks as though I'm going to be generating a lot of my stuff from code, still. Rather than you know, pull an asset from the asset store, position it in a level, give it a rigidbody and throw physics at it, the whole "grab a bunch of premade stuff and combine it to make a game" model it seems to be funneling me towards. Procedural generation of meshes, textures, and other "raw" assets like those can be a little awkward but it's very easy to procedurally instantiate gameobjects, add components and configure them. https://docs.unity3d.com/ScriptReference/GameObject-ctor.html
|
|
#
?
Nov 11, 2019 17:22
|
|
|
I don't have a lot of context for how "awkward" Unity is when generating raw assets, but it's entirely doable. The first Unity project I tinkered with way back in the day was procgen terrain meshes with procgen textures. Heck, pretty much everything I've been involved with since with Unity has been procgen-related. It's not as intuitive to a first-time user as instantiating a prefab is, but if you've already got an idea of the algorithm that you want to work with then Unity won't stop you.
Corbeau fucked around with this message at 18:03 on Nov 11, 2019 |
|
#
?
Nov 11, 2019 18:00
|
|
|
|
| # ? May 9, 2024 07:34 |
|
|
HauntedRobot posted:I've finally decided to get into Unity, and I've been watching a ton of tutorials and I just want a bit of a sanity check here. I'm kind of blown away by what you can do with it, all the systems it gives you for basically free, it's very inspiring. But I look at the kinds of games I'm planning on making with it, stuff like roguelikes, 3d puzzles and whatnot and things with a lot of procedural generation and it looks as though I'm going to be generating a lot of my stuff from code, still. Rather than you know, pull an asset from the asset store, position it in a level, give it a rigidbody and throw physics at it, the whole "grab a bunch of premade stuff and combine it to make a game" model it seems to be funneling me towards. Nah that's sane, that's what I and lots of people do, and you'd be doing roughly the same in unreal or godot. There are a few things to be mindful of, don't abuse GameObjects for everything or you'll have potential performance concerns. Although even then it depends, indie stuff... Just wanna warn you right now that making procgen good is toooons of work. I would build some bespoke levels first and then build procgen later if you're considering it. Its not a shortcut to skip level design.
|
|
#
?
Nov 11, 2019 18:50
|
|