@The Ender I would say cheese is when a certain strategy can only be countered if you specifically prepare for that strategy. An example I can think of would be in Wargame: Air Land Battle, a common cheese strategy is to rush helo's in the opening phase of the match and use them cap the other team's only entry point(where new units are called from). Arguably it's a valid strategy because you can do it within the confines of the rules, but the only way you can reasonably counter it is either do the same thing to them or make yourself weak to all other openers by leaving a lot of defenses behind.
With the Air Land Battle heli rush, you can beat it with a standard loadout. If you scout it out in advance the correct counter is to become extremely aggressive because spending all their points on helicopters makes them very weak defensively. You can be rolling your armour into their base not long after they drop troops in yours. The key conceptual leap is that you don't need to keep your starting entry point to win.
Having said that it still definitely qualifies as if you fail to counter it you lose, but if you succeed the helicopter strategy completely falls apart and they either lose very quickly or the player ragequits before that even happens.
If a strategy crushes beginners, but also puts an opponent in a situation where they are not going to have fun win or lose, that is when it qualifies for me.
This was a pretty crushing idiot math error I just realized I made:
Avery sells sheets of glossy cards at about 20~ dollars per 120 cards. For some reason, I thought it was 20~ dollars per 120 sheets.
Just the basic cards I have ready now require a print run of 800~ cards, or 1600~ cards if a user wants to also print backs. Plus, y'know, an extra sheet here or there for printing fuck-ups.
So, a user would have to buy 13+ packages of cards at 20 bucks a pop... $260. Before the costs of stuff like ink are factored-in. And that's just with the cards i have now, which represent a very small portion of the total eventual card pool.
@The Ender Did you use any specialised software to make those cards? I can imagine wanting to make a card game, is there a tool to help quickly prototype them, or did you have to write an engine to run it, or do a pen and paper prototype?
If there were a tool for prototyping card games, like UE4 or Unity, I'd be very interesting in that.
@The Ender Did you use any specialised software to make those cards? I can imagine wanting to make a card game, is there a tool to help quickly prototype them, or did you have to write an engine to run it, or do a pen and paper prototype?
If there were a tool for prototyping card games, like UE4 or Unity, I'd be very interesting in that.
I just drew them in Illustrator and used a dice chart to simulate some draw mechanics for early playtesting. The best prototyping / testing for any card game, in my opinion, is always going to be just printing them out & playing.
Also: What would people here like to see/be able to buy on the UE4 marketplace? I'm thinking of doing some more things for it, though I have no idea how much money is in that at the moment.
Sometimes I feel like just raw coding makes way more sense to me than Blueprints. I really want to use them well but either I'm too impatient to really learn them or it just doesn't click right with me.
FuriousJodo on
FuriousJodo on Twitch/PSN/XBL/Whatever else
0
Options
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
Sometimes I feel like just raw coding makes way more sense to me than Blueprints. I really want to use them well but either I'm too impatient to really learn them or it just doesn't click right with me.
If you know C++, you're better off coding. You're not constrained by what's been node-ified (for instance, there's no BP equivalent of a dictionary data type yet ) and decently formatted code is honestly easier to read and debug than a complex node diagram.
Blueprint is wonderful for folks who don't know C++, or find a graphical approach easier to understand.
Sometimes I feel like just raw coding makes way more sense to me than Blueprints. I really want to use them well but either I'm too impatient to really learn them or it just doesn't click right with me.
If you know C++, you're better off coding. You're not constrained by what's been node-ified (for instance, there's no BP equivalent of a dictionary data type yet ) and decently formatted code is honestly easier to read and debug than a complex node diagram.
Blueprint is wonderful for folks who don't know C++, or find a graphical approach easier to understand.
Also if you want to play around with the Behaviour Tree in more detail you are going to need to modify the BTT and BT files to gain the control you need.
Especially considering that there's a bug at the moment where behaviour trees don't stop running if you try changing which tree is running. Leading to mulitple trees for one AI. Also switching trees for some unknown reason doesn't attempt to abort the currently executing task in the old tree. I've had to write a couple of functions to get the expected behaviour >.>
Personally I like using C++ to make new BP nodes and doing everything there.
Antinumeric on
In this moment, I am euphoric. Not because of any phony god’s blessing. But because, I am enlightened by my intelligence.
Sometimes I feel like just raw coding makes way more sense to me than Blueprints. I really want to use them well but either I'm too impatient to really learn them or it just doesn't click right with me.
If you know C++, you're better off coding. You're not constrained by what's been node-ified (for instance, there's no BP equivalent of a dictionary data type yet ) and decently formatted code is honestly easier to read and debug than a complex node diagram.
Blueprint is wonderful for folks who don't know C++, or find a graphical approach easier to understand.
Also if you want to play around with the Behaviour Tree in more detail you are going to need to modify the BTT and BT files to gain the control you need.
Especially considering that there's a bug at the moment where behaviour trees don't stop running if you try changing which tree is running. Leading to mulitple trees for one AI. Also switching trees for some unknown reason doesn't attempt to abort the currently executing task in the old tree. I've had to write a couple of functions to get the expected behaviour >.>
Personally I like using C++ to make new BP nodes and doing everything there.
I wish I knew C++, but you can create your own BT tasks and services etc in blueprint too. Haven't run into any limits there yet myself.
Sometimes I feel like just raw coding makes way more sense to me than Blueprints. I really want to use them well but either I'm too impatient to really learn them or it just doesn't click right with me.
If you know C++, you're better off coding. You're not constrained by what's been node-ified (for instance, there's no BP equivalent of a dictionary data type yet ) and decently formatted code is honestly easier to read and debug than a complex node diagram.
Blueprint is wonderful for folks who don't know C++, or find a graphical approach easier to understand.
Also if you want to play around with the Behaviour Tree in more detail you are going to need to modify the BTT and BT files to gain the control you need.
Especially considering that there's a bug at the moment where behaviour trees don't stop running if you try changing which tree is running. Leading to mulitple trees for one AI. Also switching trees for some unknown reason doesn't attempt to abort the currently executing task in the old tree. I've had to write a couple of functions to get the expected behaviour >.>
Personally I like using C++ to make new BP nodes and doing everything there.
I wish I knew C++, but you can create your own BT tasks and services etc in blueprint too. Haven't run into any limits there yet myself.
You can create your own tasks but try stopping a tree from blueprints. Or aborting the current task, or resetting the current tree.
In this moment, I am euphoric. Not because of any phony god’s blessing. But because, I am enlightened by my intelligence.
I'd love to Jam but I'm in the process of buying a house so my wife won't let me take that much time away from the move/purchase.
As for C++, I've done C++ for years but I find adjusting to the Unreal Engine to do C++ their way is where I need to learn a lot. Right now I'm doing like @Antinumeric and creating support classes for my blueprints. Although I did recently change my buoyancy BP to a BuoyancyMovementComponent to make it easier to just make things float. Just add a new component instead of moving a bunch of node into each entity. BP inheritance is still lacking right now.
I'd love to Jam but I'm in the process of buying a house so my wife won't let me take that much time away from the move/purchase.
As for C++, I've done C++ for years but I find adjusting to the Unreal Engine to do C++ their way is where I need to learn a lot. Right now I'm doing like @Antinumeric and creating support classes for my blueprints. Although I did recently change my buoyancy BP to a BuoyancyMovementComponent to make it easier to just make things float. Just add a new component instead of moving a bunch of node into each entity. BP inheritance is still lacking right now.
The fact you can't change inherited components properties at all is incredibly annoying.
In this moment, I am euphoric. Not because of any phony god’s blessing. But because, I am enlightened by my intelligence.
Pay what you want for 4 lessons on game design. 105 lessons/19 hours of content on Unity 3D, 238 lectures/83 hours of content on 3D Studio Max/Art design, 29 lectures/7 hours on gamification, and 25 lectures/5 hours on hand-painted style.
BTA for all four, it's currently at $6.21 (the recommended price is $50 for all four, but yeah).
The one caveat is I think you already need to have personal access to the tools in question.
I'm beginning to poke into audio work and was curious if anyone knows a good resource for learning to make game sound effects. My googling attempts kept returning how to make dirtier dubstep drops and things like that.
I'm excited to announce that I have completed the basic user interface for my space combat game! I now have everything set to start coding ship AI and testing it out in combat.
I'm beginning to poke into audio work and was curious if anyone knows a good resource for learning to make game sound effects. My googling attempts kept returning how to make dirtier dubstep drops and things like that.
Well now you know your sound direction. Google has spoken.
In this moment, I am euphoric. Not because of any phony god’s blessing. But because, I am enlightened by my intelligence.
I'm beginning to poke into audio work and was curious if anyone knows a good resource for learning to make game sound effects. My googling attempts kept returning how to make dirtier dubstep drops and things like that.
I don't know any good resources unfortunately, but watching Warframe's dev streams has led me to believe that you need lots of different fruits and vegetables. I think they break or smash them, record it, and then filter the hell out of it
I recall an interview with the guys who did Space Pirates and Zombies where one of the devs said several effects were created by making "pew pew" sounds into a microphone, followed by filtering and layering of those sounds. It's not gonna work for everything of course.
Today and yesterday I pretty much re-did every blueprint in Spacething so that it would be much much tidier, more legible, easier to build on, and particularly so that it would be easy to save and restore ships. So now you can load up a cooked build, renovate the ship all you want, press F6, quit, go back in later, press F9 and your ship is back like it was. Siiiiiiiiick.
You can also save edits made in play-in-editor, so I can, in the editor, start playing, renovate the ship a bunch, press K, and jump back into editor mode, keeping all the changes I made "in-game". So you can just use it as a quick level design tool thing. Best!
been super unmotivated lately, always feel like playing games more than making them
anyway slogged through making the laser weapon
only the tutorial and weapon test room work right now, laser is in the weapon test room
as far as I can tell stencyl doesn't have raycasting so my laser shoots an invisible bullet at high speed with continuous collision testing turned on
right now the laser penetrates walls but I think I know how to implement it stopping at tiles and still keep the look
the implementation is a rube goldberg device
the rifle actor checks to see if the mouse is down and if so creates a "laser charge" actor which follows the end of the rifle
the laser charge actor fires after the animation is finished creating a laser drawing actor and a laser bullet actor facing the direction of the rifle, the laser is 1000 pixels long but eventually I'll snag the collision coordinates between the laser bullet and the tile and draw the beam between the start and the end coordinates
the laser drawing actor draws the beam that and fades away after 2 seconds
the laser shot actor has a speed of 1000 pixels a second and continuous collision detection killing any enemy in its path
Today and yesterday I pretty much re-did every blueprint in Spacething so that it would be much much tidier, more legible, easier to build on, and particularly so that it would be easy to save and restore ships. So now you can load up a cooked build, renovate the ship all you want, press F6, quit, go back in later, press F9 and your ship is back like it was. Siiiiiiiiick.
You can also save edits made in play-in-editor, so I can, in the editor, start playing, renovate the ship a bunch, press K, and jump back into editor mode, keeping all the changes I made "in-game". So you can just use it as a quick level design tool thing. Best!
I've been inspired by your example and decided to make myself a procedural building generator. I was sitting there looking at 3dsmax thinking: "I am not good enough, patient enough, will need to constantly modify this model and it will take forever and make me move to a different project."
So I figured it would be easier to just make a bunch of walls, internal and external, and have the buildings be automatically generated. I don't have anything to show yet but man this opens up so many possibilities for generating zones and such. I guess Fortnite is also doing that with their player constructable buildings.
The biggest problem I've had with procedurally generating levels is that all the best occlusion culling methods seem to involve baking in lots of data (Umbra and such). This means if your levels are any bigger than quite small and contain lots of stuff, performance is noticeably worse than games with pre baked scenery.
Its something I've been wrestling with in Tomb of Rooms. I've had a few attempts at a home made solution, but nothing that so far has given me any significant performance gain without introducing more problems and I'm not really a wizard at that sort of math heavy stuff. If anyone has any ideas though I'd be very interested.
This is pretty big new. I know C# was a big reason a lot folks were sticking with Unity.
I wouldn't jump ship just yet if lack of C# is what's keeping you from UE4. This is unsupported and requires manual patching, and their about page states that you'll need a commercial license from Xamarin in order to redistribute code written with mono for UE4. Their license for Mac/iOS/Android starts at $0 up to $999 but they don't list a price for Windows(seems you have to email them for a quote), presumably it's the same price but I'd say it's probably worth waiting for official support if you really have to have C#.
0
Options
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
I've been working on a Maya plugin to let animators pose directly off the mesh of a rig, rather than via controls set up during the traditional rigging process. It's heavily inspired by the systems being used at DreamWorks and Pixar. I'm happy to say it's finally working! Here's a little video of it in action (Ignore the distorted sound):
My future plans are to streamline the setup process (as rigs need to be made to work with it) and implement highlighting of the mesh to show what control will be selected before the user clicks. Which means I need to make Maya work with GPUs--oh boy
I've been working on a Maya plugin to let animators pose directly off the mesh of a rig, rather than via controls set up during the traditional rigging process. It's heavily inspired by the systems being used at DreamWorks and Pixar. I'm happy to say it's finally working! Here's a little video of it in action (Ignore the distorted sound):
My future plans are to streamline the setup process (as rigs need to be made to work with it) and implement highlighting of the mesh to show what control will be selected before the user clicks. Which means I need to make Maya work with GPUs--oh boy
Today and yesterday I pretty much re-did every blueprint in Spacething so that it would be much much tidier, more legible, easier to build on, and particularly so that it would be easy to save and restore ships. So now you can load up a cooked build, renovate the ship all you want, press F6, quit, go back in later, press F9 and your ship is back like it was. Siiiiiiiiick.
You can also save edits made in play-in-editor, so I can, in the editor, start playing, renovate the ship a bunch, press K, and jump back into editor mode, keeping all the changes I made "in-game". So you can just use it as a quick level design tool thing. Best!
I've been inspired by your example and decided to make myself a procedural building generator. I was sitting there looking at 3dsmax thinking: "I am not good enough, patient enough, will need to constantly modify this model and it will take forever and make me move to a different project."
So I figured it would be easier to just make a bunch of walls, internal and external, and have the buildings be automatically generated. I don't have anything to show yet but man this opens up so many possibilities for generating zones and such. I guess Fortnite is also doing that with their player constructable buildings.
Awesome to hear it's been some inspiration . I was actually thinking last night about expanding Spacething's system into a procedural building generator including exteriors. It would be pretty easy I think for me to set it up to automatically generate a building something like this with random-ish rooms on the inside, with the option of "renovating" it via a similar interface to Spacething's, and ideally an option to then convert it all into regular actors. It would be a pretty rad thing to put on the marketplace. Whether I do it or not at this point is really a matter of how much time is in my day/what projects I need to prioritise.
The biggest problem I've had with procedurally generating levels is that all the best occlusion culling methods seem to involve baking in lots of data (Umbra and such). This means if your levels are any bigger than quite small and contain lots of stuff, performance is noticeably worse than games with pre baked scenery.
Its something I've been wrestling with in Tomb of Rooms. I've had a few attempts at a home made solution, but nothing that so far has given me any significant performance gain without introducing more problems and I'm not really a wizard at that sort of math heavy stuff. If anyone has any ideas though I'd be very interested.
I haven't looked into how good UE4's real-time occlusion stuff is, but I have done a heck of a lot of optimisation of stuff like this on UE3 some of which applies. They're bringing back the MassiveLOD system in some form, but unless that's been made super dynamic it wouldn't be useful for proc gen stuff.
It's easy to do super simple distant LODs for all your meshes, but I guess most of the perf these days goes on draw calls. I guess one of the things I would do for my procedural building generator would be to use a material on the windows/openings which fades to darkness at a certain distance (so window glass becomes purely reflective and open doors/holes of whatever kind come out opaque black or whatever colour is least noticable), and at that same distance, just stop rendering everything inside the building. This is what Source engine games do with func_areaportalwindow although obviously nothing much in Source is procedural. I could also do stuff like figure out which "sides" of the building ought to be visible from the player's location and cull out entire sides of the building at once (walls in my generator know if they're "north, south, east or west", but that might have issues for buildings much more complex than a big rectangular prism.
+1
Options
David_TA fashion yes-man is no good to me.Copenhagen, DenmarkRegistered Userregular
I really wish art wasn't such a barrier. Not just that stuff doesn't look good, but even just generating the assets is a struggle. Like an entire day to make one really ugly cutscene.
Though after a hard days work, I'm pretty much just one other ugly cutscene away from having a gameplay testable slice of an actual game. Well, that and, y'know, testers.
Long post is long. Spoiled for your convenient scrollpast.
So, a long while back (May of this year), I wrote twoposts detailing my work on an RPG combat engine based on the game of [url=http://en.wikipedia.org/wiki/Nim[/url]Nim[/url]. I figured I'd write up my work on the project just to center my own head and keep some visibility on the project.
For those who don't feel like reading another post as large as this one, the core concept is that all of the events that would normally be randomly generated in RPG combat, such as an attack being a critical hit or missing, are instead put on a timeline that's shared between both the player and the enemy. When a combatant on either side takes its turn, the timeline advances a number of spaces according to the ability used, and the space that the timeline stops on is the one that applies. So, you wind up with situations like your weaker attack doing more damage because the weaker attack is what lands you on a critical hit space, or deliberately choosing a weaker attack because choosing your stronger attack would allow the enemy to land on a critical hit space with its most powerful attack on a subsequent turn. At the time of my last writing, I had a functioning parallelized AI that could evaluate all of its options with alpha-beta tree pruning using some test attacks.
At that point, I had to decide exactly what I wanted to apply this game engine to. Being a writer by talent and a programmer by training, I was tempted to apply one of the grand RPG plots I have in the wings to it. However, after some thought, I discovered that the principle exemplified by this post:
I really wish art wasn't such a barrier. Not just that stuff doesn't look good, but even just generating the assets is a struggle. Like an entire day to make one really ugly cutscene.
Though after a hard days work, I'm pretty much just one other ugly cutscene away from having a gameplay testable slice of an actual game. Well, that and, y'know, testers.
... was going to be a significant issue. I am already embroiled in the development of an open-world roguelike which is going slowly, and I don't want to toss a bunch of irrelevant bullshit onto my workload. So, against my instincts, I've pared down the scope of the project significantly. There will be no overworld, no scripted sequences, no character dialog, not even a shop system. Instead, the flow of the game is going to be a cliff's notes version of an RPG: You select the battle that you want to play from a menu. The menu displays a brief vignette that describes the context of the battle ("The dungeon branched to the left and the right, with no visible clues as to which way we were supposed to be going. We took a vote, unanimously deciding to take the left branch. The left branch turned out to be infested with Hellwolves. We forgot to account for the fact that we are the most unlucky sons of bitches ever to do the wandering hero thing."). After the battle, you're rewarded with a matching vignette describing the outcome ("Turns out Hellwolves are not actually that terrifying.") and either a piece of equipment or a power-up that expands your equipment-wearing capacity. The rewards are fixed, so you can't repeat the same mission for multiple rewards. Some of the missions are required, and some of them are optional.
Since there won't be a fixed party, the player is allowed to create their own from a set of available character classes, akin to Final Fantasy 1. There are ten classes in the game, divided into five paradigms (as in, their approach to winning battles), and then further divided into a physical and a magical version of the paradigm. I was about to list them all, but frankly I don't think it's necessary at this time. You'll all find that out when I publish the game (when, I am reminding myself, when), and this is more focused on the development side of things. So instead I'll note that I came up with eighteen skills for each class, meaning there are 180 skills available to the player. I have coded all but four of these so far, an effort that took remarkably little time thanks to some half-decent code structuring and the general simplicity of the game's rules.
Which leaves me thinking about where I'm going to go with this next. There are several major projects that I can think of. First of all, creating a more usable test bed than the one I've used to do smoke tests on the skills. I have trivially verified that each skill is working and done some more in-depth tests where I thought an interaction between them could go funky, but making the AI do fifteen turns' worth of verification through all possible uses of each skill will probably be more helpful in the long run.
Speaking of the AI, right now it operates on a turn-by-turn basis, which means it spends a lot of time recalculating game state transitions that it already examined before. Since calculating the transition from one game state to another based on which actions get used is the major pain point processing-wise and the game state itself is somewhat thin in terms of memory usage, I could probably squeeze even more performance out of the AI (particularly in the sense of avoiding garbage collections) by caching the game state progression in a persistent structure and only having the AI calculate a game state transition the first time it reaches it. This would also allow me to return to a single thread, which is important because Unity does not support the Task Parallel Library (yet).
Speaking of garbage collection, the code (in C#) is littered with foreaches, iterators, and your classic enterprise-style deleting objects by letting them fall out of scope and get garbage collected. My target environment is Unity, and Unity does not like it when you garbage collect often. Granted, I believe the thing that's going to trigger garbage collection most often is the AI, and people sort of expect to see the game skip a little when the AI is doing heavy work. I'm not going to do an optimization pass for Unity just yet; I plan to see how it actually behaves before I go and try to change my whole coding style across the entire codebase before it's necessary.
Right now the game does not have a good system for communicating its state changes to the UI layer. All of the skills are going to require a second pass to ensure that they emit an event object that can tell the outside world, "Hey, Clongus the Warrior just used his heavy attack on an unsuspecting Hellwolf, and did 7 points of damage."
Once all of the core engine is finished, I'll have to create a UI layer in Unity to present the game to the player. That's probably going to take a whole 'nother design session and trial by fire to figure out, so it's well beyond the scope of this post.
After that, it's the whole wide world of encounter design and content creation. Good times.
My favorite musical instrument is the air-raid siren.
+2
Options
David_TA fashion yes-man is no good to me.Copenhagen, DenmarkRegistered Userregular
the core concept is that all of the events that would normally be randomly generated in RPG combat, such as an attack being a critical hit or missing, are instead put on a timeline that's shared between both the player and the enemy. When a combatant on either side takes its turn, the timeline advances a number of spaces according to the ability used, and the space that the timeline stops on is the one that applies. So, you wind up with situations like your weaker attack doing more damage because the weaker attack is what lands you on a critical hit space, or deliberately choosing a weaker attack because choosing your stronger attack would allow the enemy to land on a critical hit space with its most powerful attack on a subsequent turn.
Just wanted to say, that sounds really cool. Mixing RPG combat with, basically, a board game. Or Mario Party. Really neat idea.
Posts
Having said that it still definitely qualifies as if you fail to counter it you lose, but if you succeed the helicopter strategy completely falls apart and they either lose very quickly or the player ragequits before that even happens.
If a strategy crushes beginners, but also puts an opponent in a situation where they are not going to have fun win or lose, that is when it qualifies for me.
This was a pretty crushing idiot math error I just realized I made:
Avery sells sheets of glossy cards at about 20~ dollars per 120 cards. For some reason, I thought it was 20~ dollars per 120 sheets.
Just the basic cards I have ready now require a print run of 800~ cards, or 1600~ cards if a user wants to also print backs. Plus, y'know, an extra sheet here or there for printing fuck-ups.
So, a user would have to buy 13+ packages of cards at 20 bucks a pop... $260. Before the costs of stuff like ink are factored-in. And that's just with the cards i have now, which represent a very small portion of the total eventual card pool.
i has a very big sad right now.
If there were a tool for prototyping card games, like UE4 or Unity, I'd be very interesting in that.
https://forums.unrealengine.com/showthread.php?49620-OCTOBER-GAME-JAM-Win-Subscription-Time!-Theme-Announced-on-Thursday-s-Twitch-Stream
@GnomeTank and I are going to be forming a team for it, if any other PAers wanna give it a shot, shoot me a PM.
I just drew them in Illustrator and used a dice chart to simulate some draw mechanics for early playtesting. The best prototyping / testing for any card game, in my opinion, is always going to be just printing them out & playing.
If you know C++, you're better off coding. You're not constrained by what's been node-ified (for instance, there's no BP equivalent of a dictionary data type yet
Blueprint is wonderful for folks who don't know C++, or find a graphical approach easier to understand.
Especially considering that there's a bug at the moment where behaviour trees don't stop running if you try changing which tree is running. Leading to mulitple trees for one AI. Also switching trees for some unknown reason doesn't attempt to abort the currently executing task in the old tree. I've had to write a couple of functions to get the expected behaviour >.>
Personally I like using C++ to make new BP nodes and doing everything there.
I wish I knew C++, but you can create your own BT tasks and services etc in blueprint too. Haven't run into any limits there yet myself.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
As for C++, I've done C++ for years but I find adjusting to the Unreal Engine to do C++ their way is where I need to learn a lot. Right now I'm doing like @Antinumeric and creating support classes for my blueprints. Although I did recently change my buoyancy BP to a BuoyancyMovementComponent to make it easier to just make things float. Just add a new component instead of moving a bunch of node into each entity. BP inheritance is still lacking right now.
This should interest some folks around here.
Pay what you want for 4 lessons on game design. 105 lessons/19 hours of content on Unity 3D, 238 lectures/83 hours of content on 3D Studio Max/Art design, 29 lectures/7 hours on gamification, and 25 lectures/5 hours on hand-painted style.
BTA for all four, it's currently at $6.21 (the recommended price is $50 for all four, but yeah).
The one caveat is I think you already need to have personal access to the tools in question.
I don't know any good resources unfortunately, but watching Warframe's dev streams has led me to believe that you need lots of different fruits and vegetables. I think they break or smash them, record it, and then filter the hell out of it
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
So the UE4 Game Jam theme for this weekend is "Bump in the Night"
https://forums.unrealengine.com/showthread.php?49620-OCTOBER-GAME-JAM-Win-Subscription-Time
Like this?
This is pretty big new. I know C# was a big reason a lot folks were sticking with Unity.
You can also save edits made in play-in-editor, so I can, in the editor, start playing, renovate the ship a bunch, press K, and jump back into editor mode, keeping all the changes I made "in-game". So you can just use it as a quick level design tool thing. Best!
anyway slogged through making the laser weapon
only the tutorial and weapon test room work right now, laser is in the weapon test room
as far as I can tell stencyl doesn't have raycasting so my laser shoots an invisible bullet at high speed with continuous collision testing turned on
right now the laser penetrates walls but I think I know how to implement it stopping at tiles and still keep the look
the implementation is a rube goldberg device
the rifle actor checks to see if the mouse is down and if so creates a "laser charge" actor which follows the end of the rifle
the laser charge actor fires after the animation is finished creating a laser drawing actor and a laser bullet actor facing the direction of the rifle, the laser is 1000 pixels long but eventually I'll snag the collision coordinates between the laser bullet and the tile and draw the beam between the start and the end coordinates
the laser drawing actor draws the beam that and fades away after 2 seconds
the laser shot actor has a speed of 1000 pixels a second and continuous collision detection killing any enemy in its path
I've been inspired by your example and decided to make myself a procedural building generator. I was sitting there looking at 3dsmax thinking: "I am not good enough, patient enough, will need to constantly modify this model and it will take forever and make me move to a different project."
So I figured it would be easier to just make a bunch of walls, internal and external, and have the buildings be automatically generated. I don't have anything to show yet but man this opens up so many possibilities for generating zones and such. I guess Fortnite is also doing that with their player constructable buildings.
Its something I've been wrestling with in Tomb of Rooms. I've had a few attempts at a home made solution, but nothing that so far has given me any significant performance gain without introducing more problems and I'm not really a wizard at that sort of math heavy stuff. If anyone has any ideas though I'd be very interested.
I wouldn't jump ship just yet if lack of C# is what's keeping you from UE4. This is unsupported and requires manual patching, and their about page states that you'll need a commercial license from Xamarin in order to redistribute code written with mono for UE4. Their license for Mac/iOS/Android starts at $0 up to $999 but they don't list a price for Windows(seems you have to email them for a quote), presumably it's the same price but I'd say it's probably worth waiting for official support if you really have to have C#.
My future plans are to streamline the setup process (as rigs need to be made to work with it) and implement highlighting of the mesh to show what control will be selected before the user clicks. Which means I need to make Maya work with GPUs--oh boy
sweg
as
fuck
I haven't looked into how good UE4's real-time occlusion stuff is, but I have done a heck of a lot of optimisation of stuff like this on UE3 some of which applies. They're bringing back the MassiveLOD system in some form, but unless that's been made super dynamic it wouldn't be useful for proc gen stuff.
It's easy to do super simple distant LODs for all your meshes, but I guess most of the perf these days goes on draw calls. I guess one of the things I would do for my procedural building generator would be to use a material on the windows/openings which fades to darkness at a certain distance (so window glass becomes purely reflective and open doors/holes of whatever kind come out opaque black or whatever colour is least noticable), and at that same distance, just stop rendering everything inside the building. This is what Source engine games do with func_areaportalwindow although obviously nothing much in Source is procedural. I could also do stuff like figure out which "sides" of the building ought to be visible from the player's location and cull out entire sides of the building at once (walls in my generator know if they're "north, south, east or west", but that might have issues for buildings much more complex than a big rectangular prism.
Though after a hard days work, I'm pretty much just one other ugly cutscene away from having a gameplay testable slice of an actual game. Well, that and, y'know, testers.
For those who don't feel like reading another post as large as this one, the core concept is that all of the events that would normally be randomly generated in RPG combat, such as an attack being a critical hit or missing, are instead put on a timeline that's shared between both the player and the enemy. When a combatant on either side takes its turn, the timeline advances a number of spaces according to the ability used, and the space that the timeline stops on is the one that applies. So, you wind up with situations like your weaker attack doing more damage because the weaker attack is what lands you on a critical hit space, or deliberately choosing a weaker attack because choosing your stronger attack would allow the enemy to land on a critical hit space with its most powerful attack on a subsequent turn. At the time of my last writing, I had a functioning parallelized AI that could evaluate all of its options with alpha-beta tree pruning using some test attacks.
At that point, I had to decide exactly what I wanted to apply this game engine to. Being a writer by talent and a programmer by training, I was tempted to apply one of the grand RPG plots I have in the wings to it. However, after some thought, I discovered that the principle exemplified by this post:
... was going to be a significant issue. I am already embroiled in the development of an open-world roguelike which is going slowly, and I don't want to toss a bunch of irrelevant bullshit onto my workload. So, against my instincts, I've pared down the scope of the project significantly. There will be no overworld, no scripted sequences, no character dialog, not even a shop system. Instead, the flow of the game is going to be a cliff's notes version of an RPG: You select the battle that you want to play from a menu. The menu displays a brief vignette that describes the context of the battle ("The dungeon branched to the left and the right, with no visible clues as to which way we were supposed to be going. We took a vote, unanimously deciding to take the left branch. The left branch turned out to be infested with Hellwolves. We forgot to account for the fact that we are the most unlucky sons of bitches ever to do the wandering hero thing."). After the battle, you're rewarded with a matching vignette describing the outcome ("Turns out Hellwolves are not actually that terrifying.") and either a piece of equipment or a power-up that expands your equipment-wearing capacity. The rewards are fixed, so you can't repeat the same mission for multiple rewards. Some of the missions are required, and some of them are optional.
Since there won't be a fixed party, the player is allowed to create their own from a set of available character classes, akin to Final Fantasy 1. There are ten classes in the game, divided into five paradigms (as in, their approach to winning battles), and then further divided into a physical and a magical version of the paradigm. I was about to list them all, but frankly I don't think it's necessary at this time. You'll all find that out when I publish the game (when, I am reminding myself, when), and this is more focused on the development side of things. So instead I'll note that I came up with eighteen skills for each class, meaning there are 180 skills available to the player. I have coded all but four of these so far, an effort that took remarkably little time thanks to some half-decent code structuring and the general simplicity of the game's rules.
Which leaves me thinking about where I'm going to go with this next. There are several major projects that I can think of. First of all, creating a more usable test bed than the one I've used to do smoke tests on the skills. I have trivially verified that each skill is working and done some more in-depth tests where I thought an interaction between them could go funky, but making the AI do fifteen turns' worth of verification through all possible uses of each skill will probably be more helpful in the long run.
Speaking of the AI, right now it operates on a turn-by-turn basis, which means it spends a lot of time recalculating game state transitions that it already examined before. Since calculating the transition from one game state to another based on which actions get used is the major pain point processing-wise and the game state itself is somewhat thin in terms of memory usage, I could probably squeeze even more performance out of the AI (particularly in the sense of avoiding garbage collections) by caching the game state progression in a persistent structure and only having the AI calculate a game state transition the first time it reaches it. This would also allow me to return to a single thread, which is important because Unity does not support the Task Parallel Library (yet).
Speaking of garbage collection, the code (in C#) is littered with foreaches, iterators, and your classic enterprise-style deleting objects by letting them fall out of scope and get garbage collected. My target environment is Unity, and Unity does not like it when you garbage collect often. Granted, I believe the thing that's going to trigger garbage collection most often is the AI, and people sort of expect to see the game skip a little when the AI is doing heavy work. I'm not going to do an optimization pass for Unity just yet; I plan to see how it actually behaves before I go and try to change my whole coding style across the entire codebase before it's necessary.
Right now the game does not have a good system for communicating its state changes to the UI layer. All of the skills are going to require a second pass to ensure that they emit an event object that can tell the outside world, "Hey, Clongus the Warrior just used his heavy attack on an unsuspecting Hellwolf, and did 7 points of damage."
Once all of the core engine is finished, I'll have to create a UI layer in Unity to present the game to the player. That's probably going to take a whole 'nother design session and trial by fire to figure out, so it's well beyond the scope of this post.
After that, it's the whole wide world of encounter design and content creation. Good times.
Just wanted to say, that sounds really cool. Mixing RPG combat with, basically, a board game. Or Mario Party. Really neat idea.