Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Jun 2004
Offline Last Active Yesterday, 06:11 PM

Posts I've Made

In Topic: Low Poly vs. High Poly

31 January 2016 - 10:18 AM

I'm not sure, but that "smooth" thing in Maya sounds about right.  If it is, then what I said probably applies to it.


LODs are level of detail.  Basically when a model(let's say a tree, since speedtree does exactly this too) is close up, you see it in high poly glory(let's say 10,000).  Then at some distance, you see a lower poly version of it(5,000), and further yet, the tree only has maybe 1,500 polys.  Finally, in the distance, it may get converted to a single billboard tree(works well for things that aren't really animated).


Generally if your game will do this, then you may create a super high poly version first in ZBrush.  Then create a "normal" version, which you use the ZBrush version to bake normals onto.  Then you can lower the polys either directly or using a tool in order to get the lower poly versions.


The issue we currently have is just that you are going the other direction, which is not as common from what I have seen.

In Topic: Structuring a Simple 2D Engine

30 January 2016 - 12:34 PM

One thing about game engines, as mentioned above, is how some code ends up being the game, while other code is in the game engine.  But at some point, the better game engines have code that would be better in specific games, but can be used in some games, so becomes a feature.  These are things like path-finding, AI, and any number of similar ilk of features.


Once you are past the basics, the things that pretty much every game will have, you would then move on to making features like I describe above.  Sometimes, this comes on because you know of a certain feature, or because you try making a game with it, and then after coding that game, extract that code, and make it work in a general sense with your engine.  Either way can work, though if you do it the second way, making a game, then I recommend you remember the eventual goal of the engine, and therefore should remember to write things in somewhat general ways when possible.  It will make things take a bit longer, but will be quicker at the point of integrating the thing into your actual engine.


So, you have two paths you can generally follow, though you can go back and forth no problems.  You start making some simple games, and then you start extracting game code from them so you can then put the features into your game.  Or you can make a feature list of things you know games have that would work in your engine.  This list would include things like navigation, AI, particle systems, lighting systems, maybe custom shaders, you know, all those things that make games great.  Then you can simply make some test cases in order to make sure your engine features are working in a good general way, and that you can use/not use the features as you wish for any given game, and ensure that nothing interferes with other systems in the engine, regardless of which all features are actually in use at the moment.  Everything should work in concert with each everything else, in any usage combination, under any given circumstances.  That last part is generally the hardest part of making generic game engines, much more than any single given feature.

In Topic: Low Poly vs. High Poly

30 January 2016 - 11:04 AM

In some cases, you can get away with simply adding something like Blender's Subsurf modifier.  It adds smooth geometry and you can control just how much of it.  You can also then apply it and then modify it as you need to.  Note that this is similar to what would happen if you put it into ZBrush as suggested.  Also, Max and Maya have their versions(TurboSmooth in Max I think) so it should work wherever you go.


Just note that the results will also depend on how the original model is, and just how "low-poly" it is, including just where the the geometry is on the model, as these modifiers use a form of subdivision, so if the geo on the original isn't even, it won't be on the subdivided one either without some extra work.

In Topic: keep same visible are among all resolutions

21 January 2016 - 11:27 AM

Not Unity specific, but the best way to do this is to scale up until one axis hits the edge, and cover the rest with black bars(or whatever).  It can be a general system, which would work both landscape and portrait, though would obviously work better one or the other unless you have a perfect square size.  The method of scaling depends on the engine(in your case Unity) but the concept in general applies to all engines.

In Topic: GameMaker Studio, need help coding knockback

05 January 2016 - 12:13 AM

I use GMStudio, and I have to say the opinion of SirWeeble isn't the same as mine.  But I DO agree that it may be better to visit the GMC(GameMaker Forum) as they know gml coding better than here.


As far as to your problem, I would have to see the code you have as it is to know exactly what I think the best way to get it done would be.  Generally you probably want to calculate what direction the enemy needs to move, maybe based on where the player is, and if you want to have some randomness added to it.  Then set a quick velocity on the enemy in that direction.  Also, set an alarm for a small number in order to have it stop that velocity at that point.


I'm known as kburkhart84(same as here) over on the GMC forums.  I recommend you post a topic over there if you haven't, and you can PM me over there as well if you would like, though the best way for me to help is to see the code on your enemies.