So you guys may remember that I posted a while ago about my game, Wyld Hunters, and my concerns about it. After spending 8 months on it, our development had slowed down and I was feeling discouraged. The game didn't feel fun and it didn't feel like it was going anywhere. After I posted that, I went and had a very productive talk with the rest of my team. They had also been feeling a bit down and like the game was never going to be released so we agreed to do feature freeze and focus on getting the game ready for beta as soon as possible.
It took a while since we're all working on other jobs full-time but we finally got our game into beta and the hands of our beta users. We've had ~40 installs so far and I've actually been pleasantly surprised by their feedback. I've been working so long on the game that the flaws were immediately obvious to me while the appeal of the interesting sections dulled after a while. The beta users are very understanding and saw the potensial in the game which inspired me to put more effort into it.
Here's a screenshot of the game:
If anyone is interested, I'd love feedback. It's still rough and full of bugs but we're working on fixing them as fast as we can. If you have an iOS device and send me your email address, I can add you via testflight and you can check out the game. It's been an experience getting a game from concept to beta and I think I learned a lot both as a game designer and as a programmer.
Well, I finished the quick and dirty prototype version of my "Make a game" project.
I definitely think with some tweaks it could be fun. Also with making it in Unity so I can do stuff a little better, instead of just relying on primitive 2d shapes and images. I mean, I'll still have to make some art, but at least the tools will be there.
It's... uh, well, I feel pretty good for doing it in 2 weeks with another big project also that I've been doing in the 2 weeks. And doing it with Processing, the worst thing for making games. To the point where you have to make the idea of buttons, and shit like that.
If I ever get 2 seconds where I'm not working on other stuff, I definitely think it could be a fun little thing.
It needs to be a little faster getting to when you have more dice, since it's really boring just having one die, but hey.
Never made a full proper inventory system before. Now I have! I've added basic CRUD support for push/pulling items on the backend and the UI is all gamepad support. Learning is fun but I def want to use SQlite for the card system for more advanced organization management. No need to reinvent the wheel.
I am all the way on board! Not everything is built in, but with the extra code in their tech demos, this goes even further than something like Super Tilemap.
I've got Unity 2017.1.0p4, but it's not updating to 2017.2, which I thought was out of beta. Does it not auto-update to new minor versions anymore?
The gist of it is that 2017.2 is a major version, not a minor version. The first number is the year of release, the second number is the major release order within the year, and then anything that follows is minor version nonsense.
My favorite musical instrument is the air-raid siren.
I've got Unity 2017.1.0p4, but it's not updating to 2017.2, which I thought was out of beta. Does it not auto-update to new minor versions anymore?
The gist of it is that 2017.2 is a major version, not a minor version. The first number is the year of release, the second number is the major release order within the year, and then anything that follows is minor version nonsense.
Fully working equipment/inventory/loot system! I've gotta shitty JS frontend for the database to easily add/remove/change things and I only query once on game load to test file integrity and then each time you 'open' core menu.
I've never done one of these before so planning it and doing it right without pulling my hair out was a test of patience but it went pretty smooth with only one area of frustration when I typoed something and couldn't see it. XD
My passion remains AWOL, so lately I've resorted to a toy project to try to keep on some kind of pace. I have made no progress on RPS RPG, but I've built what is now my third proc-gen dungeon builder.
The concept here is to produce a dungeon that, rather than the fully tile-based style that you might see in Rogue or Dragon Warrior, has something more like the tidy sprawl of connected rooms that you see in Darkest Dungeon. I was also inspired by tabletop games like Betrayal At House On The Hill, where players draw rooms from a stack of room cards and must arrange them such that the doorways connect to the existing map and leave doorways available for further expansion of the map.
The core loop of the dungeon builder is that you give it a total number of rooms you want the dungeon contain, and then repeatedly call the dungeon's "Place Room" function to drop a new room into it. Each time the dungeon drops a new room in, it does so at one of the doorways connected to an existing room, and then decides which other potential doorways to leave open. Naturally, there's code to handle special cases like the first room (which obviously couldn't connect to any existing doors, as it's the first room), generating rooms without any new doors toward the end (because you don't want the dungeon to be created with doors to nowhere), and handling cases where the dungeon paints itself into a corner (dropping a room using the last available door into a spot surrounded by existing rooms so it can't reasonably generate doors that would support new rooms; in this case the next call to place a room will create a new door at random on the perimeter of the dungeon).
Here's a screenshot of the dungeon builder in progress:
And here's the same dungeon after it's done building:
After completing the layout, the dungeon marks a room as the goal, selected at random from those rooms at the maximum distance from the start in terms of the number of doors you have to cross.
I felt like continuing with this concept a little further, so I decided I wanted to support a fixture of the dungeon crawl: the locked door whose key you have to go find in order to proceed. But, it makes no sense to have a locked door that you can walk around, so you have to know which doors can actually be used to block access to other parts of the dungeon. I recognized this problem of identifying doors that could bisect the dungeon if they were locked is a well-explored problem in computer science; I also managed to stop myself from spending hours implementing the clever solution, because my dungeons aren't graphs of more than 100 nodes anyway. It was sufficient to iterate over every door and test if a depth-first search could reach every room in the dungeon if crossing that particular door were forbidden.
However, choosing which doors to lock that way turned out to be problematic. Note that every room at the end of a corridor is necessarily behind a door that could bisect the dungeon if it were locked; it would create two subdungeons, one of size 1 and one of size N-1, where N is the number of rooms in the dungeon. Just picking the doors to lock at random from each one that could bisect the dungeon led to dungeons where a locked door blocked access to a single room that would contain the key to unlock the next single room with a key in it to unlock the next single room with a key in it, and so on. I hacked at this for a while and eventually managed to come up with a system that preferred to pick the doors that would create the largest subdungeons, but even that didn't produce entirely acceptable results:
(Locked doors are indicated by red connector lines.)
This is a particularly well-formed example, and it still has a subregion of just seven rooms, or that area connected to the start zone which is more or less one straight corridor. In my testing, I found that sometimes the dungeon generator just couldn't find anything better than a bunch of subdungeons that were three or four rooms long, with the start and the goal in the same area. So, after hacking at it for a few hours, I stood up, walked away from my desk, slapped my forehead, ran back and implemented something that directly solved the problem.
The flaw in my reasoning was starting from a randomly-produced dungeon and trying to find desirable features in it, rather than designing the dungeon builder to produce the desirable features in the first place. I wanted subdungeons of uniform size connected by doors which block off access to the rest of the dungeon until you find the appropriate key. The solution is simple: I already had a method to magic a door onto the perimeter of the existing rooms (the third special case I described), so I could generate a subdungeon with a particular number of rooms, then create a door into empty space on any arbitrary existing room that leads into the next subdungeon. This lets you easily identify where you can place the key (it has to be in a room with lower subdungeon index than the subdungeon it unlocks) and generates a random tree of subdungeon connections (note that in the picture below, area 1 is the parent of areas 2 and 3 both).
Here's the result of the revised generator, with the subdungeon indexes printed on each room:
The placement of the goal tile had to be revised such that it is only selected from rooms within the highest subdungeon index.
The only other thing I'll point out is that I had to create a new special case handler. Imagine if, for instance, there were a fourth key, and the dungeon generator decided to start its subdungeon off by placing the first room of that subdungeon just below the start room. The subdungeon isn't done, but it has no room to expand; every possible space is already filled by a room. The previous fallback behavior was to add a door to a random spot on the perimeter of the dungeon, but subdungeon rooms absolutely must be connected with one another. In that case, it simply gives up and lets the subdungeon be stunted.
I'm not even going to speculate on what I'll wind up doing next week, on the theory that stating your intentions makes you less likely to actually accomplish them.
My favorite musical instrument is the air-raid siren.
Thanks to lurking in this thread I'm taking another stab at game dev. I grabbed GameMaker in a Humble Bundle a few years back but eventually lost interest after a few tutorials and some attempts at simple games.
This time around I'm trying out Godot. Having reached about the same point as I did with GameMaker I've been on the look out for some longer game jams to help keep me on track with trying out new things. My current jam project will eventually be an LCD clone. I've got most of the systems in place using some temporary sprites.
Thanks to lurking in this thread I'm taking another stab at game dev. I grabbed GameMaker in a Humble Bundle a few years back but eventually lost interest after a few tutorials and some attempts at simple games.
This time around I'm trying out Godot. Having reached about the same point as I did with GameMaker I've been on the look out for some longer game jams to help keep me on track with trying out new things. My current jam project will eventually be an LCD clone. I've got most of the systems in place using some temporary sprites.
I played an awful lot of a TMNT LCD game in the 90s. The thing to know about it is that it was so loud that my parents had to put foam tape on the back in order for me to play it anywhere outside the house. https://www.youtube.com/watch?v=O_rueBDMGdc
Does anyone know of a good way to create a tabular layout in Unity UI?
I'm already using the Grid Layout component, but I'd like something that adapts to its content like an HTML table, rather than me having to manually input sizes in the Grid Layout component.
Does anyone know of a good way to create a tabular layout in Unity UI?
I'm already using the Grid Layout component, but I'd like something that adapts to its content like an HTML table, rather than me having to manually input sizes in the Grid Layout component.
Something like a Content Size Fitter maybe? Not 100% if that'll fit your needs but it's another possible tool.
Does anyone know of a good way to create a tabular layout in Unity UI?
I'm already using the Grid Layout component, but I'd like something that adapts to its content like an HTML table, rather than me having to manually input sizes in the Grid Layout component.
Something like a Content Size Fitter maybe? Not 100% if that'll fit your needs but it's another possible tool.
How does layout work with that? I was under the impression that it was incompatible with the grid layout component.
I re-designed my card system so that plays have 'stage cards' now that they can place which are active for X turns and do all kinds of neat things at various times. I gutted a ton of the simultaneous play and basically reworked 80% of the gameplay rules. 100% better now even still early. Still missing a lot of animation and art but a much better approach than the first time.
There is no enemy turn here, I had to refactor the database for cards so the enemy AI doesn't have a new deck yet. Just me taking one turn after another.
What is your schedule like? I’m envious of the output but I also realize I would need to schedule myself some better GameDev time.
I find it incredibly hard to sit down and work on GameDev stuff after my day job of programming all day.
"Whenever I can" is what I've been doing, my daily responsibilities are pretty hectic so sometimes I get like 3 days and sometimes I can't touch code for a week. It sucks being so spotty.
I'm making some changes at home so I can spend more time on a regular schedule, I would like to get a solid 5-8 hours of gamedev in each day, so we'll see what happens at the beginning of the year.
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
@LaCabra that's awesome. I love reading about performance based design and coding. It's really neat how things are done outside the players view to make the games run better.
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
Can all you hip Unreal people help a turtle out? I think I'm going to make my next game in Unreal to get easy access to all the neat particle effects since there's going to be a ton of freezing, ice, and wintry stuff.
Could anyone point me to a quick tutorial for making an FPS using Blueprints in Unreal?
A basic FPS is easy if you use one of the prebuilt projects. It's easier to just remove the fun and VR stuff than to go through the hassle of creating a FPS from scratch.
When I started on Unreal I just used Epic's inventory tutorial on YouTube which got me up to speed on their basic FPS stuff anyway.
Edit: remove the gun stuff. Damn autocorrect.
DisruptedCapitalist on
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
Aye, just start with the first person shooter template and go from there! There's lots of example projects on the launcher's learn tab that you can pick apart and reverse engineer.
#Unity question
I've been testing my new game on my OP2 (which has known overheating and thus electricity use issues).
It drains the battery while charging. This happens over about say 4 hours of me building, testing, then keeping the game running as I make changes in Unity.
The framerate is set to 30 and the average timing is at 10ms for the scene I'm currently working on. So half of the timing is V-sync...
Now, again, the issue is partly my OnePlus2 that will throttle charging while the screen is on and possibly at other times too, because of the overheating.
But the larger issue is that I wonder if the drain will also be a problem for users.
So. Does anyone have any bright ideas as to how I could reduce battery drain, aside from further GPU tweaking?
Ludum Dare is upon us. The theme is "The more you have, the worse it is."
My project is called "Holiday Parking Panic" and is a kind of parking lot demolition derby setup where you'll have to complete objectives and find the best parking spot while avoiding cars, people, taking damage, etc. All physics based.
I only started developing in Unreal over the summer and of course there's always something new to learn. I decided it was time I figured out how to open doors. I knew it had something to do with Timelines, but I wanted to make sure I was on the right track by checking some tutorials first. Holy shit, they sucked.
First one I found on Unreal's wiki suggested I use Matinee--which I already know is obsolete--and even though it seemed to be on an official Epic website, there was no mention about it being outdated. I don't see how a cinematic would be used for ordinary Actor motions, but since matinee it's before my time, maybe there's something I don't get about it.
The second tutorial in the docs just totally neglected to add critical details, like which actor it was using (e.g. was the door mesh the actor or the whole blueprint?) or what the actual values of the curve they were using.
Eventually, i figured it out on my own but wasted a couple hours trying to decipher why the tutorials made no sense.
@KoopahTroopah since I've been diving into a lot of these tutorials over the past few months, I can probably help you clear up any confusion they might create for you.
DisruptedCapitalist on
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
Timelines are already not how I'd do it and Matinee would be an outright stupid way to do it even if it wasn't obsolete. Blueprint is sort of a double-edged sword in that it empowers people to do things but also to do them wrong and then make tutorials.
Timelines are already not how I'd do it and Matinee would be an outright stupid way to do it even if it wasn't obsolete. Blueprint is sort of a double-edged sword in that it empowers people to do things but also to do them wrong and then make tutorials.
Thank you for improving how I'm going to describe blueprints to people from now on
Timelines are already not how I'd do it and Matinee would be an outright stupid way to do it even if it wasn't obsolete. Blueprint is sort of a double-edged sword in that it empowers people to do things but also to do them wrong and then make tutorials.
So just out of curiosity, how would you do it? Skip Blueprints altogether and use C++?
DisruptedCapitalist on
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
Posts
But that website is useful.
http://www.fallout3nexus.com/downloads/file.php?id=16534
http://www.fallout3nexus.com/downloads/file.php?id=16534
It took a while since we're all working on other jobs full-time but we finally got our game into beta and the hands of our beta users. We've had ~40 installs so far and I've actually been pleasantly surprised by their feedback. I've been working so long on the game that the flaws were immediately obvious to me while the appeal of the interesting sections dulled after a while. The beta users are very understanding and saw the potensial in the game which inspired me to put more effort into it.
Here's a screenshot of the game:
If anyone is interested, I'd love feedback. It's still rough and full of bugs but we're working on fixing them as fast as we can. If you have an iOS device and send me your email address, I can add you via testflight and you can check out the game. It's been an experience getting a game from concept to beta and I think I learned a lot both as a game designer and as a programmer.
Eh, I'll just finish it with another tutorial and have a project "finished"
http://www.fallout3nexus.com/downloads/file.php?id=16534
I definitely think with some tweaks it could be fun. Also with making it in Unity so I can do stuff a little better, instead of just relying on primitive 2d shapes and images. I mean, I'll still have to make some art, but at least the tools will be there.
I quickly threw it up on itch(https://optimalgoat.itch.io/rogue-dice). It's so easy to post to itch..
also I have a little youtube thing
It's... uh, well, I feel pretty good for doing it in 2 weeks with another big project also that I've been doing in the 2 weeks. And doing it with Processing, the worst thing for making games. To the point where you have to make the idea of buttons, and shit like that.
If I ever get 2 seconds where I'm not working on other stuff, I definitely think it could be a fun little thing.
It needs to be a little faster getting to when you have more dice, since it's really boring just having one die, but hey.
I am all the way on board! Not everything is built in, but with the extra code in their tech demos, this goes even further than something like Super Tilemap.
The gist of it is that 2017.2 is a major version, not a minor version. The first number is the year of release, the second number is the major release order within the year, and then anything that follows is minor version nonsense.
Huh, okay!
On the other hand: That's not how semantic versioning works!
I've never done one of these before so planning it and doing it right without pulling my hair out was a test of patience but it went pretty smooth with only one area of frustration when I typoed something and couldn't see it. XD
Edit: Updated to show the full system
My passion remains AWOL, so lately I've resorted to a toy project to try to keep on some kind of pace. I have made no progress on RPS RPG, but I've built what is now my third proc-gen dungeon builder.
The concept here is to produce a dungeon that, rather than the fully tile-based style that you might see in Rogue or Dragon Warrior, has something more like the tidy sprawl of connected rooms that you see in Darkest Dungeon. I was also inspired by tabletop games like Betrayal At House On The Hill, where players draw rooms from a stack of room cards and must arrange them such that the doorways connect to the existing map and leave doorways available for further expansion of the map.
The core loop of the dungeon builder is that you give it a total number of rooms you want the dungeon contain, and then repeatedly call the dungeon's "Place Room" function to drop a new room into it. Each time the dungeon drops a new room in, it does so at one of the doorways connected to an existing room, and then decides which other potential doorways to leave open. Naturally, there's code to handle special cases like the first room (which obviously couldn't connect to any existing doors, as it's the first room), generating rooms without any new doors toward the end (because you don't want the dungeon to be created with doors to nowhere), and handling cases where the dungeon paints itself into a corner (dropping a room using the last available door into a spot surrounded by existing rooms so it can't reasonably generate doors that would support new rooms; in this case the next call to place a room will create a new door at random on the perimeter of the dungeon).
Here's a screenshot of the dungeon builder in progress:
And here's the same dungeon after it's done building:
After completing the layout, the dungeon marks a room as the goal, selected at random from those rooms at the maximum distance from the start in terms of the number of doors you have to cross.
I felt like continuing with this concept a little further, so I decided I wanted to support a fixture of the dungeon crawl: the locked door whose key you have to go find in order to proceed. But, it makes no sense to have a locked door that you can walk around, so you have to know which doors can actually be used to block access to other parts of the dungeon. I recognized this problem of identifying doors that could bisect the dungeon if they were locked is a well-explored problem in computer science; I also managed to stop myself from spending hours implementing the clever solution, because my dungeons aren't graphs of more than 100 nodes anyway. It was sufficient to iterate over every door and test if a depth-first search could reach every room in the dungeon if crossing that particular door were forbidden.
However, choosing which doors to lock that way turned out to be problematic. Note that every room at the end of a corridor is necessarily behind a door that could bisect the dungeon if it were locked; it would create two subdungeons, one of size 1 and one of size N-1, where N is the number of rooms in the dungeon. Just picking the doors to lock at random from each one that could bisect the dungeon led to dungeons where a locked door blocked access to a single room that would contain the key to unlock the next single room with a key in it to unlock the next single room with a key in it, and so on. I hacked at this for a while and eventually managed to come up with a system that preferred to pick the doors that would create the largest subdungeons, but even that didn't produce entirely acceptable results:
(Locked doors are indicated by red connector lines.)
This is a particularly well-formed example, and it still has a subregion of just seven rooms, or that area connected to the start zone which is more or less one straight corridor. In my testing, I found that sometimes the dungeon generator just couldn't find anything better than a bunch of subdungeons that were three or four rooms long, with the start and the goal in the same area. So, after hacking at it for a few hours, I stood up, walked away from my desk, slapped my forehead, ran back and implemented something that directly solved the problem.
The flaw in my reasoning was starting from a randomly-produced dungeon and trying to find desirable features in it, rather than designing the dungeon builder to produce the desirable features in the first place. I wanted subdungeons of uniform size connected by doors which block off access to the rest of the dungeon until you find the appropriate key. The solution is simple: I already had a method to magic a door onto the perimeter of the existing rooms (the third special case I described), so I could generate a subdungeon with a particular number of rooms, then create a door into empty space on any arbitrary existing room that leads into the next subdungeon. This lets you easily identify where you can place the key (it has to be in a room with lower subdungeon index than the subdungeon it unlocks) and generates a random tree of subdungeon connections (note that in the picture below, area 1 is the parent of areas 2 and 3 both).
Here's the result of the revised generator, with the subdungeon indexes printed on each room:
The placement of the goal tile had to be revised such that it is only selected from rooms within the highest subdungeon index.
The only other thing I'll point out is that I had to create a new special case handler. Imagine if, for instance, there were a fourth key, and the dungeon generator decided to start its subdungeon off by placing the first room of that subdungeon just below the start room. The subdungeon isn't done, but it has no room to expand; every possible space is already filled by a room. The previous fallback behavior was to add a door to a random spot on the perimeter of the dungeon, but subdungeon rooms absolutely must be connected with one another. In that case, it simply gives up and lets the subdungeon be stunted.
I'm not even going to speculate on what I'll wind up doing next week, on the theory that stating your intentions makes you less likely to actually accomplish them.
Windows explorer will not reveal this, only glorious text editor sublime will show the light.
http://www.fallout3nexus.com/downloads/file.php?id=16534
This time around I'm trying out Godot. Having reached about the same point as I did with GameMaker I've been on the look out for some longer game jams to help keep me on track with trying out new things. My current jam project will eventually be an LCD clone. I've got most of the systems in place using some temporary sprites.
Super Mario Maker ID: DBB-1RH-JJG
I played an awful lot of a TMNT LCD game in the 90s. The thing to know about it is that it was so loud that my parents had to put foam tape on the back in order for me to play it anywhere outside the house.
I'm already using the Grid Layout component, but I'd like something that adapts to its content like an HTML table, rather than me having to manually input sizes in the Grid Layout component.
Something like a Content Size Fitter maybe? Not 100% if that'll fit your needs but it's another possible tool.
How does layout work with that? I was under the impression that it was incompatible with the grid layout component.
Ludum Dare is a week away! Any of you plan on participating? (http://www.ldjam.com)
I'd love to, man... But full-time dev job plus personal side project plus commuting don't leave any time for gamejams :-/
But speaking of our personal side project, we showed it at Free Play Florida last weekend, and won their best in show award! Fucking woot!
Here's a silly mood piece I made to play on loop at our booth table, so you have something to look at!
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
There is no enemy turn here, I had to refactor the database for cards so the enemy AI doesn't have a new deck yet. Just me taking one turn after another.
What is your schedule like? I’m envious of the output but I also realize I would need to schedule myself some better GameDev time.
I find it incredibly hard to sit down and work on GameDev stuff after my day job of programming all day.
"Whenever I can" is what I've been doing, my daily responsibilities are pretty hectic so sometimes I get like 3 days and sometimes I can't touch code for a week. It sucks being so spotty.
I'm making some changes at home so I can spend more time on a regular schedule, I would like to get a solid 5-8 hours of gamedev in each day, so we'll see what happens at the beginning of the year.
Twitch: KoopahTroopah - Steam: Koopah
Could anyone point me to a quick tutorial for making an FPS using Blueprints in Unreal?
Twitch: KoopahTroopah - Steam: Koopah
When I started on Unreal I just used Epic's inventory tutorial on YouTube which got me up to speed on their basic FPS stuff anyway.
Edit: remove the gun stuff. Damn autocorrect.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
I've been testing my new game on my OP2 (which has known overheating and thus electricity use issues).
It drains the battery while charging. This happens over about say 4 hours of me building, testing, then keeping the game running as I make changes in Unity.
The framerate is set to 30 and the average timing is at 10ms for the scene I'm currently working on. So half of the timing is V-sync...
Now, again, the issue is partly my OnePlus2 that will throttle charging while the screen is on and possibly at other times too, because of the overheating.
But the larger issue is that I wonder if the drain will also be a problem for users.
So. Does anyone have any bright ideas as to how I could reduce battery drain, aside from further GPU tweaking?
My project is called "Holiday Parking Panic" and is a kind of parking lot demolition derby setup where you'll have to complete objectives and find the best parking spot while avoiding cars, people, taking damage, etc. All physics based.
Edit: Updates gif. 13 hours down! Kinda tired!
First one I found on Unreal's wiki suggested I use Matinee--which I already know is obsolete--and even though it seemed to be on an official Epic website, there was no mention about it being outdated. I don't see how a cinematic would be used for ordinary Actor motions, but since matinee it's before my time, maybe there's something I don't get about it.
The second tutorial in the docs just totally neglected to add critical details, like which actor it was using (e.g. was the door mesh the actor or the whole blueprint?) or what the actual values of the curve they were using.
Eventually, i figured it out on my own but wasted a couple hours trying to decipher why the tutorials made no sense.
@KoopahTroopah since I've been diving into a lot of these tutorials over the past few months, I can probably help you clear up any confusion they might create for you.
Thank you for improving how I'm going to describe blueprints to people from now on
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
So just out of curiosity, how would you do it? Skip Blueprints altogether and use C++?