Vapourware Codexian Game Development Thread

[Thac0]

The skill unlocking system. Here, everything available to this character class is shown as unlocked, but in the game you'll unlock one tile at a time, which will discover the adjacent tiles.

The tiles look gorgeous, and your current card skill upgrade system is certainly one of the weakpoints of Himeko Sutori.
This looks strongly FFXII license board inspired, and imo it will be a sizeable upgrade to your game, as that is a fun system.

Equipment change, which highlights changes to your stats:

If it is possible I would add a number which shows the base stat. So in this case instead of just a blue 70 have it show 40 -> 70 and the 70 in blue. Gives just an ounce of information more.

Also I would put all of these pics with a little text on the Steam community tab as news, at least that is how other indies do it. I constantly get community tab news from Age of Fear for example to gather hype for the next patch. Currently Himeko Sutori only has patch notes on the news tab, which looks a little dry.

 

[vortex]

What does it mean deferred rendering? I know to google but can someone expain it in layman's term?

 

[Bad Sector]

What does it mean deferred rendering? I know to google but can someone expain it in layman's term?

Deferred rendering pretty much always refers to deferred shading (similarly with deferred lighting - technically deferred lighting and deferred shading are slightly different approaches but in practice everyone uses deferred rendering, lighting and shading to mean the same thing).

The idea is this:

