In light of endless quarantine I'm trying to take another stab at game dev since I'm bored out of my skull. I spent a couple days doing Game Maker Studio tutorials but decided to stick with Unity after all since I just couldn't get over the lack of proper C# object oriented practices; I program for a living and that's half the fun of it to me. I'm planning to stick with pure simple 2D games with tight scope, and maybe get into shape for some game jams down the line as a goal.
Edit: I think I mostly figured out my Animator issue, though not without a little tedium. I'm working now on doing some kind of interactive idle game, inspired in part by Incremancer. I know there's a community for games like that with very low production values that I'm pretty confident I can hit. Nothing to show for a little while though.
Well, it came down to the wire, and required me taking a day off of work (which I was going to do anyway but shhhh), but I got a little bit of work done this morning, so hey, we broke the streak, it was only 2.99 weeks without any game dev instead of 3.
Returning to my platforming body movement system with fresh eyes, I immediately spotted an opportunity to compress the handling of various cases into a single handler, so I went ahead and did that refactor. It isn't done yet, and it blocked the planned unit testing, but it's going to make the eventual unit testing and debugging a lot easier, so whatever, I'm calling it a win.
Since it took place in my designated game programming time, a tale of some other recreational programming I did this week: I've been playing Murder By Numbers recently, which is either a picross game with a visual novel attached, or a visual novel with a picross game that shows up whenever you spot a clue, depending how you look at it. For whatever reason, they gate some extra content behind your ability to solve these picross puzzles without using the built-in assists, such as handing you the next move or pointing out where you've filled a square in incorrectly. To get the maximum rank, you have to complete every puzzle in a chapter without using any assists. Well, imagine my shock when I got to the end of case 3 with only an A-Rank, when the maximum is S-Rank. It turns out that there's a piece of evidence in that case (and only in case 3) that you can miss by not investigating a particular area at a particular time, and since I caught on to what was happening in that case early, I managed to bypass it. And you can't just go back and re-attempt individual puzzles; if you want a better rank, you have to re-play the entire chapter and every puzzle in it. Now, at this point a normal person would just go look up picross solvers online, because if there's something that shows up in a crossword puzzle book, there's a solver for it online. But that felt like too little work to be entirely fair, so, I went and wrote my own.
If you've never played picross, the idea is that you have a two-dimensional grid of cells and your objective is to fill in a particular set of cells such that they form a picture. (You usually have to be told what exactly you're looking at after the fact for the image to make sense, but I digress.) To help you figure out which cells are the correct ones, each row and column is annotated with a series of numbers that indicates how many "spans" there are in that row or column and how many cells they consist of. So, if the first row has "1 3 2 2" next to it, that means that there's a span of one cell, three cells, two cells, and two cells, in that order, with at least one blank cell between each one.
Making a computer solve picross is actually fairly easy if you don't mind applying a bit of brute force to it. Leaving boring stuff like parsing input files and rendering the solved puzzle out, here's how it goes:
- For each row and column, enumerate all possible blank/marked combinations that solve that row or column.
- Put all of the rows and columns into a bucket. To help the algorithm converge faster, I sorted them in ascending order of number of possible solutions, then in descending order by largest span, which leaves rows or columns likeliest to have useful information at the front of the bucket.
- Loop through the contents of the bucket until nothing is left in the bucket OR you reach a maximum number of iterations*.
- For each potential solution in the current row or column, remove the solution if it contradicts the current state of the grid. (Says "filled" where the grid says "blank" or says "blank" where the grid says "filled".) If this leaves zero solutions associated with the row or column, error out-- the puzzle is flawed.
- If every remaining solution in the row or column agrees on the state of a particular cell, write that state onto the grid.
- If there is only one solution in the row or column, remove that row or column from the bucket.
And that's it! There are some logical tricks I use when solving puzzles manually that aren't represented in this algorithm, but I've yet to see it fail to solve any of the puzzles in Murder By Numbers. As for that asterisk about the maximum number of iterations, I found that it's actually possible to create a picross puzzle that has multiple solutions, in which case the algorithm I wrote will loop infinitely, since it can't ever reach a single solution. With the iteration limit, you still get the majority of the solution, and the ambiguous cells will be indicated as such.
The lesson to take away from this for game devs: proofread your goddamned story flags. Or some angry nerd will write a program that kicks your program's ass.
My favorite musical instrument is the air-raid siren.
Blocked out the second puzzle. I guess it's an underground bunker? Pretty standard "push-the-blocks" puzzle. You push the blocks onto the targets/pads. When all of the blocks are in the right spot, the door - which in this case is a huge panel covering up a hole - opens up.
edit2: figured out how to make unlit 2d sprite shader in shadergraph, bad news....build crashes waterfox (havent tried firefox) but it plays in chrome! lights look much better, also added background so you can see your light radius and also pretty thrust particles which are just distracting and need tweaking
It works happily in Firefox, at least for me. The "you've got an asteroid nearby" pulsing is interesting, too.
(I'm also getting screwed in it by my own project - the ship in mine can reverse, so I keep reflexively trying to do that only to faceplant into a rock when trying out your game. Doh!)
edit2: figured out how to make unlit 2d sprite shader in shadergraph, bad news....build crashes waterfox (havent tried firefox) but it plays in chrome! lights look much better, also added background so you can see your light radius and also pretty thrust particles which are just distracting and need tweaking
It works happily in Firefox, at least for me. The "you've got an asteroid nearby" pulsing is interesting, too.
(I'm also getting screwed in it by my own project - the ship in mine can reverse, so I keep reflexively trying to do that only to faceplant into a rock when trying out your game. Doh!)
Thanks for playing! And TY for the report on firefox. The pulsing is supposed to be a "heartbeat" but it looks like compile to webgl does some compression so it doesn't sound like that anymore.
Over the past few days I got some basics in place - simple generated tile map, bounded camera controls with zoom in/out, dropping units with the mouse and having them wander within the boundaries. Thinking of doing something like an idler version of SimAnt - next is a home base, resource harvesting and enemies.
Is anyone familiar with shader graph displacements?
I'm having issues when trying to use shader graph to simulate wind on grass while also having multiple meshes use the same texture sheet (grass, flowers, clovers, etc). I'm using a gradient to prevent the bottom of the mesh from waving and it works well for the few items drawn at the top of the texture, but all other parts only get the white part of the gradient. I'm trying to use the Tiling and Offset node but can't figure out how to make it offset based on the lowest UV point of a particular mesh. Is this possible or should I not be having everything on the same texture?
Here is an example of what I'm trying to do manually. In this example I'm trying to make the gradient begin where the lower grass texture begins instead of the at the top.
In case anyone is interested in something like this, I was able to get this working by using vertex paint in blender and then using a vertex color node in shader graph. Now I am able to keep all of the objects rooted to the ground even though they are not in the same orientation or Y position in the texture.
As an additional note, I started incorporating in Art assets to my personal project Voxel Fight, and I thought this tumbling feature was just too funny not to share.
I'm trying to find a good way to handle drawing stuff when the player is instead a small space (i.e., underground). Some examples for UE4 will look for object blocking your view and make them transparent, but that requires going through a bunch of objects and modifying all their materials. In this case I would have to use specific materials that support translucency or masking.
A promising method is to use the SceneCapture, which renders a scene and dumps it onto a render texture. The key point is that you can tell it "only render these objects" so I could use it to render only the underground objects and then blit that over the normal view, or crossfade between the normal view and the "only rendering underground things" view.
The main problem I'm having now is that the SceneCapture camera doesn't do auto exposure (eye adaptation) the same as the main view, so when you are underground everything looks really dark. I'm switching from 4.23 to 4.24 to see if anything improves, and then maybe switch to 4.25-preview. In 4.25 they are changing the auto exposure so it's likely any scene capture quirks would be fixed as well.
Unreal can make stuff transparent depending on distance to the camera (distancefade). I use them for stealth ships but you could set it so that the top layer goes transparent when the camera gets close.
I would need to change a bunch of materials to do it via shaders (landscape, particles, avatars) so I'm hoping this alternate method works, but in the end I may have to just bite the bullet and add fading to all (most?) of my materials.
I'm trying to find a good way to handle drawing stuff when the player is instead a small space (i.e., underground). Some examples for UE4 will look for object blocking your view and make them transparent, but that requires going through a bunch of objects and modifying all their materials. In this case I would have to use specific materials that support translucency or masking.
A promising method is to use the SceneCapture, which renders a scene and dumps it onto a render texture. The key point is that you can tell it "only render these objects" so I could use it to render only the underground objects and then blit that over the normal view, or crossfade between the normal view and the "only rendering underground things" view.
The main problem I'm having now is that the SceneCapture camera doesn't do auto exposure (eye adaptation) the same as the main view, so when you are underground everything looks really dark. I'm switching from 4.23 to 4.24 to see if anything improves, and then maybe switch to 4.25-preview. In 4.25 they are changing the auto exposure so it's likely any scene capture quirks would be fixed as well.
Also look into custom stencil and custom depth. It is used a lot for highlighting and outlining object even when they are obscured as a special stencil buffer render pass is done for the objects independent of the scene. You can then use the stencil buffer in post process materials to do final effect.
I know what you want is more a cutaway view when underground though and this wouldn't work for that. Making all the overground objects render with masked material that you can cut out at anytime is probably the way to go. Otherwise you need a manager to switch out all materials to the transparent one whenever you go underground.
I wish they'd add a feature to be able to setup multiple render passes in UE4, would be easy in forward rendering but hard in deffered. They gave us lighting channels but I'd like geometry channels too to allow easy overlaying. Like in your case the overground and underground would just be switched with a depthbuffer clear inbetween allowing you to render the underground on top of the overground stuff.
Also look into custom stencil and custom depth. It is used a lot for highlighting and outlining object even when they are obscured as a special stencil buffer render pass is done for the objects independent of the scene. You can then use the stencil buffer in post process materials to do final effect.
I know what you want is more a cutaway view when underground though and this wouldn't work for that. Making all the overground objects render with masked material that you can cut out at anytime is probably the way to go. Otherwise you need a manager to switch out all materials to the transparent one whenever you go underground.
[...]
In fact I already use custom depth/stencil to show the character when they walk behind trees and I had hoped I could just augment that, but the stencil buffer only has 256 values. This lets me color the hidden objects with a few colors but I can't use the full color & PBR values of hidden objects because I can't fit all the relevant data into the stencil buffer.
I wish they'd add a feature to be able to setup multiple render passes in UE4, would be easy in forward rendering but hard in deffered. They gave us lighting channels but I'd like geometry channels too to allow easy overlaying. Like in your case the overground and underground would just be switched with a depthbuffer clear inbetween allowing you to render the underground on top of the overground stuff.
Yeah my SceneCapture hack is basically an attempt to impose my own sequence of rendering. It seems like much of UE4 is setup to make a realistic FPS, so if you want to step out of that box you'll have to fight a bunch of defaults and optimizations designed for high-grade FX and FPS mechanics. I mean it's not impossible but it seems more difficult than it should be. The Torque engine had a similar problem since it inherited a lot of code from the original Tribes games.
I managed to double the number of days I did game dev work on this week (from 1 to 2).
In that time, I got some unit tests written for my platforming body management system. Thus far, these tests confirm that:
- When a platforming body starts out airborne and has a blocking interaction with a collision volume and the surface normal is "walkable", then the associated ground state becomes "grounded" and it parents to the platform entity.
- When a platforming body is on the ground and not moving, the ground scan that resets its position onto the surface doesn't modify its position.
- When a platforming body begins a frame on the ground but the ground scan fails, it unparents from the previous surface and becomes airborne.
In writing this out I've realized that what counts as a walkable surface normal should be affected by the direction of gravity (if gravity exists). Fie. That's more work for this next week.
The remaining tests mostly involve making sure that the logic is correct for dispatching to various other cases (like "was on the ground but collided with a non-walkable surface whose surface normal points upward relative to the current surface") and then making sure that the velocity is handled correctly when those cases occur.
After that, well, I'm going to try to get a visual example put together so I have a video to show you guys in next week's report. I'll commit to that! It's going to happen! See you next Friday!
My favorite musical instrument is the air-raid siren.
+4
Options
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
Probably worth if you are planning on releasing anything for reals. A decent artist will charge that much for a single icon. But for placeholders game-icons.net has never failed me. If you are on that site enough you will even catch them being used in commercial work.
Yeah just placeholder art is so much better than quickly drawn black squares or text label. Same thing with 3D models. If you can have something that is animated instead of a guy in a static T-pose sliding around you get a much better idea of what the game will feel like.
I had already bought REXXARD's icons last time they were on HumbleBundle but they were nice enough to not have that much overlap in this new pack.
Wanted to share that I just made my first custom editor window in Unity which is something that I've always shied away from before because it seemed really complicated. The purpose was to randomly generate cards for a card battler game. (game mechanics shamelessly stolen from Warmetal Tyrant if anyone played that)
My window:
If you uncheck the randoms then fields appear that let you manually enter the name and countdown values. Clicking the create button will generate 100 scriptable objects of my card class with random names in the format AdjectiveAnimal:
Each of those have a random stat line with parameters determined by the countdown value, a random image, and a random color.
The results in-game (placeholder only, not playable yet):
Can share code if anyone wants to know how it is done. This is fairly trivial programming but it just seems overwhelming when you are first starting because Unity has so many interlocking systems that you need to familiarize yourself with to be effective.
Last week I said I was committed to making the platforming demo happen this week.
This is why I don't usually say things like that.
I absolutely could have gotten a visual demo of the platforming logic ready for this week... if I hadn't tripped over some things that I'd left lying around unfinished:
- I found a few more cases that needed covering by unit tests in the platforming system.
- I wound up having to re-do some of the logic involved in configuration values in order to allow changes made at run-time to propagate to their readers.
- Someone, somewhere has to say "this object is allowed to slide down surfaces as a result of gravity when it's on the ground" (as opposed to, say, more Mario-like platforming behavior where Mario stands still on angled surfaces). For some reason I had that as part of the "Ground State" component, instead of being on the "affected by gravity" component. I moved it there.
- While putting together the animations for the platforming demo, I realized that after converting the inter-component references to use string names instead of integers, I completely forgot to update the animation editor to account for that change. So I did some editor work there just to be able to use the thing again.
- On a related note, I discovered that when I enabled scaling in my animation editor, I completely forgot to make the collision volume editor side of it scaling-aware. So the collision volumes always display the same size regardless of the associated sprite's current zoom. Oops.
- I had to patch up some things in the sprite-drawing system, like adding a value to let sprites display flipped horizontally.
- While I was there, I noticed that the "perfect pixels" value in the drawing system (essentially, "scale up if possible, but the ratio should be a whole integer") could be converted into a configuration value, so I did.
- And then I abruptly realized that I had no game plan for handling character state machines, so I spent the rest of the time in design mode.
I'll spare you a full accounting of my work on that last front, but suffice it to say that I've had sufficient difficulty coming up with a generally-applicable solution that covers all my requirements that I'm beginning to suspect I've just got the wrong approach entirely. For the time being (and in the interest of getting to that vaunted visual demo faster) I may just go ahead and use a switch statement in one of my normal system classes and save the coming up with a reusable solution for my next task.
My favorite musical instrument is the air-raid siren.
Been pretty sick for a month, recuperating for about a week and a half now. So slowly picking up the gamedev again, for example with this plane model I thought was already half done but I somehow deleted not just the folder but also the references...
Been pretty sick for a month, recuperating for about a week and a half now. So slowly picking up the gamedev again, for example with this plane model I thought was already half done but I somehow deleted not just the folder but also the references...
Well, that looks like roughly half the plane is present, so that still counts. (Unless you're rebuilding the model from scratch, in which case ouch.)
Also, is that a historical plane? The layout looks familiar but I can't quite recognize it yet.
It does at that, similar design challenges I think. This is actually a Supermarine Sea Lion II, the 1922 Schneider Trophy winner. It's much smaller than the Catalina. It does have a very rounded fuselage compared to the other racers of it's time, which makes adding the lettering fun
Also weird engine mount which only makes sense once the wing will be added...
@Zibblsnrt had to rebegin from scratch. Added difficulty is that this is a very undocumented plane, with enough differences from its successor to trip me up once a while.
Got the underground view mostly working, with some crossfade to switch between overground and underground views. For the underground geometry I just went with the standard Diablo-like view where walls are low enough to not block the view and the ceiling is conveniently invisible.
The lighting is still bad, demonstrating my lack of experience with level design & lighting. I'll figure it out eventually.
It never rains but it pours. I thought I was close to having the platforming demo done, but it turned out that there were like a million little blocking problems still in the way. Here's what I ran into this week:
- The ComponentStorage class that... stores components has a method called Compress() that sizes all the component arrays to exactly the required size to hold all the entities that actually exist. It turned out that there was a major indexing error that meant that if you tried to compress a ComponentStorage that had three or more archetypes (combinations of components), it would explode.
- Object pooling is great for avoiding GCs, but my implementation essentially imposes C-style memory responsibilities on the programmer and I'd completely forgotten to make the "component references" part of a Component Storage instance object pooling-aware, which resulted in a use-after-free issue that was difficult to track down.
- It turned out that default values for Components weren't getting assigned when you added them to an existing Entity, which made editing them a pain.
- ... and the default value for the "first collision info related to this collision volume" value on collision volumes didn't correctly default to the sentinel / invalid value, so it had another indexing failure and exploded.
- When you declared a component an optional part of a buffered query and none existed, there was a null reference because the "Has Value" buffer wasn't null-checked before trying to release it.
- A whole bunch of Systems didn't have their priority values set, so I had to run around and give them those values.
- The "center camera on target" system used for... centering the camera on a specific target... had to be rewritten from scratch, since I created it before the idea of buffered component queries existed.
- It turns out that my function for calculating the grid-coordinates of a tile you're placing in the level editor was always wrong for cases where the editor's center was offset (such that you could only ever paint within the bounds of one screen), and my demo is larger than one screen, so...
- Remember how I said that the intercomponent references system wasn't properly handled for the purposes of object pooling? Turns out it also wasn't properly handled when combining ComponentStorage instances, such that the references defined in the donor ComponentStorage just got dropped on the floor.
- Since sprite animations don't update the collision information until they actually flip to a new frame of animation, single-frame animations would never actually emit the collision info.
- ... and then it turned out that I just plain hadn't implemented propagation of collision info from sprite animations at all, so I had to build that whole code path from the ground up.
- And then I discovered that due to an overly-generally named variable, the sprite animation system was sending every collision info update to the first entity, in the batch, meaning one block wound up with a Sonic-shaped bodybox and everything else was an elaborate hoax.
My next goal is a cleaning pass, because I certainly seem to have left a lot of half-finished features lying around. I've got a plan to fix the methods related to vector magnitudes, because I've noticed that they're still vulnerable to precision loss from my fixed-point number system. Then, the next big adventure is packing the whole engine up and moving it into .NET Core, because that's the future of MonoGame.
My favorite musical instrument is the air-raid siren.
Ran into a minor roadblock with the card game. In my game card units you play on board have a countdown where they can't attack for a certain number of turns.
I wanted to create an indicator to the player that the units countdown was up and it was attacking (other than the counter display going to zero). The method I picked was a particle system spawning an exclamation point that grew and then faded away, metal gear style. Unfortunately Unity doesn't appear to have a native mechanism to draw particles over screen space UI elements, regardless of how you set the render layers.
I could replicate what I want by animating a UI element but I wanted to figure out how to make this work because particles are much more flexible for future vfx. I found this tutorial https://youtu.be/hiRdux33UCs which led to this library https://unityuiextensions.tumblr.com/
It seems like the UI extensions would be worth learning.
If anyone would like to try to break it, I would appreciate it. There's a WebGL version and a W64 version, should be identical but you know how it goes. The saves should work, so you should be able to go to the inventory, write the name of the save, and click save and reload it just fine (although other people testing is always welcome, I feel the UI is good enough since I'm not selling a UI thing but I'm probably just being lazy).
The following rarity types are implemented:
Common
Rare
Epic
Legendary
The following traits are possible on the equipment drops:
Element Attack (Cold, Lightning, Fire)
Element Resist (same as above)
Stat increases (Dexterity, Str, Vitality, Intelligence)
Resource increases (Health and Mana)
The following things could drop
Cutlass (Common, Epic, Legendary)
Boots (Common)
Chest (Common, Epic)
Worn Chest (Common)
Pants (Common)
Left Shoulder (Common)
Right Shoulder (Common)
Wait (Common)
Necklace (Common)
Health potion
All art is free stuff from the Asset Store or things I've bought over the years.
Implemented but not quite ready for the demo...
Classes that restrict Equipment (e.g. warriors can wear Plate, mages can't)
Traits that improve Skills by % percent
Passive Skills (like auras or mantras, although now that I think about it, maybe they will work if you hit 1 and 2...)
Skill Effects such as Cleave, Drain Resource, Knockback (single and AOE), and a few other buff effects.
Being able to change skills.
Well, that was good for me to list out. I need to start revising the documentation.
I'm pretty happy how the loot tables turned out with Scriptable Objects. The Loot Table in the picture lists off all the items in the All Possible Items list with their name and % chance to drop. The weights for these drops are located on the rarity type, so this is why most of them are ~8.85% to drop (common) but the Epic Chest is ~2.65% to drop (Epic).
Any reason you're physically modeling the lettering? That seems like something you could do by texture instead?
All right, that would be a good way to get customization on the text.
The reason I'm not using textures for that is because I'm using a common texture for all planes. Being on mobile I really want to limit the texture use (even more when I started on this game 3 years ago). Aside from engine and wood textures, all planes are mapped to use only the first 4 tiles in an 8*8 texture grid. I created a shader that allows the user to remap any of the other tiles to those first 4 so that they can customize the plane colors.
Downside is that I'm applying small texture squares over and over.
I probably could have gotten a text overlay to work with the shader (it already uses 4 texture masks) but it would have made the texture mapping a lot harder.
I feel like the extra tris/verts on all that text, plus whatever shading issues you're going to run into, plus the extra time you spend working that way, would hit you harder than one more texture.
I feel like the extra tris/verts on all that text, plus whatever shading issues you're going to run into, plus the extra time you spend working that way, would hit you harder than one more texture.
Very likely, at this point, it's more of a historical leftover than super useful. But I don't have a good vector editing tool anymore so actually modeling the text in Blender costs less time than it would in Gimp[/quote]
Anyway, that pales to the next tale of woe and me being stupid.
Over the last three years, I've been working on a good 'world' scene builder. You've seen the blocky results, blocks (or meshes) popping up as a character runs around a generated world.
So I figured something out.
What I was doing initially was creating blocks, adding them to an array, then switching them on or off depending on distance from the player position on the array 'grid'.
To do so I had to chuck those close to the player into a separate array (or list), then deduct the ones that were already 'on' but did not need to be switched off, then select the ones that were on but did need to switch off from a third, 'last blocks' array, then switch on the ones that were in the new but not in the 'last blocks' array... It got complicated, but it worked.
I focused on landscape generation for a while, then added pathfinding for fun. Oh, and for roads.
I went towards using entities in the end, but bugged out when Unity changed the basic functionality of creating a block entity overnight. For realz. Three times in a row.
Back to mono it was! This time I had also learned about 2d arrays.
So I went back into the save old array, subtract new array, subtract third array, etc etc. And (maybe because of the virus) I was too stupid to make it work. So I went of on a side angle and introduced a 'rolling' array of blocks that would swap front to back, like a caterpillar track with only the bits on the ground.
Well, that didn't work because there's no easy swapping in 2D arrays.
Then I figured, what if I use a reference which changes while the blocks stay in their array spot!?
I started sketching it out on paper because I actually am not that smart, and then after ruminating on this, it clicked.
So now I have a Vector2Int 'offset' that gives offset.x and offset.y.
If my character moves up one x in the grid, I update the position and type of the blocks on row offset.x (this moves them in the scene) and then raise offset.x by one.
Next move up one x, I update the offset.x row and raise offset.x again by one. I circle offset.x around if it goes over arraysize-1 or under 0.
Ditto for y.
One array, one Vector2Int, almost no calculation needed, and I don't touch any block that shouldn't move.
I can overlay other functions, say between 16 and 48 on a 64*64 array, to work on the same array and change the detail of the blocks and add bounding boxes... And I'll be using it everywhere; flying cars in my FNS sci-fi game, maybe even replace the default Unity LOD function, a 3D version in my 'turbinehead' game for a 3d maze, etc. etc.
So, yeah, that was quite a journey to come to that one insight.
I figure it's probably on page 16 of that CompSci course I never took...
Unity crap: turns out you don't need the UI extension package to generate particles over UI objects. First you set the parent canvas to render to screenspace-camera (instead of overlay), then you create a sorting layer that is above default, then you set that sorting layer to the renderer of your particle system
In the prefab editor the particle system will still show up as under the UI because there doesnt appear to be a way to chance the canvas renderer there. But in the game the particles will be on top.
This technique was advised to me by the excellent dev stream toasterfuel
who I've been following for a while now. His game is Deleveled and it should be studied by every upcoming dev as a treatise on how to develop "juice" and immersive visuals using only primitives, procedural animation and shaders.
I'm doing some lunch-hour messing around with it, and I'm having kind of an odd challenge writing debug statements, of all things. When an instance of an object gets created, I want it to output a debug message that says, basically, "Hi, I'm [object] [id] and I have been created with [variable values] at [x],[y]."
I've got everything except the "[x],[y]" portion working, and the docs for this are indicating that it might be kinda crazy hard to do this? Like, that seems like something that should be pretty simple to do, but ...
(ED: I did manage to get things to spawn in a grid pattern, which is kinda cool.)
EDIT: AHAH! It's way too simple ... There are built-in variables x and y. That should've been way easier to find.
Over the weekend, I did some cleanup work on my codebase. Swept out any commented code that wasn't a reference implementation or something like that, deleted classes that had no references (anything I actually plan to use has been employed in the test project to demonstrate that it works), and so on. Then I had a pretty hellacious on-call shift at my job, so I just didn't have the energy to do creative work most of the weekdays.
So, just to pad this out a bit, an observation from my time playing Yooka-Laylee: there are a lot of subtle nuances to UI that affect how it feels to interact with, and one of the ones that's easy to neglect is transitions. There are basically no objects in our day-to-day world that cause an entire region of our vision to change its disposition, and when it does, it startles the hell out of us. So, if a dialog is going to pop up, always give it a transition of some sort-- even if it's just 3 frames to go from transparent to opaque. Slam-cut transitions feel bad to interact with and look amateurish.
And just to pad this out even more, something I'll pass along that I discovered under irrelevant circumstances. If you want to make your own music, you tend to have to learn specialized tools to get it-- software tools, I mean, though I guess that applies to real-world music too-- all of which have their own UI conventions that can be tough to break into. Sonic Pi (https://sonic-pi.net/) is a tool for live or structured playback that has its own scripting language-- meaning, you can write a function that plays three kicks and a snare with a delay after each, spin off a thread that runs that loop, and have a drum loop. It's maybe not the most efficient way of getting music in the long run, but it could be a neat starting point (and it's fully-featured enough for someone to run a small concert out of it). Just something to keep in your back pocket.
EDIT: As for projected work, my plans are to look into formalizing player input mapping, with an emphasis on compactly recording inputs for later playback. I ran into a weird edge case where my platforming body caught the corner of a tile and shot into the air backward, which made me wish I was able to play back the session inputs to get it to happen again.
Kupi on
My favorite musical instrument is the air-raid siren.
So I have a dilemma...
Well not a dilemma, but a strange case of upside-down writers block. I have recently become intrigued with an older youtube video of a blind guy play Zelda:OoT. I thought wouldn't it be kind of fun to make a 3D action RPG for the blind. So for the last few months I've been tooling with a little prototype, and hey! you know what? This is kind of fun.
The engine is actually a 2.5D sector-based system like Duke3D or OG Doom. The neat bit is that you don't need to store that data in BSP trees or use portals. You assign a "material" to the walls/floor/ceiling that makes a noise when you step/collide/hit it, and you can place "sound sprites" in 3D space (Thanks OpenAL!) and do scripted things... (Those are hard-coded for now, but may be broken out with Lua)
The game has the ability to give your character a melee weapon (staff, but can be a cane, sword whatever) you can use to tap/hit things, you also can have a ranged weapon, and a grapple that can pull you to things and things to you. (Depending on the thing you hit). Targeting is done via a "Navi" and Z-Lock because watching the blind guy use it so effectively I can't help but to completely rip off that mechanic. One analog stick (right) is for head swivel, the other is movement. The character can crouch, which allows them to "creep" to edges without falling over, and enter 1 meter tall openings. The character can also climb over 1 meter obstructions. Each footfall is one meter apart (half that when crouching) and one every 45 degrees when spinning in place. Dpad is for left face, right face, about face. Analog triggers are strife, and shoulders are the target lock switch. Buttons are jump, action, switch weapon, and Navi call-out, take-back. Start is your menu
I'm done playing with my prototype and now I'm going to refactor it into something more stable. However here is the crux...
I have no idea what to make the game about!!!
I only have interesting locations, but nothing to tie them together. City street, subway, ship, plane, peaceful village, cave network, castle? I can't even think of a genre... Fantasy? Scifi? What should my "Navi" be? I am right stuck.
My initial plan was making the main character a cyborg with a failed vision implant slated for recycling and he escapes with a cyborg Budgerigar with a higher than normal intelligence. Maybe a talking dog... I don't know. I couldn't come up with any good ideas. Anyone want to throw some idea cards into a hat?
refactor fun time....commenting out 1k lines of code knowing i will probably not reuse any of the syntax, just the basic logic flow. It feels weird but also i intellectually know it is necessary to pay off the technical debt incurred during the implementation of the "make it work NOW" proof of concept
Hello, rubber ducks! Time for some debugging assistance.
So, my lunch-hour game-creation process is going pretty well all things considered, but has hit a bit of a snag.
I've got a player that can move around a room and attack, some rudimentary (but working) UI elements, and a simple AI script for the badguys that has them, currently, move to an empty spot near the player and announce that they'd like to attack (but not actually attack yet).
Since this is a turn-based game, I store a variable on whether it's the player's turn or not. Currently, the only way to end the player's turn is to move and attack (in any order), but in the future there'll be an "end turn now" option if you, for some reason, don't want to do both.
Completing your move sets the "player_moved" variable to true, and checks in with a little watcher script to see if the player has also attacked.
Completing your attack sets the "player_attacked" variable to true, and checks in with a little watcher script to see if the player has also moved.
If both of those are true, the little watcher script turns off the player's turn (player_turn = false; controls whether or not certain UI elements work) and invokes the badguys' AI script. That script basically iterates through all of the badguys, and each one: iterates through the spots near the player until it finds one that's empty; announces its intention to move there; announces its decision to stay in place if it can't find an empty spot; determines whether or not it'll be attacking (hardcoded false at the moment); determines (eventually) the results of the attack; then passes all that back up to the main game controller. The main game controller then handles moving the enemy, updating the grid that stores where everything is, (eventually) applying enemy attack results, etc. Then it finishes up by clearing the turn variables so that it's the player's turn again (player_moved = false; player_attacked = false; player_turn = true).
And all of that up until this point works basically flawlessly. (There's a bug regarding potentially deleting room features from the grid when something runs into one, but the only non-AI way to move things around right now is a debug function I made that forces things to move, so I'm not super concerned about it at the moment.) I've got all kinds of debug statement outputs throughout the process, where the watcher script says whether or not the player's turn is over, each badguy on their turn announces that it's their turn and where they are, they announce which spot they're moving to, they move, they announce the completion of the move, we announce when the badguys are done and it's the player's turn again ... Etc. All of that flows properly and I can step through the code and watch it happen, including checking the grid against what should be happening in the code and is happening on-screen. It all works.
Until the game hands control back to the player, at which point a bunch of enemies move, the player sprite disappears from the screen, at least one badguy runs into a room feature and runs the interaction code ...
... And I have no idea what's causing that.
So I think I need to strip (comment) out the entirety of the AI script and just have the watcher announce that it's the enemies' turn, do nothing, and hand control back to the player, and see if that works?
Posts
Edit: I think I mostly figured out my Animator issue, though not without a little tedium. I'm working now on doing some kind of interactive idle game, inspired in part by Incremancer. I know there's a community for games like that with very low production values that I'm pretty confident I can hit. Nothing to show for a little while though.
Well, it came down to the wire, and required me taking a day off of work (which I was going to do anyway but shhhh), but I got a little bit of work done this morning, so hey, we broke the streak, it was only 2.99 weeks without any game dev instead of 3.
Returning to my platforming body movement system with fresh eyes, I immediately spotted an opportunity to compress the handling of various cases into a single handler, so I went ahead and did that refactor. It isn't done yet, and it blocked the planned unit testing, but it's going to make the eventual unit testing and debugging a lot easier, so whatever, I'm calling it a win.
Since it took place in my designated game programming time, a tale of some other recreational programming I did this week: I've been playing Murder By Numbers recently, which is either a picross game with a visual novel attached, or a visual novel with a picross game that shows up whenever you spot a clue, depending how you look at it. For whatever reason, they gate some extra content behind your ability to solve these picross puzzles without using the built-in assists, such as handing you the next move or pointing out where you've filled a square in incorrectly. To get the maximum rank, you have to complete every puzzle in a chapter without using any assists. Well, imagine my shock when I got to the end of case 3 with only an A-Rank, when the maximum is S-Rank. It turns out that there's a piece of evidence in that case (and only in case 3) that you can miss by not investigating a particular area at a particular time, and since I caught on to what was happening in that case early, I managed to bypass it. And you can't just go back and re-attempt individual puzzles; if you want a better rank, you have to re-play the entire chapter and every puzzle in it. Now, at this point a normal person would just go look up picross solvers online, because if there's something that shows up in a crossword puzzle book, there's a solver for it online. But that felt like too little work to be entirely fair, so, I went and wrote my own.
If you've never played picross, the idea is that you have a two-dimensional grid of cells and your objective is to fill in a particular set of cells such that they form a picture. (You usually have to be told what exactly you're looking at after the fact for the image to make sense, but I digress.) To help you figure out which cells are the correct ones, each row and column is annotated with a series of numbers that indicates how many "spans" there are in that row or column and how many cells they consist of. So, if the first row has "1 3 2 2" next to it, that means that there's a span of one cell, three cells, two cells, and two cells, in that order, with at least one blank cell between each one.
Making a computer solve picross is actually fairly easy if you don't mind applying a bit of brute force to it. Leaving boring stuff like parsing input files and rendering the solved puzzle out, here's how it goes:
- For each row and column, enumerate all possible blank/marked combinations that solve that row or column.
- Put all of the rows and columns into a bucket. To help the algorithm converge faster, I sorted them in ascending order of number of possible solutions, then in descending order by largest span, which leaves rows or columns likeliest to have useful information at the front of the bucket.
- Loop through the contents of the bucket until nothing is left in the bucket OR you reach a maximum number of iterations*.
- For each potential solution in the current row or column, remove the solution if it contradicts the current state of the grid. (Says "filled" where the grid says "blank" or says "blank" where the grid says "filled".) If this leaves zero solutions associated with the row or column, error out-- the puzzle is flawed.
- If every remaining solution in the row or column agrees on the state of a particular cell, write that state onto the grid.
- If there is only one solution in the row or column, remove that row or column from the bucket.
And that's it! There are some logical tricks I use when solving puzzles manually that aren't represented in this algorithm, but I've yet to see it fail to solve any of the puzzles in Murder By Numbers. As for that asterisk about the maximum number of iterations, I found that it's actually possible to create a picross puzzle that has multiple solutions, in which case the algorithm I wrote will loop infinitely, since it can't ever reach a single solution. With the iteration limit, you still get the majority of the solution, and the ambiguous cells will be indicated as such.
The lesson to take away from this for game devs: proofread your goddamned story flags. Or some angry nerd will write a program that kicks your program's ass.
It works happily in Firefox, at least for me. The "you've got an asteroid nearby" pulsing is interesting, too.
(I'm also getting screwed in it by my own project - the ship in mine can reverse, so I keep reflexively trying to do that only to faceplant into a rock when trying out your game. Doh!)
Thanks for playing! And TY for the report on firefox. The pulsing is supposed to be a "heartbeat" but it looks like compile to webgl does some compression so it doesn't sound like that anymore.
In case anyone is interested in something like this, I was able to get this working by using vertex paint in blender and then using a vertex color node in shader graph. Now I am able to keep all of the objects rooted to the ground even though they are not in the same orientation or Y position in the texture.
GDC Relief Bundle
A bundle hosted by gamedev.world with content from 104 creators.
Pay what you want for 167 items
https://itch.io/b/471/gdc-relief-bundle
What we have now is something a bit more limited in scope, a diablo-esque ARPG Loot, Stat, and Item system.
As an additional note, I started incorporating in Art assets to my personal project Voxel Fight, and I thought this tumbling feature was just too funny not to share.
The shelter in place culture has allowed me to really focus on various projects for work and personal, which is great so as long as I keep my job.
A promising method is to use the SceneCapture, which renders a scene and dumps it onto a render texture. The key point is that you can tell it "only render these objects" so I could use it to render only the underground objects and then blit that over the normal view, or crossfade between the normal view and the "only rendering underground things" view.
The main problem I'm having now is that the SceneCapture camera doesn't do auto exposure (eye adaptation) the same as the main view, so when you are underground everything looks really dark. I'm switching from 4.23 to 4.24 to see if anything improves, and then maybe switch to 4.25-preview. In 4.25 they are changing the auto exposure so it's likely any scene capture quirks would be fixed as well.
Also look into custom stencil and custom depth. It is used a lot for highlighting and outlining object even when they are obscured as a special stencil buffer render pass is done for the objects independent of the scene. You can then use the stencil buffer in post process materials to do final effect.
I know what you want is more a cutaway view when underground though and this wouldn't work for that. Making all the overground objects render with masked material that you can cut out at anytime is probably the way to go. Otherwise you need a manager to switch out all materials to the transparent one whenever you go underground.
I wish they'd add a feature to be able to setup multiple render passes in UE4, would be easy in forward rendering but hard in deffered. They gave us lighting channels but I'd like geometry channels too to allow easy overlaying. Like in your case the overground and underground would just be switched with a depthbuffer clear inbetween allowing you to render the underground on top of the overground stuff.
In fact I already use custom depth/stencil to show the character when they walk behind trees and I had hoped I could just augment that, but the stencil buffer only has 256 values. This lets me color the hidden objects with a few colors but I can't use the full color & PBR values of hidden objects because I can't fit all the relevant data into the stencil buffer.
Yeah my SceneCapture hack is basically an attempt to impose my own sequence of rendering. It seems like much of UE4 is setup to make a realistic FPS, so if you want to step out of that box you'll have to fight a bunch of defaults and optimizations designed for high-grade FX and FPS mechanics. I mean it's not impossible but it seems more difficult than it should be. The Torque engine had a similar problem since it inherited a lot of code from the original Tribes games.
I managed to double the number of days I did game dev work on this week (from 1 to 2).
In that time, I got some unit tests written for my platforming body management system. Thus far, these tests confirm that:
- When a platforming body starts out airborne and has a blocking interaction with a collision volume and the surface normal is "walkable", then the associated ground state becomes "grounded" and it parents to the platform entity.
- When a platforming body is on the ground and not moving, the ground scan that resets its position onto the surface doesn't modify its position.
- When a platforming body begins a frame on the ground but the ground scan fails, it unparents from the previous surface and becomes airborne.
In writing this out I've realized that what counts as a walkable surface normal should be affected by the direction of gravity (if gravity exists). Fie. That's more work for this next week.
The remaining tests mostly involve making sure that the logic is correct for dispatching to various other cases (like "was on the ground but collided with a non-walkable surface whose surface normal points upward relative to the current surface") and then making sure that the velocity is handled correctly when those cases occur.
After that, well, I'm going to try to get a visual example put together so I have a video to show you guys in next week's report. I'll commit to that! It's going to happen! See you next Friday!
Twitch: KoopahTroopah - Steam: Koopah
Probably worth if you are planning on releasing anything for reals. A decent artist will charge that much for a single icon. But for placeholders game-icons.net has never failed me. If you are on that site enough you will even catch them being used in commercial work.
I had already bought REXXARD's icons last time they were on HumbleBundle but they were nice enough to not have that much overlap in this new pack.
Twitch: KoopahTroopah - Steam: Koopah
My window:
If you uncheck the randoms then fields appear that let you manually enter the name and countdown values. Clicking the create button will generate 100 scriptable objects of my card class with random names in the format AdjectiveAnimal:
Each of those have a random stat line with parameters determined by the countdown value, a random image, and a random color.
The results in-game (placeholder only, not playable yet):
Can share code if anyone wants to know how it is done. This is fairly trivial programming but it just seems overwhelming when you are first starting because Unity has so many interlocking systems that you need to familiarize yourself with to be effective.
Last week I said I was committed to making the platforming demo happen this week.
This is why I don't usually say things like that.
I absolutely could have gotten a visual demo of the platforming logic ready for this week... if I hadn't tripped over some things that I'd left lying around unfinished:
- I found a few more cases that needed covering by unit tests in the platforming system.
- I wound up having to re-do some of the logic involved in configuration values in order to allow changes made at run-time to propagate to their readers.
- Someone, somewhere has to say "this object is allowed to slide down surfaces as a result of gravity when it's on the ground" (as opposed to, say, more Mario-like platforming behavior where Mario stands still on angled surfaces). For some reason I had that as part of the "Ground State" component, instead of being on the "affected by gravity" component. I moved it there.
- While putting together the animations for the platforming demo, I realized that after converting the inter-component references to use string names instead of integers, I completely forgot to update the animation editor to account for that change. So I did some editor work there just to be able to use the thing again.
- On a related note, I discovered that when I enabled scaling in my animation editor, I completely forgot to make the collision volume editor side of it scaling-aware. So the collision volumes always display the same size regardless of the associated sprite's current zoom. Oops.
- I had to patch up some things in the sprite-drawing system, like adding a value to let sprites display flipped horizontally.
- While I was there, I noticed that the "perfect pixels" value in the drawing system (essentially, "scale up if possible, but the ratio should be a whole integer") could be converted into a configuration value, so I did.
- And then I abruptly realized that I had no game plan for handling character state machines, so I spent the rest of the time in design mode.
I'll spare you a full accounting of my work on that last front, but suffice it to say that I've had sufficient difficulty coming up with a generally-applicable solution that covers all my requirements that I'm beginning to suspect I've just got the wrong approach entirely. For the time being (and in the interest of getting to that vaunted visual demo faster) I may just go ahead and use a switch statement in one of my normal system classes and save the coming up with a reusable solution for my next task.
Well, that looks like roughly half the plane is present, so that still counts. (Unless you're rebuilding the model from scratch, in which case ouch.)
Also, is that a historical plane? The layout looks familiar but I can't quite recognize it yet.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
It does at that, similar design challenges I think. This is actually a Supermarine Sea Lion II, the 1922 Schneider Trophy winner. It's much smaller than the Catalina. It does have a very rounded fuselage compared to the other racers of it's time, which makes adding the lettering fun
Also weird engine mount which only makes sense once the wing will be added...
@Zibblsnrt had to rebegin from scratch. Added difficulty is that this is a very undocumented plane, with enough differences from its successor to trip me up once a while.
Wow, that thing's engine mount is surreal.
Any reason you're physically modeling the lettering? That seems like something you could do by texture instead?
The lighting is still bad, demonstrating my lack of experience with level design & lighting. I'll figure it out eventually.
It never rains but it pours. I thought I was close to having the platforming demo done, but it turned out that there were like a million little blocking problems still in the way. Here's what I ran into this week:
- The ComponentStorage class that... stores components has a method called Compress() that sizes all the component arrays to exactly the required size to hold all the entities that actually exist. It turned out that there was a major indexing error that meant that if you tried to compress a ComponentStorage that had three or more archetypes (combinations of components), it would explode.
- Object pooling is great for avoiding GCs, but my implementation essentially imposes C-style memory responsibilities on the programmer and I'd completely forgotten to make the "component references" part of a Component Storage instance object pooling-aware, which resulted in a use-after-free issue that was difficult to track down.
- It turned out that default values for Components weren't getting assigned when you added them to an existing Entity, which made editing them a pain.
- ... and the default value for the "first collision info related to this collision volume" value on collision volumes didn't correctly default to the sentinel / invalid value, so it had another indexing failure and exploded.
- When you declared a component an optional part of a buffered query and none existed, there was a null reference because the "Has Value" buffer wasn't null-checked before trying to release it.
- A whole bunch of Systems didn't have their priority values set, so I had to run around and give them those values.
- The "center camera on target" system used for... centering the camera on a specific target... had to be rewritten from scratch, since I created it before the idea of buffered component queries existed.
- It turns out that my function for calculating the grid-coordinates of a tile you're placing in the level editor was always wrong for cases where the editor's center was offset (such that you could only ever paint within the bounds of one screen), and my demo is larger than one screen, so...
- Remember how I said that the intercomponent references system wasn't properly handled for the purposes of object pooling? Turns out it also wasn't properly handled when combining ComponentStorage instances, such that the references defined in the donor ComponentStorage just got dropped on the floor.
- Since sprite animations don't update the collision information until they actually flip to a new frame of animation, single-frame animations would never actually emit the collision info.
- ... and then it turned out that I just plain hadn't implemented propagation of collision info from sprite animations at all, so I had to build that whole code path from the ground up.
- And then I discovered that due to an overly-generally named variable, the sprite animation system was sending every collision info update to the first entity, in the batch, meaning one block wound up with a Sonic-shaped bodybox and everything else was an elaborate hoax.
... and then I had an actual-ass platform game.
My next goal is a cleaning pass, because I certainly seem to have left a lot of half-finished features lying around. I've got a plan to fix the methods related to vector magnitudes, because I've noticed that they're still vulnerable to precision loss from my fixed-point number system. Then, the next big adventure is packing the whole engine up and moving it into .NET Core, because that's the future of MonoGame.
I wanted to create an indicator to the player that the units countdown was up and it was attacking (other than the counter display going to zero). The method I picked was a particle system spawning an exclamation point that grew and then faded away, metal gear style. Unfortunately Unity doesn't appear to have a native mechanism to draw particles over screen space UI elements, regardless of how you set the render layers.
I could replicate what I want by animating a UI element but I wanted to figure out how to make this work because particles are much more flexible for future vfx. I found this tutorial
It seems like the UI extensions would be worth learning.
https://ventedpennies.itch.io/arpg-item-and-stat-system
If anyone would like to try to break it, I would appreciate it. There's a WebGL version and a W64 version, should be identical but you know how it goes. The saves should work, so you should be able to go to the inventory, write the name of the save, and click save and reload it just fine (although other people testing is always welcome, I feel the UI is good enough since I'm not selling a UI thing but I'm probably just being lazy).
The following rarity types are implemented:
The following traits are possible on the equipment drops:
The following things could drop
All art is free stuff from the Asset Store or things I've bought over the years.
Implemented but not quite ready for the demo...
Well, that was good for me to list out. I need to start revising the documentation.
I'm pretty happy how the loot tables turned out with Scriptable Objects. The Loot Table in the picture lists off all the items in the All Possible Items list with their name and % chance to drop. The weights for these drops are located on the rarity type, so this is why most of them are ~8.85% to drop (common) but the Epic Chest is ~2.65% to drop (Epic).
All right, that would be a good way to get customization on the text.
The reason I'm not using textures for that is because I'm using a common texture for all planes. Being on mobile I really want to limit the texture use (even more when I started on this game 3 years ago). Aside from engine and wood textures, all planes are mapped to use only the first 4 tiles in an 8*8 texture grid. I created a shader that allows the user to remap any of the other tiles to those first 4 so that they can customize the plane colors.
Downside is that I'm applying small texture squares over and over.
I probably could have gotten a text overlay to work with the shader (it already uses 4 texture masks) but it would have made the texture mapping a lot harder.
Anyway, that pales to the next tale of woe and me being stupid.
Over the last three years, I've been working on a good 'world' scene builder. You've seen the blocky results, blocks (or meshes) popping up as a character runs around a generated world.
So I figured something out.
What I was doing initially was creating blocks, adding them to an array, then switching them on or off depending on distance from the player position on the array 'grid'.
To do so I had to chuck those close to the player into a separate array (or list), then deduct the ones that were already 'on' but did not need to be switched off, then select the ones that were on but did need to switch off from a third, 'last blocks' array, then switch on the ones that were in the new but not in the 'last blocks' array... It got complicated, but it worked.
I focused on landscape generation for a while, then added pathfinding for fun. Oh, and for roads.
I went towards using entities in the end, but bugged out when Unity changed the basic functionality of creating a block entity overnight. For realz. Three times in a row.
Back to mono it was! This time I had also learned about 2d arrays.
So I went back into the save old array, subtract new array, subtract third array, etc etc. And (maybe because of the virus) I was too stupid to make it work. So I went of on a side angle and introduced a 'rolling' array of blocks that would swap front to back, like a caterpillar track with only the bits on the ground.
Well, that didn't work because there's no easy swapping in 2D arrays.
Then I figured, what if I use a reference which changes while the blocks stay in their array spot!?
I started sketching it out on paper because I actually am not that smart, and then after ruminating on this, it clicked.
So now I have a Vector2Int 'offset' that gives offset.x and offset.y.
If my character moves up one x in the grid, I update the position and type of the blocks on row offset.x (this moves them in the scene) and then raise offset.x by one.
Next move up one x, I update the offset.x row and raise offset.x again by one. I circle offset.x around if it goes over arraysize-1 or under 0.
Ditto for y.
One array, one Vector2Int, almost no calculation needed, and I don't touch any block that shouldn't move.
I can overlay other functions, say between 16 and 48 on a 64*64 array, to work on the same array and change the detail of the blocks and add bounding boxes... And I'll be using it everywhere; flying cars in my FNS sci-fi game, maybe even replace the default Unity LOD function, a 3D version in my 'turbinehead' game for a 3d maze, etc. etc.
So, yeah, that was quite a journey to come to that one insight.
I figure it's probably on page 16 of that CompSci course I never took...
For a good free vector editing program, try https://inkscape.org/
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
In the prefab editor the particle system will still show up as under the UI because there doesnt appear to be a way to chance the canvas renderer there. But in the game the particles will be on top.
This technique was advised to me by the excellent dev stream toasterfuel who I've been following for a while now. His game is Deleveled and it should be studied by every upcoming dev as a treatise on how to develop "juice" and immersive visuals using only primitives, procedural animation and shaders.
I'm doing some lunch-hour messing around with it, and I'm having kind of an odd challenge writing debug statements, of all things. When an instance of an object gets created, I want it to output a debug message that says, basically, "Hi, I'm [object] [id] and I have been created with [variable values] at [x],[y]."
I've got everything except the "[x],[y]" portion working, and the docs for this are indicating that it might be kinda crazy hard to do this? Like, that seems like something that should be pretty simple to do, but ...
(ED: I did manage to get things to spawn in a grid pattern, which is kinda cool.)
EDIT: AHAH! It's way too simple ... There are built-in variables x and y. That should've been way easier to find.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
Over the weekend, I did some cleanup work on my codebase. Swept out any commented code that wasn't a reference implementation or something like that, deleted classes that had no references (anything I actually plan to use has been employed in the test project to demonstrate that it works), and so on. Then I had a pretty hellacious on-call shift at my job, so I just didn't have the energy to do creative work most of the weekdays.
So, just to pad this out a bit, an observation from my time playing Yooka-Laylee: there are a lot of subtle nuances to UI that affect how it feels to interact with, and one of the ones that's easy to neglect is transitions. There are basically no objects in our day-to-day world that cause an entire region of our vision to change its disposition, and when it does, it startles the hell out of us. So, if a dialog is going to pop up, always give it a transition of some sort-- even if it's just 3 frames to go from transparent to opaque. Slam-cut transitions feel bad to interact with and look amateurish.
And just to pad this out even more, something I'll pass along that I discovered under irrelevant circumstances. If you want to make your own music, you tend to have to learn specialized tools to get it-- software tools, I mean, though I guess that applies to real-world music too-- all of which have their own UI conventions that can be tough to break into. Sonic Pi (https://sonic-pi.net/) is a tool for live or structured playback that has its own scripting language-- meaning, you can write a function that plays three kicks and a snare with a delay after each, spin off a thread that runs that loop, and have a drum loop. It's maybe not the most efficient way of getting music in the long run, but it could be a neat starting point (and it's fully-featured enough for someone to run a small concert out of it). Just something to keep in your back pocket.
EDIT: As for projected work, my plans are to look into formalizing player input mapping, with an emphasis on compactly recording inputs for later playback. I ran into a weird edge case where my platforming body caught the corner of a tile and shot into the air backward, which made me wish I was able to play back the session inputs to get it to happen again.
Well not a dilemma, but a strange case of upside-down writers block. I have recently become intrigued with an older youtube video of a blind guy play Zelda:OoT. I thought wouldn't it be kind of fun to make a 3D action RPG for the blind. So for the last few months I've been tooling with a little prototype, and hey! you know what? This is kind of fun.
The engine is actually a 2.5D sector-based system like Duke3D or OG Doom. The neat bit is that you don't need to store that data in BSP trees or use portals. You assign a "material" to the walls/floor/ceiling that makes a noise when you step/collide/hit it, and you can place "sound sprites" in 3D space (Thanks OpenAL!) and do scripted things... (Those are hard-coded for now, but may be broken out with Lua)
The game has the ability to give your character a melee weapon (staff, but can be a cane, sword whatever) you can use to tap/hit things, you also can have a ranged weapon, and a grapple that can pull you to things and things to you. (Depending on the thing you hit). Targeting is done via a "Navi" and Z-Lock because watching the blind guy use it so effectively I can't help but to completely rip off that mechanic. One analog stick (right) is for head swivel, the other is movement. The character can crouch, which allows them to "creep" to edges without falling over, and enter 1 meter tall openings. The character can also climb over 1 meter obstructions. Each footfall is one meter apart (half that when crouching) and one every 45 degrees when spinning in place. Dpad is for left face, right face, about face. Analog triggers are strife, and shoulders are the target lock switch. Buttons are jump, action, switch weapon, and Navi call-out, take-back. Start is your menu
I'm done playing with my prototype and now I'm going to refactor it into something more stable. However here is the crux...
I have no idea what to make the game about!!!
I only have interesting locations, but nothing to tie them together. City street, subway, ship, plane, peaceful village, cave network, castle? I can't even think of a genre... Fantasy? Scifi? What should my "Navi" be? I am right stuck.
My initial plan was making the main character a cyborg with a failed vision implant slated for recycling and he escapes with a cyborg Budgerigar with a higher than normal intelligence. Maybe a talking dog... I don't know. I couldn't come up with any good ideas. Anyone want to throw some idea cards into a hat?
So, my lunch-hour game-creation process is going pretty well all things considered, but has hit a bit of a snag.
I've got a player that can move around a room and attack, some rudimentary (but working) UI elements, and a simple AI script for the badguys that has them, currently, move to an empty spot near the player and announce that they'd like to attack (but not actually attack yet).
Since this is a turn-based game, I store a variable on whether it's the player's turn or not. Currently, the only way to end the player's turn is to move and attack (in any order), but in the future there'll be an "end turn now" option if you, for some reason, don't want to do both.
Completing your move sets the "player_moved" variable to true, and checks in with a little watcher script to see if the player has also attacked.
Completing your attack sets the "player_attacked" variable to true, and checks in with a little watcher script to see if the player has also moved.
If both of those are true, the little watcher script turns off the player's turn (player_turn = false; controls whether or not certain UI elements work) and invokes the badguys' AI script. That script basically iterates through all of the badguys, and each one: iterates through the spots near the player until it finds one that's empty; announces its intention to move there; announces its decision to stay in place if it can't find an empty spot; determines whether or not it'll be attacking (hardcoded false at the moment); determines (eventually) the results of the attack; then passes all that back up to the main game controller. The main game controller then handles moving the enemy, updating the grid that stores where everything is, (eventually) applying enemy attack results, etc. Then it finishes up by clearing the turn variables so that it's the player's turn again (player_moved = false; player_attacked = false; player_turn = true).
And all of that up until this point works basically flawlessly. (There's a bug regarding potentially deleting room features from the grid when something runs into one, but the only non-AI way to move things around right now is a debug function I made that forces things to move, so I'm not super concerned about it at the moment.) I've got all kinds of debug statement outputs throughout the process, where the watcher script says whether or not the player's turn is over, each badguy on their turn announces that it's their turn and where they are, they announce which spot they're moving to, they move, they announce the completion of the move, we announce when the badguys are done and it's the player's turn again ... Etc. All of that flows properly and I can step through the code and watch it happen, including checking the grid against what should be happening in the code and is happening on-screen. It all works.
Until the game hands control back to the player, at which point a bunch of enemies move, the player sprite disappears from the screen, at least one badguy runs into a room feature and runs the interaction code ...
... And I have no idea what's causing that.
So I think I need to strip (comment) out the entirety of the AI script and just have the watcher announce that it's the enemies' turn, do nothing, and hand control back to the player, and see if that works?
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]