• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2474 Excellent

About Satharis

  • Rank
    Advanced Member

Personal Information

  • Interests
  1. Is Unity or Unreal fit my needs? Veterans only

    Most "realistic" looking games are 80% world building 20% graphics. Unreal has very nice visuals but without lots of carefully placed lighting, lots of meshes(including many small detail ones) and other visual effects, it doesn't look real at all. I'm sorta skeptical you'll make it look that great without significant investment in art, but I suppose you could try. Frankly I'm not sure what planet you come from either where you think untextured objects will ever look "realistic." You obviously can do whatever you want, your life and all, but I can't say I understand what your goal is. People are not going to want to pay for and play a game that is just pretty but has no gameplay. If you were trying to make a showpiece to get a full time job then your idea of a project is ridiculously overambitious and more likely to showcase the engine than your coding ability.
  2. Is Unity or Unreal fit my needs? Veterans only

    Where I live that would barely cover two programmers of low to moderate experience for a year, forget "professional." Making games is crazy expensive if you aren't doing it as a hobby or as slave labor, especially with how costs of everything seem to just be going up. That said that whole we need to raise prices on games because they are so expensive to make is just publisher nonsense, GTA 5 cost less than 300 million to make and made about 2 billion in its first week of sales.
  3. Is Unity or Unreal fit my needs? Veterans only

    Unreal is C++ not C#, if you can even use C# to any real degree in it I couldn't tell you since I've only ever see C++ used with it. Blueprints are certainly not a replacement for code, they're okay for logic and things and have the benefit of being easy to add and remove due to not needing to go through the horrendous process of adding C++ files. They fail horribly when math is involved, since literally every operator is usually a blueprint node. Blueprints nodes copy between things, between different projects is a little different and would require you to migrate the entire blueprint object generally and then copy and paste parts out of it that you want. The texture streaming system on ue4 has options for customization, you can probably fine tune the way it works, or you know, modify it in the engine code. UE4 is nice but like any thing of scale it has a lot of stuff in it you may never use, it also is tuned for very specific types of games, a serious RTS for example would find much to hate in Unreal with the way ticking and the AI behavior trees are set up, they definitely favor more complex characters you would find in an FPS and the entire architecture with game modes and each level being its own world are definitely symptoms of the UT focus. Other options exist but it is quite obvious they were added later on to try and accommodate different game types and thus often feature rather obtuse behavior or restrictions on design, the level streaming in UE4 can be a bit weird to work with, as an example. Couldn't tell you as much about Unity since I've only used it briefly but frankly given your responses about UE4 I think you need to go investigate more and actually try them both rather than reading and creating these misconceived notions.
  4. C# Wizards and Warrors

    Not only is it not necessary but it's flat out a bogus requirement. How exactly do you catch something at compile time that in most complex cases, would be loaded from a file at run time? You shouldn't know every item that you're ever going to try to equip in a game at compile time in order to stop it, that's a ridiculous sentiment.
  5. VR naked development

    I'm not sure i'd say it has a huge community base just because people are developing software that works with it, in terms of pure VR games or adapting existing games to feature VR it often isn't at all an increase in profit in much the same way that linux compatibility often isn't. That would be more liable to change if it wasn't 400-600 bucks for the equipment, which might happen some years from now.
  6. Gameplay Attack Speed and Delay

    I would think the warrior's next time to attack would belong to the warrior, yes. I would also not use absolute time since that makes things like time dilation and pausing annoying at best.
  7. C# Wizards and Warrors

    Technically in that case you would be correct, it would stop you from passing in anything but a staff, but that's a bit of a weird way to do it, and like I said the caveat is that you have to know that it needs to be a -staff- ahead of time, essentially hardcoding it. The set function is just that though, a function, so you could basically replicate the behavior an "equip" function would have in it. But that might be a bit confusing to a user. My other point was casting it to staff was kinda superfluous. If it passes the if statement you can just set weapon = value; and it would work the same. The if statement is a gate essentially.
  8. C# Wizards and Warrors

    That effectively wouldn't do anything, casting is just changing how you interpret the type of a thing, and you're basically casting it to a staff and then setting a weapon reference to it, meaning if you try to access it through weapon you'll get a reference to a weapon back. If you wanted to access the -staff- part of weapon then you would just set the private weapon to the incoming staff, then cast it to a staff later when you need to cast it. If effect that private Weapon is only ever going to act like a weapon, even if its pointing to a subclass of weapon like a Sword. Keyword Is would be using type identification to figure out it is a sword, which you could do, but has some caveats and I'm not sure about performance. In a language like C++ you'd usually provide some kind of identifier to know how to cast something to a subclass, like an enum you set. I'm not entirely sure how that would help with the problem presented in the thread so far either. You could technically reject certain weapon types in the set function for weapon like that, but, you'd then need to know the types ahead of time, and you would probably be better served making something like an Equip function that does it instead. In the context of this thread I would suspect you'd get more than a few people saying that Staff and Sword do not necessarily even need to be a subclass of a weapon.
  9. C# Wizards and Warrors

    Having a separate class just to hold functions that verify whether something can happen seems kind of overkill. Usually the rule when designing things is to figure out who needs to know about the rules. How you want to do this depends a lot on the style you want to follow. Is a wizard a player or is a player just a player and has an archetype class that happens to be wizard? Somewhere you need to define which weapons are okay to equip and which are not. That's the one part you can't get around, the program can't know without you defining it somewhere. But there are literally a million ways to do that, some are more simple and some are more complex but offer greater flexibility. I usually opt for the minimalist approach unless I have a good reason not to. The inventory could handle that, it might let you add items and equip them and then it has a reference to the player that owns it, then it can grab the player's archetype class and see if the weapon is something it can equip. The player class could also do that by looking itself if it didn't have a separate inventory class, or it could simply have a list of weapon types it can equip and you can populate that by using a factory method to create a player with the properties of a wizard or a warrior. Literally dozens of ways to accomplish the same thing. In terms of the comparison there isn't really getting around using an enum or something similar. Either the weapon or the thing adding the weapon needs to know if it can be added/equipped, and the only way to do that is to compare it to something known ahead of time and determine if it is true or false. Your options are rather limited in that area, if you don't compare against a weapon type then you'll have to compare against the item i'd or if it implements an interface or something else. These all equate to identifying what the thing is.
  10. Sort of the big-bad-wolf of programming there, particularly in games you'll often find scenarios where you have a lot of similar things where one or more have to be slightly different than the others. If you need energy for one item then your only real options are to place it in the superclass, or make it a child class and access it that way. That property has to go -somewhere- after all.
  11. Bad Design vs. Niche Design

    This whole topic sorta seems like a philosophical nightmare. One could argue in circles if bad art is still art and worthy of recognition but people will still sneer in disgust if someone draws a stick figure cat on a piece of notebook paper and hangs it on the wall and calls themselves an artist(generally.) It's sort of hard to articulate a real answer because you could make a wide range of criteria for what makes a "good" game. A lot of people complain about the Call of Duty series for example(ignoring the fact many of the games are quite different from each other) and yet they obviously were made by large teams of skilled developers, so does that make them good? Does a lot of sales make them good? They seem to be reviled often and yet sell a ton of copies. What makes a game like Subnautica good? I think the only real basic tenant that you could argue with for a game being good design or not is that it needs to have had some love put into it, there's a lot of games out there that are obviously lazy, rushed, don't seem to do their own prescribed goal very well, etc. On that note I'd probably point out that you can't really treat design as a thing in and of itself, ideas are only as good as the implementation they end up in. It takes a well made game to demonstrate a good design, not just an idea.
  12. Interestingly his code would actually work(well, once.. sans key repeat) if not for the fact he isn't comparing the type of the event he polled with the desired keydown state. Instead he's asking for the keystate from SFML. Obviously asking for the state will always return at least one button as being down if either one is, thus stopping the if/else chain, whereas if it was actually compared to the event then the spacebar event would show up uniquely. The whole thing is a series of unfortunate events combining to make it not work at all.
  13. Game Engine Decisions

    Even with Unreal that tends to come up pretty constantly in my experience. People on forums and boards can often answer simple questions but when it comes to complex behavior or things that are in a project that has been worked on for longer than a day, the answers seem to drop off quickly or not be very useful. I had a colleague quip that it was probably because all of the people with actual experience were likely busy applying it somewhere rather than discussing it on forums. He sort of has a point. Answers here fall into the other category usually, quite a few people here have experience with big projects but often can't take the time to, or don't know, the complexities and issues of one particular platform or engine. In general it seems like game development is often a very do-it-yourself kind of learning experience, that's why experience is so valuable, you accidentally learn solutions to problems you have without even knowing that was what you were looking for.
  14. Modern OpenGL GLSL Camera

    In addition to the more detailed explanation of what a camera is, it can be helpful to think of a camera as just a logical representation of where you are looking in a scene. Although a "camera" doesn't actually exist in game engines, it is pretty common to create a class for one and have rendering functions accept a camera as a logical viewpoint for the rendering. In unreal and such you'll see the camera also contains settings about how the scene should be rendered, specifically any properties that are endemic to the camera itself. This has the advantage of making it easy to create different logical cameras and both manipulate them and swap the viewpoint easily. More generally: The model matrix is the position of the model in world space, as opposed to its local space. The view matrix is essentially the viewing position of the camera. The projection matrix is how the camera augments the view, you can think of it like using a different lens in a real camera, usually this is orthographic or perspective, but it also contains properties about the viewing space such as the aspect ratio and the clipping plane.
  15. Was it a mistake to develop my own engine?

    My personal biggest headache about modern engines is that they are just insanely gigantic and maze-like to work with. Though I suppose that would be true of any sizeable engine, but you can tell that many hundreds if not thousands of people have layered workaround on top of workaround into a lot of the code. My main experience with UE4 has been spending dozens of hours tracing through code, googling or reading documentation to try and figure out where something I want to change is even defined in the engine code and what methods I have to get at it or override it. Even dealing with blueprint there is a lot of situations you run into where it's something to the tune of "Oh there isn't a node for that, but there is a C++ function buried somewhere that will let you do that! Connect them!" Convenience seems to be a double-edged sword in many cases, it's quick and easy to do many otherwise hard or time consuming things in the engine due to the robust tools and deep systems set up already for you, but it makes learning it and changing things that don't just work for you right away at the top level a heck of a job. It's hard to say whether you would have been more productive, personally, I think making an engine yourself of decent design and depth sounds like a great learning experience if nothing else.
  • Advertisement