The classic approach to shading (aka "forward shading") is to figure out which lights affect which meshes and calculate the shading when rendering those meshes on screen, so e.g. for each pixel the pixel shaders would go over every light that could affect that pixel and figure out if and how the light affected it. Usually this was done by first figuring out which lights affected the meshes, then when rendering the mesh, information about those lights would be sent to the shaders. The issue with this approach is that often lights would be taken into consideration even though they barely affected the pixel and there was limited space for the shaders to get info about those lights (this isn't much of a concern these days though). Most often engines only took a single light into consideration and rendered the affected meshes multiple times with additive blending for each additional light, so a mesh that was affected by -say- 10 lights would be rendered 10 times.

In deferred shading instead of rendering the final shaded image to the screen, the scene is "rendered" into separate textures which (usually) have the same resolution as the final image with each texture storing information that can be used to calculate lighting - e.g. the position of a pixel in 3D space, the color of the texture at that pixel (but without any lighting done), the normal (direction) of the surface at that pixel, etc, with these textures often being called together as the "g-buffer" (for geometry buffer, though that name might be misleading as it doesn't store the geometry itself, just information about the geometry at the pixels that were rendered). After this is done, the renderer finds the lights that are inside the camera's pyramid/frustum and for each one of those lights it performs a separate pass over scene in the area that the light would affect. Traditionally this was done by rendering a sphere around the light with a shader that did the lighting calculations but other approaches were used too (e.g. full screen quad with clipping around the light bounding box) and nowadays this is often done in small "tiles" in screen space using a compute shader. But pretty much every approach has more or less the same idea of instead of calculating the shading when rendering the mesh, to calculate at a later step from the data stored in the g-buffer.

The positive of this approach is that it is much faster to handle multiple lights, especially with complex geometry, since if 10 lights are affecting a mesh it will still only rendered once and only the part that calculates the lighting will care that there are 10 lights there (but that will be done only for the affected pixel(s) which is way cheaper).

The negative is that it only works with opaque geometry, transparencies do not work with it (because the g-buffer can only store data for one surface per pixel) and they are often done with forward rendering (or a forward-like approach). Also the g-buffer requires more memory and has much higher memory bandwidth demands - which increase a lot if you add MSAA in the mix. But often the pros outweigh the cons - e.g. it enables a lot of screen-space algorithms, such as screen space decals which can affect the underlying color and normal data of complex non-planar surfaces with little performance impact.

 

[The Avatar]

What does it mean deferred rendering? I know to google but can someone expain it in layman's term?

Forward rendering fully draws each object, lighting and all.
Deferred rendering draws objects to separate offscreen buffers and then does the lighting in screen-space.

 

[curds]

Started modeling again after having been in coding mode for the past several months. This is my version of a Kuo-toa, or a fat Murloc depending on how you see it. I think Kua-toa is Wizards of the Coast IP, so I will have to think of a different name for them. Any ideas?

Vodyanoy, Kappa, Neck, Merrow.

Stolen from here: https://en.wikipedia.org/wiki/List_of_piscine_and_amphibian_humanoids

Some Lovecraftian name is always a safe bet for fishpeople, too.

 

[50726f73706572]

I normally don't post here. But here's a look at the status of my game:

https://vimeo.com/578955725

Believe it or not you're looking at my gui after i "redesigned" it.
Made tweaks to gui since making the video.

I can't predict the future but once people give my game a chance, they'll like it.

 

[Nathaniel3W]

I normally don't post here. But here's a look at the status of my game:

https://vimeo.com/578955725

Believe it or not you're looking at my gui after i "redesigned" it.
Made tweaks to gui since making the video.

I can't predict the future but once people give my game a chance, they'll like it.

You and TheDeveloperDude really need to collaborate on a project. I feel like your styles are very complimentary.

 

[50726f73706572]

I normally don't post here. But here's a look at the status of my game:

https://vimeo.com/578955725

Believe it or not you're looking at my gui after i "redesigned" it.
Made tweaks to gui since making the video.

I can't predict the future but once people give my game a chance, they'll like it.

You and TheDeveloperDude really need to collaborate on a project. I feel like your styles are very complimentary.

I've lost most of my social skills getting to where I am, so a true collaboration with another person will never be possible.

 

[50726f73706572]

New main menu today, among other things.

 

[TheDeveloperDude]

Does anyone use Test Driven Development method here?
Or any automated test/unit test for game development?

 

[Twiglard]

Does anyone use Test Driven Development method here?

That's a retarded idea, no. You can't design an API without properly implementing it. Otherwise you have to constantly rewrite the tests. All abstractions are leaky.

Or any automated test/unit test for game development?

Good luck making your game logic deterministic and invocable in a non-interactive fashion. It absolutely can be done, but it's not an easy thing to do and to maintain.

 

[RPK]

Does anyone use Test Driven Development method here?

That's a retarded idea, no. You can't design an API without properly implementing it. Otherwise you have to constantly rewrite the tests. All abstractions are leaky.

Or any automated test/unit test for game development?

Good luck making your game logic deterministic and invocable in a non-interactive fashion. It absolutely can be done, but it's not an easy thing to do and to maintain.

if you make your game logic accept a random number provider interface as a parameter to either a method or as a class constructor, it's easy. It's basic dependency injection. That's how all unit testing is done.

Your real class injects the real random provider and your unit test inject an implementation that always provides the same value. that way your "random" value is now deterministic.

all of your game logic should be in separate classes from the classes that provide interaction with the player or the world in any way so that it can be tested via unit tests.

Test driven development is a perfectly valid approach.

 

[Bad Sector]

all of your game logic should be in separate classes from the classes that provide interaction with the player or the world in any way so that it can be tested via unit tests.

I haven't seen that be done in practice in released projects anywhere, not to mention it doesn't really work with the script-based approach pretty much all engines use.

I have seen unit tests for stuff like the low level matrix, math, etc stuff but i always felt they were a waste of time since a) anything that breaks there will be immediately obvious since a TON of stuff are built on those and b) these are pretty much written once and rarely touched while unit tests are mainly useful for refactoring.

I have seen other forms of automated testing that helps though, but that is for high level stuff, like loading a map and having automated (recorded) input played to ensure the engine wont crash.

 

[Nutria]

I have absolutely no idea wtf I'm talking about, but from what I've heard that's something that works best when you scale it up to running a factory or something. Probably doesn't help much in a small team. IIRC it's best when the people writing the tests and the people writing the code are separate, so it wouldn't help that much if you're not on a huge project.

 

[zwanzig_zwoelf]

Does anyone use Test Driven Development method here?
Or any automated test/unit test for game development?

And what exactly are you trying to achieve with this?

