Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

22 Neutral

About gaxio

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There are a number of reasons why buildings (at least historically) must be placed on grids. The game uses a tilemap. This makes everything very fast to render because you don't have a huge list of objects with positions, graphics to display, etc. All you have is a grid and on each grid which graphic needs to be displayed. It makes things very simple and saves on quite a lot of memory, at least for machines in the 90's and before. The game logic is easier that way. In order to place a building in Age of Empires, it must be on an empty space and have land under it, or a dock must be half on the water, etc. Checking for building placement becomes a lot easier if it's done on the tilemap. It didn't have to be, but I think we practically every RTS game of the era all the developers just decided it was easier that way. In Age of Empires or Factorio, this basically makes walls and conveyor belts possible. If you could place wall or belt segments independent of the grid, it would be a nightmare to build. Imagine building from 2 directions and having them not meet up in the middle. Imagine a unit sneaking through because your wall was a tiny bit too far from a building. It would massively complicate the game for no good reason so, again, just place them all on the grid.
  2. Welding is something that's done inside your 3d modelling application, but once it's in the 3d engine it's just a list of verts. All welding does is make verts in the UV space stick together to make it easier to work with. Once it's rendered everything is disconnected, faces aren't even connected anymore let alone UV stuff. As for why exactly that's happening, I'm not exactly sure. All that's doing is making sure the UV coodinates for the fragment are clamped to 0..1. However, as was pointed out, that's what the texture sampler parameters like clamp and wrap already do, so there's no need for it.
  3. The third bold part is known at compile time. The compiler will make a table of virtual functions to offsets in the vtable so it knows which function pointer in the vtable to look up.
  4. Godot has explicit support for this with the GDNative API.
  5. Godot is written in C++, open source and similar to Unity.
  6. What does the texture look like? Is there any margin or padding on the texture? Texture maps are usually dilated as much as possible (though in reality a few pixels is all that's needed, but the more dilation the better for lower resolution mip map versions) to prevent these types of seams.
  7. Bloom as a fragment shader will only work for fragments that are actually rasterized. If the mesh being rendered is cut off right around the sprite then none of those pixels are rasterized so they never make it to the fragment shader. It's hard to tell what's going on in your screenshot, but it looks like that's part of it. One thing I've done is just apply bloom in the GIMP and use a separate sprite. If I only need bloom on a few things it's often easier to have a glowing variant of that sprite than try to have a shader do the work. Edit: Also, 18 dependent texture samples per fragment might be a bit expensive.
  8. Amen to that. This is one of the areas where C# shines, since it doesn't just store compiled code in assemblies (DLLs and EXEs and stuff) but also extensive meta-information about the classes and methods then it makes code completion almost trivial. All the editor has to know is what you're trying to complete, look it up in the assembly and you're done. Plus there are things like OmniSharp that abstract this, so almost any editor can have good, reliable code completion. VS Code has never let me down in this respect, thought ironically completion in MonoDevelop has broken on me many times over the years due to it being a buggy mess. That's hardly C#'s fault though. But it really changes how you code. When coding without code completion I'll have a vocabulary of API functions that I almost never stray from. If I have a problem I can't solve, I'll go look up another function and try to add it to my vocabulary. But often I'll find out later that there are API functions that do things I've been doing on my own, but that I could have discovered through code completion easily. Often times I won't know which function I really need so I just browse through the completion list and see if anything looks appropriate. It seems like such a tiny thing, but it's a pretty big deal.
  9. If you're trying to show a concise example of Unity then you're not doing a very good job of it. A few things in your code are needlessly verbose. [SerializeField] float speed = 100f; void Move(float x, float y) { transform.position += new Vector3(x, y, 0) * speed * Time.deltaTime; } void Update() { Move(Input.GetAxis("Horizontal"), Input.GetAxis("Vertical")); } That's it. There are no tricks or crazy syntax here. And you're really all over the place with your naming (MoveObject has a redundant word in it, TempVec is a terrible name), the code is not DRY, it's incorrect and/or overly verbose ("this" is redundant, and position is a property, not a method).
  10. I just don't know why you're focusing on these irrelevant and completely arbitrary things like install size and code length. It's like going car shopping and focusing on the floor mats and tire irons. I don't know why you're focusing on these two things and honestly I don't think you know why either. As for the actual code length, it's as long as it needs to be. If you want even shorter code, look at engines like GameMaker and Construct, which have default character controllers you can drag onto objects. That's 0 lines of code, but as soon as you need that controller to do something a bit different you're back to the same problems every other engine her: gathering either 4 buttons or 2 axes of input and moving the character with that. Every game engine will provide an API to do this and it's just a matter of using that API to do what you need. Whether one API has longer function names (Input.is_action_pressed("up") vs key("up"), for example) is utterly irrelevant. It's a bit of typing, that's it. If that's really what's making you choose one engine over another, I just don't know what to say.
  11. gaxio

    Brick materials for unity

    Does the mesh have UVs?
  12. And? That's a simple action, if you're judging how easy it is to script an engine based on how short the program is... I don't even know what to say. That's a completely arbitrary thing to judge an engine on and a very odd thing for a "veteran programmer" to say. The entire movement in script in Godot looks something like this. extends KinematicBody2D const SPEED = 200 func _physics_process(delta): var velocity = Vector2( float(Input.is_action_pressed("right")) - float(Input.is_action_pressed("left")), float(Input.is_action_pressed("down")) - float(Input.is_action_pressed("up")) ) move_and_slide(velocity.normalized() * SPEED) That's it. It's flexible, succinct and it honestly shouldn't get much "easier" than that. If you're afraid of typing a few lines of code... I don't know what to say. Keep switching engines to find the shortest, I guess, but like I said before that's a completely arbitrary thing to be judging an engine on. In terms of ease of use balanced with expandability and popularity (which sounds unimportant, but unless you're self-sufficient then you need people to help you solve problems) you're not going to find many (or any, really) better options than Unity or Godot. Pick one and start learning it. And stop expecting it to conform to your irrational expectations, no software will and unless you learn to adapt to different languages, libraries and paradigms than you'll constantly have a bad time with game development. It is what it is, stop expecting it to be something else and stop trying to make it into something else.
  13. I'm not quite sure what you mean, could you give an example of this? All these engines are going to involve working with an API and stringing API functions together. None of it is as boiled down and simplified as something as Blitz3D, but on the other hand it's all a lot more flexible than Blitz3D. The objective of engines like Unity and Godot is not to make it dead simple, it's to make it easy to do easy tasks and possible to do any task. This necessitates a more general API. This is a bad idea. Learn the environment you're working in and use its API, don't try to hide that API behind a self-made abstraction layer that will only confuse things when it goes wrong. The Unity and Godot APIs are not difficult or overly-verbose anyway, you should not be having a problem with this.
  14. This is your problem, not Godot's. I don't want to sound mean but if you're having trouble with Godot's scripting language then you aren't going to have a fun time with any engine. Bite the bullet and learn how to program or you will never make any progress. Godot's scripting language is not difficult, it's one of the easiest things I can think of to work in and switching engines to look for an easier one is going to be an exercise in frustration. Even C# in Unity is easy, C# is a very nice language to work in and I know plenty of people who have gone from 0 programming knowledge to developing games in Unity with C#. Learning to program sucks. It sucks for everyone when they're first starting. They get frustrated and nothing seems to make any sense, but it just takes time for your mind to work through this stuff. Keep trying, keep working at it every day. Every day you'll learn something new, lights will come on in your brain and eventually you'll get over the frustration hump and things will start to make sense to you. Switching engines won't get you over the frustration hump, you just have to grit your teeth and get to work. Now honestly I'd stick with Unity if you're just starting out. The amount of information about Unity on the web is shocking, you can google more or less any problem you're having and the Unity forums are huge and very active. The install size really shouldn't be an issue, it's 2018 and storage is cheap. If you want to move to another engine later then that's another issue, but if you're just learning then I think Unity is the place to be. That said, Godot looks quite nice too. The community I'm sure is growing as well, it wouldn't be a terrible choice.
  15. I think method #2 is usually what you want. When using a pure ECS, systems are usually iterating over collections of components and being able to iterate over those components in contiguous memory is what will be most efficient. The other iteration scenarios such as iterating over all entities that have a set of components are best solved using views. A view is a cached list of entities that have those components and should hopefully have them in an order that ensures the most cache hits. However, not everyone likes a pure ECS approach. The first one of these systems I made was emulating the "entities with components" paradigm I was using in Unity. There, you don't have systems and components hold all the code. It's great for putting things together in a much more ad-hoc way and you have certain steps (or events, really) where the entire hierarchy is iterated and certain methods like Update are called. In this case, you probably want #1. In an engine I did in C, I actually used #1 but taken to the Nth degree: all entities have memory for all components and a flag to determine which component the entity really has. It wastes memory, but for a small game, who cares? It'll make more cache misses since the stride of your iterations is going to be large, but again, for small games who cares? I even had a fixed limit on the number of entities possible in the system, the entire ECS was a single malloc and could be disposed with a single free, the code using it only ever saw a void* and a set of functions to operate on it. My point in bringing this up is that sometimes beating on a problem like a gorilla and following the path of least resistance is fine. It breaks all the rules but it was a small game on a modern computer, it's fine. Most people who sit down to make an engine really overthink things (but I suppose that's the point of an engine, I guess) when literally any solution will be just fine. Because this solution I did in C was admittedly dumb and inflexible, but it ended up being just fine.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!