This week was not a lot better for attention, discipline, and emotional stability, so it's another "one token step forward" week. I implemented (with unit tests) the "create from format" function on my CharBuffer String-replacement class.
The plan for this week is to break ground on the actual text-rendering component that displays strings, along with any associated content file types.
My favorite musical instrument is the air-raid siren.
Still making good progress! I'm still not completely convinced that it's actually fun, but I think a game like this lives and dies by its meta systems and progression. So I figure if I just keep adding onto it eventually it'll become something noteworthy.
Splurged on some nice assets for enemies and backgrounds that should be suitable for a final game. Will need to commission more some day if I keep going with this, but this will get me through the prototyping stages. Also found a nice pixel health/mana orb asset in the store that I'm happy with. I don't expect to sell this but I'll be happy if anybody enjoys it.
Did a refactoring of enemies/backgrounds to be in world space rather than UI space, since doing it in UI turned out to be an unscalable hack from the initial tutorial I was following.
Implemented equippable weapons per class.
Set up a 20-floor template for any dungeon that spawns enemies randomly by difficulty tier.
A chest spawns every five rounds to give you a unique item/unlock on first clear, e.g. Archer after level 5 and Woodcutting after level 10.
I haven't done any gameplay stuff in a little while, but I've gotten started on a level editor.
I've been thinking about doing a 2D Zelda imitation for ages, but never gotten very far with it.
My immediate todo list:
Levels consisting of multiple rooms
Saving and loading of levels
Rotated tiles
Setting properties on entities, such as what item a chest contains
After that comes pretty much everything to do with actually playing levels. I've got basic movement and definitions for which tiles are solid, but not much else.
I managed to compile 4.26 by checking out a fresh copy of the source code. It took about a day to compile from scratch. Then I figured I should try the new Chaos physics so I had to toggle on a flag and recompile from scratch AGAIN, which took another day.
The reason I switched to 4.26 was to see if Runtime Virtual Textures worked better, and they do. But for other reasons they are impractical so I'll just get by with normal grass. I did some more arranging of geometry and shaders for grass. The tricky part is balancing the lighting on the grass vs. non-grass. It's hard to make everything look good without the grass blowing out to white, but I'm getting there.
Alright, this week was focused on the ARPG system. I did some refactoring for convenience, which is meh to me. Probably why I felt like I did a lot, but accomplished very little.
So now, a new user can one-click create new databases for their own game, and, if they so choose, copy over the data from the demo. This was much needed but tedious and boring, hours of work resulting into a button click. Exciting.
For more exciting stuff, I refactored the UI elements so things are more streamlined there. Someone suggested to have a drag-ability-into-ability-slot feature, which is reasonable but wasn't originally on the plan since I think many other assets do UI much better. In any case, I got it accomplished as shown from the video.
I also am working on creating some demo models to include with the package, because the default skeleton is meh. I'll eventually include a couple of demo characters, each a different class and maybe some enemies.
This week, I'm trying to write up a new description for the asset store page. I already wrote a "Quick Guide" for getting started, and once I get a new description that more accurately reflects everything the asset offers, I'll send the updates up. I was hoping to do that yesterday, but I didn't make the deadline so I'm going to use that as an excuse to write up some stuff and then make the new deadline for this weekend.
What I need for this new deadline:
Finish my first demo character with all the example abilities with animations (nearly there).
Finish the documentation revisions (halfway there).
Interesting. I'll take a look at that and see if I can fiddle something out. Have you tried setting the pivot to the 'feet'? center bottom y? I imagine that'll remain constant to the bounding box even if the height changes?
Thanks for the pics. Gives me a clearer understanding of the situation.
Okay, coming back to this after a month off, I think I have to handle it by setting the sprite pivot on each frame. I use root motion (i.e., the animation can move the transform of the root node of the animator), because of how tied actions are to animations. What this means is that I can't do things like putting the sprite node underneath a separate parent, since then root motion will just cause the sprite to move further and further away from the root.
So now I have to decide between a.) setting the sprite pivot to bottom center, then aligning the collider to the bottom of the sprite. Which means that all forces will be directed to their feet, rather than the center of gravity. Which I can work around. Or b) calculate half the height of the collider, then set the Y value of the pivot to that using a utility to mass-update a character's frames. This requires more work but keeps the collider center closer to a sprite's center of gravity.
Time to just pick one and get to making things!
I'm glad you're continuing with it!
Yeah, the issues with root motion that you mention here are why I don't use it if I can avoid it. I probably would feel different if I was an animator and could make great animations.
If you're working with forces, sounds like b) is the better bet.
Interesting. I'll take a look at that and see if I can fiddle something out. Have you tried setting the pivot to the 'feet'? center bottom y? I imagine that'll remain constant to the bounding box even if the height changes?
Thanks for the pics. Gives me a clearer understanding of the situation.
Okay, coming back to this after a month off, I think I have to handle it by setting the sprite pivot on each frame. I use root motion (i.e., the animation can move the transform of the root node of the animator), because of how tied actions are to animations. What this means is that I can't do things like putting the sprite node underneath a separate parent, since then root motion will just cause the sprite to move further and further away from the root.
So now I have to decide between a.) setting the sprite pivot to bottom center, then aligning the collider to the bottom of the sprite. Which means that all forces will be directed to their feet, rather than the center of gravity. Which I can work around. Or b) calculate half the height of the collider, then set the Y value of the pivot to that using a utility to mass-update a character's frames. This requires more work but keeps the collider center closer to a sprite's center of gravity.
Time to just pick one and get to making things!
I'm glad you're continuing with it!
Yeah, the issues with root motion that you mention here are why I don't use it if I can avoid it. I probably would feel different if I was an animator and could make great animations.
If you're working with forces, sounds like b) is the better bet.
Thanks!
I dislike root motion as implemented, but I love whenever I can move things like that out of code and into the editor. For example, the exact timing on a lunge or stumble is much easier to create and to review in the Animation window than in code.
I'm not working with forces, but there's a lot of pushing and pulling with attacks that has to come out just right to create consistent combos. I can probably deal with it by just doing the right math on the pivot, but I figure I should give it some consideration before I change how everything works
I tried out Chaos Physics in Unreal and it is definitely still a Work In Progress. I just piled a few rigid bodies on the landscape:
These are the segments of giant caterpillar built as some rigid bodies controlled via physics. They are just sitting on the landscape, not moving but not asleep. In Chaos, simulating this takes 80ms so I get about 12fps max. In a non-chaos build the simulation is sub-millisecond. I'm not sure what causes this but I don't need exploding buildings THAT badly at the moment. Maybe this stuff will be improved in 4.27 or the "chaos" development branch, I dunno.
Printing text with sprites is hard, who could have guessed?
Got more work done this week than the previous two, but I still don't have anything to demo yet.
As a minor task, I added a parameter to the [ContentPathAttribute] I made to mark string-type object members as being a file path instead of an all-purpose string. When the object editor sees a member with the [ContentPath] attribute, it gives you a ComboBox (text box with selectable options below) populated with all the file paths it can find in the content directory. Well, sometimes that file path should always point to a texture file, so it makes no sense for the editor to give you sound effects as an option. The new parameter lets you set a file extension so the editor will only offer you the right file types.
Other than that, I've made progress on the text renderer. It's capable of placing plain old sprites at a target position right now, but I still have to implement the text justification and anchor positions. I also need to create an editor for the Font object type that controls how characters in strings map to subsets of the texture file. So, all told, the feature is still half-implemented and basically untestable for now. Oh well!
Assuming I keep my head pointed in the right direction, I should have something presentable by next week. See you then!
My favorite musical instrument is the air-raid siren.
Most of this week was spent on making some core game design changes - first I removed the active clicker gameplay in favor of auto-attacks with manual skills. That allows me to design/balance around an intended gameplay flow rather than encouraging rapid click spam. I'll still introduce unlocks that allow you to automate the skill usage, albeit in a less-than-optimal way.
I still couldn't shake the feeling that something wasn't adding up about the game's premise though. You could just run headfirst into a dungeon again and again on autoplay until you get the gear/levels to overpower it - even for an idle game there's not much depth there. Then I started to think it might be more interesting as a roguelite of sorts, where you quickly level your classes and acquire gear per-run, making decisions along the way on how to specialize. Gold persists between runs and is used to unlock classes, permanent upgrades, add new loot to the pool, etc. I felt like the idle offline gathering stuff was too extraneous, with concerns about being able to trivialize the content by idling for too long, so I cut it for now. Implemented the basic shop this weekend and got the core gameplay loop mostly worked out.
That's the bare demo, boring but shows what's possible in the different rooms. I'm working on a 'stadium' scene, just one room where you can spawn dudes, collect rewards, buy stuff, and save and load. Almost like a game...
Anyways, I've decided on a few things.
One, I'm going to send updates more frequently to the store. This provides a benefit that people see that it's constantly being updated (even if it's just a line of code...), but also it'll help me track down problems if anyone has them. Much easier to locate a conflict with incremental changes, instead of landslides.
Two, now that things are at an okay place, I'm going to expose some of the editor features to the game itself. Mainly, equipment, class, and ability creation. You can already create these things in the editor, but they are made in a way so that people can also make their own at runtime.
It's pretty raw, but the general idea is there. People can add native traits, random traits, set the item level, customize prefix and suffixes, and also customize a few more things later on. The idea here is you can make it, then add it to your inventory.
Of course I fully expect people to make overpowered equipment, but one step at a time. Basically I just want to showcase the limitless possibilities, and adding custom trait types will require new code but it's pretty hand-holdy since you inherit a base class and it errors the project until you complete the required methods. But after that it'll be added as an option to these system.
Three, the last major addition will be importing/exporting basic database information to json (e.g. item name, health amount, cost, etc). This, hopefully, allows people to text edit basic values without opening Unity. It won't include all the data for each thing because, well, some of it just doesn't make sense to text edit (for instance, the leveling curves). But with this last major addition, I can start displaying more of the features (much like equipment creation above). Also, I'm interested how this will port over to unity's ECS, it should be work pretty well with the hybrid system and turning objects into entities since much of the systems are written like datacomponents.
Also, my 6 weeks since the last sale is almost up, which means I'll be increasing the price to $80 from its current $40. Of course I have many free keys if anyone wants to be a tester!
For next week, continue working on this equipment creator. Let's just focus on that for now.
I've made rather poor progress on my game, because I took a week off to be low-grade depressed (no worries, just low affect), and then I took a week off to make a Triple Triad-esque mini-game to put into my main game.
It's a distraction, but I was happy with my card-facing MonoBehaviour. Since I'm doing this with UI canvases, there's no 3d model to flip around when I turn cards. I saw some solutions online, but they seemed to have extra ideas that weren't necessary, like making an extra transform to sit above the surface of the card to give you a normal by doing extraTransform - card.transform.
So I made a card front node and card back node and selectively disable one or the other depending on the result of `bool IsFaceTowardsCamera => Vector3.Dot(cardFace.transform.forward, Camera.main.transform.forward) > 0;`
Dang that’s awesome! I’d love to make a Triple Triad game, let alone then put it in a larger game. Awesome work!
Thank you! I'm still at the stage of getting mouse dragging to work properly (I'm more of a gamepad person, but I just *know* somebody is going to want to use a mouse on this). My goal is for each game will take under 5 minutes and just be a little alternate play mode to break up the main game.
Hey, you're not going to believe this, but I actually got some stuff done this week. If doing the same parlor trick you did in Unity like three years ago counts as "getting something done".
I mentioned last week that the text renderer can place plain old sprites at the appropriate locations. To explain a little further: MonoGame has a built-in string rendering function, but I wanted to go a little further than what it offers-- rendering text as individual sprites allows me to easily reveal them one-by-one in classic pixel-game style. As sprites, they can also be tinted, made to shake, rotated, scaled, and so on. (You thought that would be self-demonstrating, didn't you? Yeah, I haven't gotten that far yet...) But it turns out that there's all kinds of tricky little nuances there, such as accounting for non-renderable characters, word-wrapping at boundary positions, defining where exactly you start rendering and how the text should be centered, and so on. There are a few lines I haven't managed to code-coverage my way onto yet, but most of it's been hit by test cases now.
... and I'd be remiss if I didn't mention the fact that I encountered a number of hilarious bugs while assembling this demo, such as characters at the bottom of the second page appearing before ones at the top, text dropping past the bottom of the boundary area, word-wrap failing on the very last word of the text box and splitting across the pages, and the "bip" sound turning into a swarm of hellbees when you play it every frame.
Naturally, since a "font" is a new object type for my engine, I had to create an editor to edit them. And while I was trying to pick out the individual letters, I realized that my sprite picker is real hard to use when you're trying to click on things that are one pixel wide. So, I wound up giving it a zoom function, which took an evening or two to finish. Then it was just a matter of putting the time in to put together this little demo.
Speaking of putting the time in, I'm really actually very much out of coding projects that don't involve producing real gameplay. So my next task is to get past the "ugh gate" and actually do some drawing and music composition in the coming weeks. I suspect the results will be disastrous, but you have to start somewhere. Whatever the outcome, though, you can count on the weekly report. See you then!
My favorite musical instrument is the air-raid siren.
Took another look at my giant monster locomotion. Also tried out the new hair stuff in UE 4.26. I had an "inchworm" monster that could sorta move around but it had many failure modes. I replaced it with a new setup that is like those little trains that toddlers pull around the house. So the new monster is a set of connected blobs with little wheels underneath. The wheels are invisible but by controlling a motor driving each wheel I can make the creature move forward and back. Turning is done by bending the joints between each segment. Here's a short clip.
The movement is pretty reliable but sometimes still gets stuck on bumps, which I can fix by making the wheels slightly bigger. Also, adding a slight wobble can help push it over ledges and other things it can get caught on.
So I had this idea rolling around for a low-fi superhero game called "The Guy in the Chair"
No graphics, just a terminal, and your job is to be, as Ned from Spider-man put's it, "The guy in the Chair", where you direct the hero where to go, watch his status as he beats up bad guys, and recall him when things get too hot. Get beat up too much, he's out a few days. Research down three skill trees. Bio, Cybernetics, and Toys. This results in late game mutant powers, cyborg powers, or... Batman with power armor(?) -- (Getting new way to travel to the crime scene is definitely under "toys")
I tossed around ideas with what city I should use, and I was too lazy to make one myself using ASCII art. However, I just came across the SimCIty 2000 file spec and I'm in love! You can upload any city, and it has everything will all there. Sewers for bad guys, subways, crime areas, police, hospitals.... and it all fits on a 40x40 grid.
So tonight I started with the terminal framework. I'm using C and my tool of choice is Msys GCC. I want to stay as cross platform as possible so the frameworks I'm using are ncurses for the terminal, and Allegro 5 for the low level game functions like filesystems and audio.
As I'm starting with Windows, I'm shimming in an API to make the console window management as generic as possible, however I found that you have a rather large command of the windows console window, such as changing the font type and size, disabling the scroll buffer, turning on and off the minimize/maximize buttons, turning on and off the ability to resize the window, and maximizing for full screen. Here I thought it was a dumb fire-and-forget window.
Game uses 80x25 text but that is subject to change depending on what I can fit on the screen. I hope to one day port it to the Commander X16
Progress has been slow lately, I still had some nagging doubts about the game for a variety of reasons, and I almost gave up on it at times. Then I had the idea to have the player character always be a wizard, with the "classes" being their elemental schools. Instead of swapping classes, you attune different elements. That way there's a much stronger emphasis on elemental strengths/weaknesses being the key to winning engagements. That has some downstream consequences which required refactors:
Class levels are replaced with just a singular character level.
Weapons are now character-wide rather than needing one weapon type per class.
Which I think makes the game somewhat more coherent, plus I think spell effects are more satisfying than little pixel sword swipes etc. Still can't guarantee how far I'll take this project but I feel like I'm making forward progress even when I delete stuff.
After that refactoring and code cleanup I added a few more features:
Elemental weaknesses - white damage text for neutral damage, grey for hitting a resistance, element-colored for hitting a weakness.
Two spells per element with particle effects. I got the effects off the asset store, and with some tinkering they make a huge difference to the combat feel.
Pick from three chests, with an upgrade to let you see their contents in advance.
I'm feeling myself start to run out of steam a bit and thinking about new ideas, but I'm trying to push myself to at least get it into a fully playable state so I can get in the habit of finishing projects rather than bouncing from idea to idea.
Since the original intent was to keep at the equipment creator, naturally I worked on something else.
This week I got caught up with refactoring some of the damage dealing objects in the system. So, I have two different types of actor damage dealing objects, one that I refer to melee and ones that are projectile based. Each can set additional modifiers per weapon, so say an Axe can have a base physical attack of 25 or can add some elemental damage to it. In addition, it can also scale based on the actor's attack value or current element attack value, so you can do something like base 5 fire + 10% of caster's fire attack.
Additionally, all of these damage dealing objects can also apply SoT (Status over Time) effects. I confusingly named them SoT's because they can act as both a damage and heal over time, it basically just modifies resources. Later on, the plan is to include states, such as freeze or whatever.
Also, since I was re-looking at the damage dealers (since I was re-examining the combat since, since I was re-examining damage dealing objects, since I was re-examining equipment creation...), I also refactored the system that handles the combat interactions, or what I call the combat formulas.
Combat formulas is an abstract class now that contains the basic interactions during combat (ProjectileDamage, ElementDamage, Melee, etc.) which can be overwritten so people can simply add their own formulas into an inherited class. There's player and enemy combat formulas, which includes basic get information for the combat interactions, such as GetTotalAttackDamage or GetReducedPhysical or GetElementResist. Again, these can be overwritten so people can do their own formula shenanigans. It's also completely over-engineered, so it can be overwritten per damage dealing object if one so desires. Perhaps you want some boss to have different damage calculations than a normal mob (why? who knows!).
This also then had the knock on effect of creating an Actor Damage Database, so we can easily reference and create existing or new types through the game database (yay). Additionally, you can save off the data in a text file and I'm also starting to add export/import text to the databases themselves.
You get something like this for the actual Data Object and Text:
and then something like this for the actual database
Yes, super exciting.
So I'll leave it with this video with me demo'ing guns and a flamethrower, using the multis and the sots. Of course this just demonstrates my underwhelming flying text system, but one thing at a time.
I'm finding my best ideas come when I'm unable to sleep and my brain just starts throwing out ideas all over the place, and I just have to stay up and write them down until I'm satisfied. I'm maintaining a google doc to remember upcoming tasks and I got a lot of good ideas just now I think. Hopefully they'll still sound good to me in the light of day.
I've made rather poor progress on my game, because I took a week off to be low-grade depressed (no worries, just low affect), and then I took a week off to make a Triple Triad-esque mini-game to put into my main game.
It's a distraction, but I was happy with my card-facing MonoBehaviour. Since I'm doing this with UI canvases, there's no 3d model to flip around when I turn cards. I saw some solutions online, but they seemed to have extra ideas that weren't necessary, like making an extra transform to sit above the surface of the card to give you a normal by doing extraTransform - card.transform.
So I made a card front node and card back node and selectively disable one or the other depending on the result of `bool IsFaceTowardsCamera => Vector3.Dot(cardFace.transform.forward, Camera.main.transform.forward) > 0;`
Something that might be neat here is to tween the scale up and down over the course of the flip to simulate a card being flipped on a flat surface instead of rotating in space.
I made an enemy/obstacle/thing that follows a wall.
I think I managed to fix all the major issues it had, but it still has some minor ones.
If it's away from a wall it turns every frame. It makes sense, but it doesn't look good.
It can go out of bounds. I'll fix this by making the area outside the room be considered solid tiles.
I need to be able to set in the level editor which wall it is attached to and whether to go clockwise or counter-clockwise, but I don't have any UI for that yet.
I've made rather poor progress on my game, because I took a week off to be low-grade depressed (no worries, just low affect), and then I took a week off to make a Triple Triad-esque mini-game to put into my main game.
It's a distraction, but I was happy with my card-facing MonoBehaviour. Since I'm doing this with UI canvases, there's no 3d model to flip around when I turn cards. I saw some solutions online, but they seemed to have extra ideas that weren't necessary, like making an extra transform to sit above the surface of the card to give you a normal by doing extraTransform - card.transform.
So I made a card front node and card back node and selectively disable one or the other depending on the result of `bool IsFaceTowardsCamera => Vector3.Dot(cardFace.transform.forward, Camera.main.transform.forward) > 0;`
Something that might be neat here is to tween the scale up and down over the course of the flip to simulate a card being flipped on a flat surface instead of rotating in space.
Ooh, good suggestion. My plan was to tween them from a hand area to a play area, but this gives me the idea to add a little vertical rise and fall to simulate moving in an arc.
Spent the last month getting all the non-sexy supporting work done for a new game. Menu system, config options, save system, and world map are all working now.
I've got the fundamentals of the combat engine in place as well, even though the video doesn't show it. Stage rendering, camera controls, and cursor moment are all in working order, so now it's on to the real heavy lifting: scenario implementation, actual combat engine, and asset generation.
Is this a reasonable place for posts such as "hi I'm teaching myself unity" and "what the hell am I doing?"
Definitely share what you're working on / struggling with! That's half the fun, and it can be a good way to motivate yourself.
For sure heh. It's hard to overstate just how "begining to learn" this is though.
Like I've done the Lego microgame tutorial and the first module in the unity learn community thing they have going on.
Basically my achievement so far is that I made a ball roll down a janky track by telling it to obey gravity onto a safe platform and applied some asset store textures to the various crudeobjects.
I have a design background and a lot of experience in 2d graphic editors so mostly I'm picking up the interface pretty quickly. The hardest part is getting used to panning in 3D instead of 2D.
I think the next module is an intro to scripting. I imagine now things will start to get weird
So, it's been a bit since I've done any real gamedev stuff on my own accord, but I did just walk a handful of 4th-graders (my Webelos!) through a couple-week tutorial in Scratch (scratch.mit.edu), where we created a Space Invaders-ish game (we used bugs and balls to squish 'em; we're doing our part!).
Up through last week, everyone had basically been following along and implementing the same stuff. Their "homework" for last night's meeting was to add a mechanic of their own to the game. My own tweak was to reduce the rate of fire of the "gun" and add a 3-shot powerup after you successfully got 5 bugs.
My guys, variously, did:
A full suite of sound effects
A new type of bug that took more hits to squish
A second player
A couple others just didn't have time to do the homework, so we'll see what they come up with next week.
Super proud of them! Plus it was fun teaching them programming basics.
Pretty much all I wanted to do with my spare time this week was play Sekiro. On Thursday, so as not to have absolutely nothing to report, I did some preliminary work trying to find a way to abstract away the work my architecture does with content objects such that, for example, if I wanted to pack up and move from MonoGame to Unity for some reason (like, MonoGame doesn't wind up supported on Nintendo Console N+1), I could use all of the content files that I created specifically for use by my architecture without significant translation effort. However, I'm (well) aware that I'm subconsciously avoiding the road made of nails, hot coals, and broken glass that leads to my actual goal (training up in the arts) and sticking to the comfy road of pillows and chocolate (continued programming side projects) that goes nowhere.
But, unfortunately, between trying to find a house in an overheated market on a short time-frame while simultaneously trying not to lose my job, I don't have a lot of psychic energy to throw at creativity. As ever, though, I'll try to have at least one thing to bring to the thread, even if it's a failure. See you then.
My favorite musical instrument is the air-raid siren.
I know that if I start working on some cook game mechanic or programming trick I'll get lost down the rabbit hole for a long time. So I've been forcing myself to work on finishing up what I already have and ruthlessly cutting features that I was thinking about.
So this week I just finished up the giant caterpillar appearances. Some fiddling with the shader materials and hair distribution gives a good variety of wyrms. I made hair mohawks and moustaches because why not? This is a giant caterpillar so I've already thrown most of the the rules out the window. I could spend more time on it but this is good enough. Next I'm revisiting the structure of the puzzle levels.
This weekend was mostly UI work and some code cleanup, spent a while trying to brainstorm ways to add more progression complexity to the game. I think I have some good ideas but there's a lot left to do. I set up a Trello to organize my thoughts you can peek at if you want.
Added a mana potion that shares a cooldown with your health potion to create a meaningful choice between offense/defense oriented play.
Implemented working weapon/armor stats and stat screen.
Added a new crystals currency, with a chance to gain one for a given element each time you defeat an enemy with that element.
Added a Spellbook panel where you spend crystals for spells and magic-related permanent upgrades.
Redesigned the Shop with a more spacious list format since the grid was too empty looking.
Removed the inventory as it no longer makes sense in the roguelite structure, only permanent unlocks are acquired between runs. I haven't completely ruled out an offline gathering system but it would take a different form if I re-implement it, and I have a lot of higher priority items.
Added automation research for drinking potions automatically.
Late night report, but here we are at week's end yet again.
For the ARPG system, I got a helper window for creating "Wearables", most importantly melee and projectile weapons.
In the video here, I open the window and then show the various options (arrow, bullet, flame, axe, etc). These can be added by adding to the databases. It sets up whatever gameobject to be the weapon and also asks for a projectile if you are doing one of those weapons, and sets it up accordingly. Here I choose some character as the projectile with mixed results, it shoots but it plays the animation since I quickly chose an object with an animator. Oh well, it's working and I'm not able to check for every component that could possibly exist on someone's gameobject.
Other than that, I spent too much time figuring out how to port many of the foundations of my ARPG system to Unity's ECS. I've got a working inventory, modifier, equipment, items, attribute, and leveling. There's no video to that because it's all data, quite boring. The last issue I wanted to resolve before I started to pretty things up was entity instancing. Fundamentally it works the same way as the main ARPG asset I've been updating, everything has a template and then you instantiate that at runtime. Same system applies here, you load the templates and then grab instances from the various handlers.
I'll probably give a better update on that next week, as it's late and I have an early morning. Until next week!
Posts
This week was not a lot better for attention, discipline, and emotional stability, so it's another "one token step forward" week. I implemented (with unit tests) the "create from format" function on my CharBuffer String-replacement class.
The plan for this week is to break ground on the actual text-rendering component that displays strings, along with any associated content file types.
I've been thinking about doing a 2D Zelda imitation for ages, but never gotten very far with it.
My immediate todo list:
After that comes pretty much everything to do with actually playing levels. I've got basic movement and definitions for which tiles are solid, but not much else.
I managed to compile 4.26 by checking out a fresh copy of the source code. It took about a day to compile from scratch. Then I figured I should try the new Chaos physics so I had to toggle on a flag and recompile from scratch AGAIN, which took another day.
The reason I switched to 4.26 was to see if Runtime Virtual Textures worked better, and they do. But for other reasons they are impractical so I'll just get by with normal grass. I did some more arranging of geometry and shaders for grass. The tricky part is balancing the lighting on the grass vs. non-grass. It's hard to make everything look good without the grass blowing out to white, but I'm getting there.
Alright, this week was focused on the ARPG system. I did some refactoring for convenience, which is meh to me. Probably why I felt like I did a lot, but accomplished very little.
So now, a new user can one-click create new databases for their own game, and, if they so choose, copy over the data from the demo. This was much needed but tedious and boring, hours of work resulting into a button click. Exciting.
For more exciting stuff, I refactored the UI elements so things are more streamlined there. Someone suggested to have a drag-ability-into-ability-slot feature, which is reasonable but wasn't originally on the plan since I think many other assets do UI much better. In any case, I got it accomplished as shown from the video.
I also am working on creating some demo models to include with the package, because the default skeleton is meh. I'll eventually include a couple of demo characters, each a different class and maybe some enemies.
This week, I'm trying to write up a new description for the asset store page. I already wrote a "Quick Guide" for getting started, and once I get a new description that more accurately reflects everything the asset offers, I'll send the updates up. I was hoping to do that yesterday, but I didn't make the deadline so I'm going to use that as an excuse to write up some stuff and then make the new deadline for this weekend.
What I need for this new deadline:
I'm glad you're continuing with it!
Yeah, the issues with root motion that you mention here are why I don't use it if I can avoid it. I probably would feel different if I was an animator and could make great animations.
If you're working with forces, sounds like b) is the better bet.
I dislike root motion as implemented, but I love whenever I can move things like that out of code and into the editor. For example, the exact timing on a lunge or stumble is much easier to create and to review in the Animation window than in code.
I'm not working with forces, but there's a lot of pushing and pulling with attacks that has to come out just right to create consistent combos. I can probably deal with it by just doing the right math on the pivot, but I figure I should give it some consideration before I change how everything works
These are the segments of giant caterpillar built as some rigid bodies controlled via physics. They are just sitting on the landscape, not moving but not asleep. In Chaos, simulating this takes 80ms so I get about 12fps max. In a non-chaos build the simulation is sub-millisecond. I'm not sure what causes this but I don't need exploding buildings THAT badly at the moment. Maybe this stuff will be improved in 4.27 or the "chaos" development branch, I dunno.
Printing text with sprites is hard, who could have guessed?
Got more work done this week than the previous two, but I still don't have anything to demo yet.
As a minor task, I added a parameter to the [ContentPathAttribute] I made to mark string-type object members as being a file path instead of an all-purpose string. When the object editor sees a member with the [ContentPath] attribute, it gives you a ComboBox (text box with selectable options below) populated with all the file paths it can find in the content directory. Well, sometimes that file path should always point to a texture file, so it makes no sense for the editor to give you sound effects as an option. The new parameter lets you set a file extension so the editor will only offer you the right file types.
Other than that, I've made progress on the text renderer. It's capable of placing plain old sprites at a target position right now, but I still have to implement the text justification and anchor positions. I also need to create an editor for the Font object type that controls how characters in strings map to subsets of the texture file. So, all told, the feature is still half-implemented and basically untestable for now. Oh well!
Assuming I keep my head pointed in the right direction, I should have something presentable by next week. See you then!
I still couldn't shake the feeling that something wasn't adding up about the game's premise though. You could just run headfirst into a dungeon again and again on autoplay until you get the gear/levels to overpower it - even for an idle game there's not much depth there. Then I started to think it might be more interesting as a roguelite of sorts, where you quickly level your classes and acquire gear per-run, making decisions along the way on how to specialize. Gold persists between runs and is used to unlock classes, permanent upgrades, add new loot to the pool, etc. I felt like the idle offline gathering stuff was too extraneous, with concerns about being able to trivialize the content by idling for too long, so I cut it for now. Implemented the basic shop this weekend and got the core gameplay loop mostly worked out.
I made the update and got the demo updated with the new stuff here:
https://ventedpennies.itch.io/arpg-item-and-stat-system
That's the bare demo, boring but shows what's possible in the different rooms. I'm working on a 'stadium' scene, just one room where you can spawn dudes, collect rewards, buy stuff, and save and load. Almost like a game...
Anyways, I've decided on a few things.
One, I'm going to send updates more frequently to the store. This provides a benefit that people see that it's constantly being updated (even if it's just a line of code...), but also it'll help me track down problems if anyone has them. Much easier to locate a conflict with incremental changes, instead of landslides.
Two, now that things are at an okay place, I'm going to expose some of the editor features to the game itself. Mainly, equipment, class, and ability creation. You can already create these things in the editor, but they are made in a way so that people can also make their own at runtime.
So here's my first attempts at bringing that into the game. Imagine beautiful art.
It's pretty raw, but the general idea is there. People can add native traits, random traits, set the item level, customize prefix and suffixes, and also customize a few more things later on. The idea here is you can make it, then add it to your inventory.
Of course I fully expect people to make overpowered equipment, but one step at a time. Basically I just want to showcase the limitless possibilities, and adding custom trait types will require new code but it's pretty hand-holdy since you inherit a base class and it errors the project until you complete the required methods. But after that it'll be added as an option to these system.
Three, the last major addition will be importing/exporting basic database information to json (e.g. item name, health amount, cost, etc). This, hopefully, allows people to text edit basic values without opening Unity. It won't include all the data for each thing because, well, some of it just doesn't make sense to text edit (for instance, the leveling curves). But with this last major addition, I can start displaying more of the features (much like equipment creation above). Also, I'm interested how this will port over to unity's ECS, it should be work pretty well with the hybrid system and turning objects into entities since much of the systems are written like datacomponents.
Also, my 6 weeks since the last sale is almost up, which means I'll be increasing the price to $80 from its current $40. Of course I have many free keys if anyone wants to be a tester!
For next week, continue working on this equipment creator. Let's just focus on that for now.
I've got item pickups, locked doors that take a key to open and treasure chests.
Some silly things happen if I put treasure chests in treasure chests
It's a distraction, but I was happy with my card-facing MonoBehaviour. Since I'm doing this with UI canvases, there's no 3d model to flip around when I turn cards. I saw some solutions online, but they seemed to have extra ideas that weren't necessary, like making an extra transform to sit above the surface of the card to give you a normal by doing extraTransform - card.transform.
So I made a card front node and card back node and selectively disable one or the other depending on the result of `bool IsFaceTowardsCamera => Vector3.Dot(cardFace.transform.forward, Camera.main.transform.forward) > 0;`
Thank you! I'm still at the stage of getting mouse dragging to work properly (I'm more of a gamepad person, but I just *know* somebody is going to want to use a mouse on this). My goal is for each game will take under 5 minutes and just be a little alternate play mode to break up the main game.
Transcript:
Hey, you're not going to believe this, but I actually got some stuff done this week. If doing the same parlor trick you did in Unity like three years ago counts as "getting something done".
I mentioned last week that the text renderer can place plain old sprites at the appropriate locations. To explain a little further: MonoGame has a built-in string rendering function, but I wanted to go a little further than what it offers-- rendering text as individual sprites allows me to easily reveal them one-by-one in classic pixel-game style. As sprites, they can also be tinted, made to shake, rotated, scaled, and so on. (You thought that would be self-demonstrating, didn't you? Yeah, I haven't gotten that far yet...) But it turns out that there's all kinds of tricky little nuances there, such as accounting for non-renderable characters, word-wrapping at boundary positions, defining where exactly you start rendering and how the text should be centered, and so on. There are a few lines I haven't managed to code-coverage my way onto yet, but most of it's been hit by test cases now.
... and I'd be remiss if I didn't mention the fact that I encountered a number of hilarious bugs while assembling this demo, such as characters at the bottom of the second page appearing before ones at the top, text dropping past the bottom of the boundary area, word-wrap failing on the very last word of the text box and splitting across the pages, and the "bip" sound turning into a swarm of hellbees when you play it every frame.
Naturally, since a "font" is a new object type for my engine, I had to create an editor to edit them. And while I was trying to pick out the individual letters, I realized that my sprite picker is real hard to use when you're trying to click on things that are one pixel wide. So, I wound up giving it a zoom function, which took an evening or two to finish. Then it was just a matter of putting the time in to put together this little demo.
Speaking of putting the time in, I'm really actually very much out of coding projects that don't involve producing real gameplay. So my next task is to get past the "ugh gate" and actually do some drawing and music composition in the coming weeks. I suspect the results will be disastrous, but you have to start somewhere. Whatever the outcome, though, you can count on the weekly report. See you then!
The movement is pretty reliable but sometimes still gets stuck on bumps, which I can fix by making the wheels slightly bigger. Also, adding a slight wobble can help push it over ledges and other things it can get caught on.
Dude! you're totally kerning! Well, not really I guess but having variation in character width is already impressive to me.
No graphics, just a terminal, and your job is to be, as Ned from Spider-man put's it, "The guy in the Chair", where you direct the hero where to go, watch his status as he beats up bad guys, and recall him when things get too hot. Get beat up too much, he's out a few days. Research down three skill trees. Bio, Cybernetics, and Toys. This results in late game mutant powers, cyborg powers, or... Batman with power armor(?) -- (Getting new way to travel to the crime scene is definitely under "toys")
I tossed around ideas with what city I should use, and I was too lazy to make one myself using ASCII art. However, I just came across the SimCIty 2000 file spec and I'm in love! You can upload any city, and it has everything will all there. Sewers for bad guys, subways, crime areas, police, hospitals.... and it all fits on a 40x40 grid.
So tonight I started with the terminal framework. I'm using C and my tool of choice is Msys GCC. I want to stay as cross platform as possible so the frameworks I'm using are ncurses for the terminal, and Allegro 5 for the low level game functions like filesystems and audio.
As I'm starting with Windows, I'm shimming in an API to make the console window management as generic as possible, however I found that you have a rather large command of the windows console window, such as changing the font type and size, disabling the scroll buffer, turning on and off the minimize/maximize buttons, turning on and off the ability to resize the window, and maximizing for full screen. Here I thought it was a dumb fire-and-forget window.
Game uses 80x25 text but that is subject to change depending on what I can fit on the screen. I hope to one day port it to the Commander X16
- Class levels are replaced with just a singular character level.
- Weapons are now character-wide rather than needing one weapon type per class.
Which I think makes the game somewhat more coherent, plus I think spell effects are more satisfying than little pixel sword swipes etc. Still can't guarantee how far I'll take this project but I feel like I'm making forward progress even when I delete stuff.After that refactoring and code cleanup I added a few more features:
I'm feeling myself start to run out of steam a bit and thinking about new ideas, but I'm trying to push myself to at least get it into a fully playable state so I can get in the habit of finishing projects rather than bouncing from idea to idea.
Alright, another week flown right by.
Since the original intent was to keep at the equipment creator, naturally I worked on something else.
This week I got caught up with refactoring some of the damage dealing objects in the system. So, I have two different types of actor damage dealing objects, one that I refer to melee and ones that are projectile based. Each can set additional modifiers per weapon, so say an Axe can have a base physical attack of 25 or can add some elemental damage to it. In addition, it can also scale based on the actor's attack value or current element attack value, so you can do something like base 5 fire + 10% of caster's fire attack.
Additionally, all of these damage dealing objects can also apply SoT (Status over Time) effects. I confusingly named them SoT's because they can act as both a damage and heal over time, it basically just modifies resources. Later on, the plan is to include states, such as freeze or whatever.
Also, since I was re-looking at the damage dealers (since I was re-examining the combat since, since I was re-examining damage dealing objects, since I was re-examining equipment creation...), I also refactored the system that handles the combat interactions, or what I call the combat formulas.
Combat formulas is an abstract class now that contains the basic interactions during combat (ProjectileDamage, ElementDamage, Melee, etc.) which can be overwritten so people can simply add their own formulas into an inherited class. There's player and enemy combat formulas, which includes basic get information for the combat interactions, such as GetTotalAttackDamage or GetReducedPhysical or GetElementResist. Again, these can be overwritten so people can do their own formula shenanigans. It's also completely over-engineered, so it can be overwritten per damage dealing object if one so desires. Perhaps you want some boss to have different damage calculations than a normal mob (why? who knows!).
This also then had the knock on effect of creating an Actor Damage Database, so we can easily reference and create existing or new types through the game database (yay). Additionally, you can save off the data in a text file and I'm also starting to add export/import text to the databases themselves.
You get something like this for the actual Data Object and Text:
and then something like this for the actual database
Yes, super exciting.
So I'll leave it with this video with me demo'ing guns and a flamethrower, using the multis and the sots. Of course this just demonstrates my underwhelming flying text system, but one thing at a time.
Okay, so next week. Well, I said it was the equipment creator so maybe next week.
Something that might be neat here is to tween the scale up and down over the course of the flip to simulate a card being flipped on a flat surface instead of rotating in space.
Yes absolutely the right place.
I think I managed to fix all the major issues it had, but it still has some minor ones.
If it's away from a wall it turns every frame. It makes sense, but it doesn't look good.
It can go out of bounds. I'll fix this by making the area outside the room be considered solid tiles.
I need to be able to set in the level editor which wall it is attached to and whether to go clockwise or counter-clockwise, but I don't have any UI for that yet.
Ooh, good suggestion. My plan was to tween them from a hand area to a play area, but this gives me the idea to add a little vertical rise and fall to simulate moving in an arc.
Definitely share what you're working on / struggling with! That's half the fun, and it can be a good way to motivate yourself.
I've got the fundamentals of the combat engine in place as well, even though the video doesn't show it. Stage rendering, camera controls, and cursor moment are all in working order, so now it's on to the real heavy lifting: scenario implementation, actual combat engine, and asset generation.
For sure heh. It's hard to overstate just how "begining to learn" this is though.
Like I've done the Lego microgame tutorial and the first module in the unity learn community thing they have going on.
Basically my achievement so far is that I made a ball roll down a janky track by telling it to obey gravity onto a safe platform and applied some asset store textures to the various crudeobjects.
I have a design background and a lot of experience in 2d graphic editors so mostly I'm picking up the interface pretty quickly. The hardest part is getting used to panning in 3D instead of 2D.
I think the next module is an intro to scripting. I imagine now things will start to get weird
Up through last week, everyone had basically been following along and implementing the same stuff. Their "homework" for last night's meeting was to add a mechanic of their own to the game. My own tweak was to reduce the rate of fire of the "gun" and add a 3-shot powerup after you successfully got 5 bugs.
My guys, variously, did:
A couple others just didn't have time to do the homework, so we'll see what they come up with next week.
Super proud of them! Plus it was fun teaching them programming basics.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
Pretty much all I wanted to do with my spare time this week was play Sekiro. On Thursday, so as not to have absolutely nothing to report, I did some preliminary work trying to find a way to abstract away the work my architecture does with content objects such that, for example, if I wanted to pack up and move from MonoGame to Unity for some reason (like, MonoGame doesn't wind up supported on Nintendo Console N+1), I could use all of the content files that I created specifically for use by my architecture without significant translation effort. However, I'm (well) aware that I'm subconsciously avoiding the road made of nails, hot coals, and broken glass that leads to my actual goal (training up in the arts) and sticking to the comfy road of pillows and chocolate (continued programming side projects) that goes nowhere.
But, unfortunately, between trying to find a house in an overheated market on a short time-frame while simultaneously trying not to lose my job, I don't have a lot of psychic energy to throw at creativity. As ever, though, I'll try to have at least one thing to bring to the thread, even if it's a failure. See you then.
I know that if I start working on some cook game mechanic or programming trick I'll get lost down the rabbit hole for a long time. So I've been forcing myself to work on finishing up what I already have and ruthlessly cutting features that I was thinking about.
So this week I just finished up the giant caterpillar appearances. Some fiddling with the shader materials and hair distribution gives a good variety of wyrms. I made hair mohawks and moustaches because why not? This is a giant caterpillar so I've already thrown most of the the rules out the window. I could spend more time on it but this is good enough. Next I'm revisiting the structure of the puzzle levels.
For the ARPG system, I got a helper window for creating "Wearables", most importantly melee and projectile weapons.
In the video here, I open the window and then show the various options (arrow, bullet, flame, axe, etc). These can be added by adding to the databases. It sets up whatever gameobject to be the weapon and also asks for a projectile if you are doing one of those weapons, and sets it up accordingly. Here I choose some character as the projectile with mixed results, it shoots but it plays the animation since I quickly chose an object with an animator. Oh well, it's working and I'm not able to check for every component that could possibly exist on someone's gameobject.
Other than that, I spent too much time figuring out how to port many of the foundations of my ARPG system to Unity's ECS. I've got a working inventory, modifier, equipment, items, attribute, and leveling. There's no video to that because it's all data, quite boring. The last issue I wanted to resolve before I started to pretty things up was entity instancing. Fundamentally it works the same way as the main ARPG asset I've been updating, everything has a template and then you instantiate that at runtime. Same system applies here, you load the templates and then grab instances from the various handlers.
I'll probably give a better update on that next week, as it's late and I have an early morning. Until next week!