From what I know, it's a waste of time if you're a solo dev / tiny team working on a project with a reasonable scale.

 

[rusty_shackleford]

who needs automated testing when you have early access?

 

[Bad Sector]

I have absolutely no idea wtf I'm talking about, but from what I've heard that's something that works best when you scale it up to running a factory or something. Probably doesn't help much in a small team. IIRC it's best when the people writing the tests and the people writing the code are separate, so it wouldn't help that much if you're not on a huge project.

Yeah, unit tests aren't useless by themselves but they aren't a magic hammer that makes things better with every wack. They are useful largely to ensure that assumptions are still valid (test-driven development is just writing code that has those assumptions first), but they do not fit all purposes and even where they work their "RoI" depends heavily in your team's structure.

Personally i wouldn't bother with unit tests for anything related to games, but i would bother with unit tests when it comes to things like scripting languages that i want to keep backwards compatible. I'd also consider automated tests (many people confuse the two but unit tests are just a form of automated testing, not the only one) for stability tests and if i had a dedicated building PC i'd most likely have it perform such tests. 99% of time they'd work but they are also trivial to implement and can help especially with crossplatform projects (e.g. your work on one platform could accidentally break some other platform which can be easier to fix immediately after you notice it rather than at a much later point).

 

[RPK]

I've written unit tests for everything from character creation to the combat engine. I'm currently sitting at nearly 300 unit tests in my project. and yes, all of the logic of the engine is in scripts separated from the code that anything to do with user interaction or game physics or anything else that has to do with the game engine. I can't imagine what a nightmare testing must be otherwise.

 

[TheDeveloperDude]

And what exactly are you trying to achieve with this?

I am a solo developer.
It sounds a great idea to have tests. I modifying a program and running the tests I am sure I have not ruined the system.
But I cannot imagine how I can achieve that.
For example one of the player characters is attacking a monster. I have to create a PC and a monster. Then execute the attack, look at the result. But there is a lot of randomness. It is crazy.

 

[RPK]

And what exactly are you trying to achieve with this?

I am a solo developer.
It sounds a great idea to have tests. I modifying a program and running the tests I am sure I have not ruined the system.
But I cannot imagine how I can achieve that.
For example one of the player characters is attacking a monster. I have to create a PC and a monster. Then execute the attack, look at the result. But there is a lot of randomness. It is crazy.

this is why you have your characters and attack logic and everything that doesn't have to be "physically" represented on screen separated out into their own classes so they can be instantiated by themselves. Then you have a container class that gets attached to whatever is managing the visual elements on screen that also contains these objects and refers to them as needed.

 

[Bad Sector]

I've written unit tests for everything from character creation to the combat engine. I'm currently sitting at nearly 300 unit tests in my project.

I have heard about people attempting this for years now in games, even doing "proper" test-driven development. The thing is, i never heard of any released games doing this which is exactly why i wrote "I haven't seen that be done in practice in released projects anywhere" (note that i do not include trivial proof-of-concept games like, e.g. pacman, boulder dash or some match-3 game where you do not see or can 'bruteforce' through the overhead imposed by unit testing/TDD).

I mean there might be some but it is so incredibly rare that i think it is a testament towards its (in)applicability in games.

(also FWIW i have a personal bias since with only a single exception, pretty much everyone in my career who tried to push unit tests, TDD and similar buzzwords were mediocre-at-best busybodies and every single competent programmer i know is at best not fond of and most often against unit tests - note that all this is in the context of game development, not general development, unit tests are very useful in some cases in other contexts)

all of the logic of the engine is in scripts separated from the code

Scripts are also code, but what i meant is engines that have you put scripts here and there alongside the scriptable elements. It is certainly not impossible to do what you describe but it works against design and intent of an engine that uses scripts like that.

 

[RPK]

I've written unit tests for everything from character creation to the combat engine. I'm currently sitting at nearly 300 unit tests in my project.

I have heard about people attempting this for years now in games, even doing "proper" test-driven development. The thing is, i never heard of any released games doing this which is exactly why i wrote "I haven't seen that be done in practice in released projects anywhere" (note that i do not include trivial proof-of-concept games like, e.g. pacman, boulder dash or some match-3 game where you do not see or can 'bruteforce' through the overhead imposed by unit testing/TDD).

I mean there might be some but it is so incredibly rare that i think it is a testament towards its (in)applicability in games.

(also FWIW i have a personal bias since with only a single exception, pretty much everyone in my career who tried to push unit tests, TDD and similar buzzwords were mediocre-at-best busybodies and every single competent programmer i know is at best not fond of and most often against unit tests - note that all this is in the context of game development, not general development, unit tests are very useful in some cases in other contexts)

all of the logic of the engine is in scripts separated from the code

Scripts are also code, but what i meant is engines that have you put scripts here and there alongside the scriptable elements. It is certainly not impossible to do what you describe but it works against design and intent of an engine that uses scripts like that.

well, I am working on an implementation of the d&d 3.5 ogl rules and my unit tests have help me immeasurably with making sure all the rules for things like tripping and so on are working correctly. Like i mentioned earlier, I can't imaging how much of a PITA that would have been to fire up the game get two characters together, have one try to trip the other (and hope they fail) and have the other try to return trip etc.

with a unit test, i can force the first guy's "random" provider to return a value that's low enough for his attack to fail and then have the second guy's random provider return a value for him to succeed.

My unit tests have SAVED me hours upon hours of time and tons of regressions as well.

 

[Bad Sector]

well, I am working on an implementation of the d&d 3.5 ogl rules and my unit tests have help me immeasurably with making sure all the rules for things like tripping and so on are working correctly. Like i mentioned earlier, I can't imaging how much of a PITA that would have been to fire up the game get two characters together, have one try to trip the other (and hope they fail) and have the other try to return trip etc.

with a unit test, i can force the first guy's "random" provider to return a value that's low enough for his attack to fail and then have the second guy's random provider return a value for him to succeed.

Of course you test what you develop, but are you going to change that implementation later? What exactly would regress? To me that sounds like something i'd develop, perform some tests on the game itself to see if they work as expected and then move on to other stuff - things wont break unless i change them and assuming a modular enough design (i mean very trivial stuff, like avoiding interdependencies) i wont ever need to touch those again... or if i do, any previous tests would be invalidated anyway (if you need to update a unit test to reflect changes to what the unit test is testing then the previous unit test was a complete waste of time).

My unit tests have SAVED me hours upon hours of time and tons of regressions as well.

How?

 

[RPK]

How?

by catching errors in logic without having to start up the game and move characters around and wait for things to happen on screen. I know what should happen when a character with x stats attacks a character with y stats and I setup a test with that scenario. It's not exactly TDD because I'm writing tests to verify what the code i just wrote, but still...

any time you don't have to run the game is time saved.

I've caught regressions when i, for instance create effects (spells) that modify things they are not supposed to, or when they don't do things they should. Again, I don't have to go into the game and somehow create a character that has those spells and cast them and then check the character sheet (hopefully I have created that already and added what to it I'm wanting to see) to see what I'm concerned about.

I'm not saying my way is the only way to do things. I find it incredibly efficient to just new up a character, add whatever stats I want to it, run it through the attack code with my mock random provider and verify the results and know that I now have a series of regression tests I can run whenever I want and can add to to see see if anything I've added to code over the course of the months has affected what I wrote all those months ago. Which has happened.

Especially in Unity (yeah, yeah, yeah) where you can't instantiate monobehaviors, having separate classes for all that stuff is very handy.

 

[The_Sloth_Sleeps]

I'd say you need a human player tester with a script - ideally not the programmer.

I'm not a fan of unit tests, but they have their place in certain "factory" style projects.

Unit tests tend to be self fulfilling prophecies. And God forbid u change a requirement.

To re-phrase Bad Sector tests are useful for automatically checking general assumptions.

Building state checks around a whole game (especially visual) I imagine to be incredibly tedious, and who tests the tests?