Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Jun 2004
Offline Last Active Yesterday, 05:57 PM

#5314335 What controller to use while developing PC game

Posted by on 08 October 2016 - 10:05 AM

It really depends the game

Usually, I develop using a wired xbox 360 controller, but I'm just itching to program a game that uses my saitek x52 pro flight system.

It has more buttons and axis inputs than just about any device you'll find on pc, so it's great for edge cases. It even has an lcd display on it :)

Note that controller isn't xinput iirc but DirectInput instead.

There are some really esoteric controllers out there that use their own api. Hope to (insert deity of choice here) you never encounter one in the wild :)


This is exactly why I mention supporting both DInput and XInput.  Yes, XBOX360/ONE are the de facto standard, but they aren't all that is out there.  Everything else pretty much uses DInput still.  Microsoft is from what I see the ONLY entity trying to get rid of DInput as all the manufacturers are still releasing devices for DInput support.  And it also supports my reasoning behind custom input for the player.  You just never know what they have, or what style of controls they like.  The easiest way is to just support it all.  I've never known a player that wants a really strange input scheme(like d-pad on the right for example), but that wasn't willing to set the controls up themselves in the options menu.  You don't have to support directly all the possibly esoteric schemes if you just let them press the indicated button for the indicated action.

#5314286 What controller to use while developing PC game

Posted by on 07 October 2016 - 02:41 PM

The biggest recommendations I have....


Support both DInput and XInput if possible.  I think Unity supports both seamlessly, though I understand that other input systems on the asset store do as well.


Support custom inputs...one of my biggest things about a game is that it lets me choose what button does what, instead of forcing defaults.  This also applies with keyboard, mouse, and joysticks.  I don't really care if the game has different configurations available as default, as long as I can make my own choices.

#5311841 correct modeling for game developement (poly count)

Posted by on 21 September 2016 - 08:40 PM

I think your example about the two villages is a good example.  If the temple you mention is never going to be used anywhere else, even in different form, go ahead and model it, and just place it in your world.  And about the two similar looking but different villages, that is exactly one of the good advantages of using the modular assets.


Poly count, it really depends on your game and your target audience, and how good of computers you expect that target audience to have.  The actual number of polys is nowhere near as important as the shaders that are used on said polys.  A high end deferred pipeline/shader like UE4s or Unity's PBR shaders will be more expensive than one of Unity's older forward rendering shaders, even if you use less polys on the PBR shaders and more on the forward rendered polys.


A good rule and thing to get used to with modelling is to get used to only putting polys where you need it, but don't be stingy either.  If you have a nice flat surface, you don't want to put a ton of polys on it if you can fill it with just a few and have it look the same.  But...you need enough geometry to get the curvature of your model.  And you need extra loops for anywhere geometry deforms during animation, like shoulders, knees, elbows, etc...  There is no perfect way to make things happen, as all aspects of gamedev, even in AAA studios, involve making things "close enough, good enough."  Modern human models can easily range from 3000 polys to 30,000 polys or even more.  Note that the less actual models in your game at any time, the more polys you can make them have(although that doesn't mean you should, especially if your target audience isn't likely to have computers that can handle it).  By the same token, if your game is full of action and hordes of enemies, you are going to have to have less geometry per enemy.

#5311821 correct modeling for game developement (poly count)

Posted by on 21 September 2016 - 04:31 PM

One thing I should mention, about low-poly and high-poly, which comes first is all about preference.  Some people prefer to sculpt out the high poly version, and then do retopo to get the low poly.  Others make the low poly, and then do the subdivision(or whatever method to get the needed geometry) to be able to sculpt the high poly.  Either works.  Another thing to consider, especially if you are working alone, is that you may not need to mess with low/high poly.  Some people make just the low poly version, and then they create textures in something like Substance Painter.  The beauty of Painter is that you paint all the maps of the material at once.  If using the PBR pipeline, this means it paints the Albedo, Metallic, Normal, Rough/Gloss, all at once.  So if you are painting with a material that has heights/normals as part of it, then you are adding the normals right there as part of the process, and without having pre-sculpted them first. You can even directly "sculpt" normal maps in as well simply be painting on that channel alone, though it is best to paint whole materials when possible.


The other thing...some people prefer modular design(making pieces of levels, then putting them together later), while others prefer to model whole levels.  The advantage of making modular pieces is that once they are done, if they are done right, you can make big levels with small pieces, and if you change a piece, it can apply everywhere it was repeated to.  The disadvantage is that you have to make them right so that they fit together, and the fact is that they can get repetitive if there isn't enough variety.  The advantage of modelling it all at once is that you can make the variety automatically as part of the progress.  The disadvantage is that it generally takes longer to make a level in the modelling software, at least, a complete level.  If you have modular pieces, you can move them(export) to the engine as you get them so that the level designer can start right then.  But if you are making whole levels at a time, it isn't so easy to do that all at once.  So basically, there are advantages and disadvantages to both methods.

#5311258 Where could I find game-ready textures I can use in commercial projects?

Posted by on 17 September 2016 - 10:55 PM

If you are using PBR rendering(and less so, but still somewhat if you aren't), GameTextures.com is a good place to find many textures.  It is paid though, but the textures all tile and are quite ready for game use.

#5309440 Game engine advice?

Posted by on 04 September 2016 - 04:23 PM

If you want 3d games, Unity is generally the best choice hands down.  There are times where Unity doesn't fit the project, specialty things like extreme RTS games, or where you need the graphics of Unreal(and even that can be done in Unity if you have the art time).  Unity simply does about everything you need except code the game for you.

#5309249 2D Game Making Softwares For Beginners?

Posted by on 02 September 2016 - 07:23 PM

I would back the suggestion for gamemaker.  It starts easy, but you can move beyond the Drag&Drop into scripting, which then let's you do about anything.  It also ends up quite powerful if you want "hardcore" games later too.  I mean to say that it scales pretty well, making it easy to make simple games, but able to make more complicated (maybe even AAA) games if you are so inclined.

#5309074 Python or GML?

Posted by on 01 September 2016 - 04:54 PM

The reason why you are finding it hard to take a GML course is because GML isn't really a proper programming language. It is a domain specific scripting language for a (effectively consumer) product.

You are much better off learning Python and if (like me) you don't like learning multiple things at once, then make Python take priority! Python will be around 10 years from now, GML won't (or will be very different) so this alone makes it more worth while.

Now, on to Python. Graphics, audio, input, everything is very posible in Python when using a library such as pygame (http://www.pygame.org). Honestly it doesn't really get easier than this so I cannot imagine what GML brings to the table that would ever make it a more viable choice.

That said, it doesn't get much easier than pygame but that doesn't make it easy ;), just keep learning and stick with it and most of all, enjoy it.

Hope this helps :)


I have to disagree on some of your points...


We have no way to know whether Python will be around in 10 years, (though I DO agree it will most likely still be in use).  By the same token, GML will probably have evolved, but I also think it will still be around.


Easier than Python(with PyGame)...GML is.  It seems like you don't know much about GML, or rather GMStudio(GameMaker) itself.  It is a much more inclusive Game Engine, with the GML scripting language for programming game play.  For almost anything, this is easier to use than Python, as you get the engine basically done, and you just add on the game play code.  You don't have to load resources, program a tile engine, code sprite animation, anything like that, as it is already done, and set up with the IDE.


I'm not saying that Python(with PyGame) isn't easy, rather in my opinion GameMaker(with GML) is easier.

#5308769 Python or GML?

Posted by on 30 August 2016 - 09:15 PM

It will probably be easier in GameMaker(with GML), but it isn't all about the language.  You are comparing two very different things.  With GML, you use Gamemaker, and that's it.  Python is more open in the sense that it is a generic language, not tied to a single IDE or piece of software like GML is.  And with GML, you get all that stuff that Gamemaker brings, like resource loading/management.  It is a pretty full-on game engine, tile engine, sprite engine, has sound system, particle system, etc...  python has "access" to all of these things, or you could roll your own, but with GML, it is all part of the package.

#5306065 I need help picking an easy to use modelling program

Posted by on 15 August 2016 - 08:39 PM

Honestly, if you want free, I recommend you keep at figuring Blender out.  It doesn't get better for free, and later, when you want more complex models, you will be grateful to have learned what you did.


I honestly don't know of anything better than Blender for free.  There are some easier programs, but they tend to be lacking, some in important areas.  Some are missing things you want, like any method of animation, and going by what you specified you want, Blender is the only one that does all of it.  It can make the models, animate them, and even "paint skins."  There is nothing else that does all of this for free, though you can find a paid program(or two) that does it.


If you have trouble with Blender, you can always try again, and post on forums, either here, but probably better on dedicated Blender forums, to help overcome the problems.  I'm no expert, but if you want to PM me, I may be able to help as well.

#5305760 I'm considering engine switch after current project is done. Which one sh...

Posted by on 14 August 2016 - 10:28 AM

I'd be curious to know what it is that you are trying to do that you say you "need" to use something else for.  Unless you need to do something specialized, like massive RTS, Unity should be able to handle it, and if the case is that you need something specialized, you are going to have to code your own(maybe on top of something if you are lucky) or find a pre-made engine specific for the game type(good luck unless you have a nice budget).  The only "general usage" engine that I know of that beats Unity is some things is UE4, but you've already stated you aren't interested in using C++.  I can tell you though, many other engines also work with C++, or some other language that you may not know.


But yeah, a better way to get a better recommendation would be to know exactly what you are trying to do that Unity can't handle for you.

#5303905 Theory Behind These Uncharted 4 Bullet Trails

Posted by on 03 August 2016 - 09:31 PM

You could look at ways to render lightning/electricity.  I know it isn't the same, but the principles could apply.  It generally involves calculating a line from A to B, and then perturbing points on said line, creating a chain of segments.  You could do something similar for this random smoke trail, but instead of rendering line segments as brightly colored, you either render lines as cloudy smoky textures(which little by little lose alpha), or make some sort of path particle emitter, or a point emitter than moves really quick along the path.

#5297380 How to make a monitor?

Posted by on 20 June 2016 - 04:45 PM

I will provide a bit more detail, but it is Lactose! said.


1.  Make a new Render Texture in the project folder.

2.  Make a material, probably something either with an emission texture, or for texting purposes use the Unlit/Texture shader.

3.  Drag the Render Texture into the texture of the material.

4.  Make your plane(or if you already have UVmapped geometry) with that material, so you can see the render texture.

5.  Make another camera, pointing wherever you want it to.  Take the AudioListener component off of the camera so you don't get errors.

6.  On that new camera, drag the Render Texture onto the "Target Texture" of the camera.

7.  Profit?!?!


That is all I did, took less than a minute in my project to just add it in really quickly.  It even works and updates in the editor too.

#5297219 Breakout Animation for bricks.

Posted by on 19 June 2016 - 10:24 AM

Instead of adding bricks to the list as they become visible, you could instead keep them all in the list like you have now, and simply have each one have a boolean variable for "visible."  Then in the render call, you would choose whether to actually draw or not based on that variable.  This way, each brick handles whether it draws or not.  This method comes in handy in the future as well, as you get used to each class handling its own affairs.  Technically, you have a bit of overhead calling those Render functions for them not to draw, but I think it is worth the organization purpose, and in this type of game it shouldn't affect anything anyway.

#5295553 C# and Unity for 2D Side Scroller

Posted by on 07 June 2016 - 06:06 PM

Not having to learn a made up ecmascript variant is a start. The d-n-d editor is a joke if you plan to make anything more complicated than a dead-simple platformer. GM is terribad for working in teams as well, whereas Unity has settings that make it play nice with version control. Unity has nice tools for automating animation via state machines, good physics and collision that can be fine-tuned as you desire, and works with external editors so you can code in your own environment. The component-styled UI is powerful, and the way it exposes public script members so they can be edited from the UI - even during debugging - is great. The canvas system is more powerful for making and tweaking in-game menus and HUD elements. Unity supports custom shaders without tomfoolery. Both support a kind of object hierarchy, but Unity's is similar to a scene graph, which ends up being much more convenient.


Unity also has never decided to simply disable previous PAID versions of their software, leaving people stranded and unable to continue their work unless they upgrade to the new version and deal with the massive slew of breaking changes involved in that process.


GM can be used as a tool for people that are code-phobic so that they can overcome that phobia, and it's decent for prototyping, but for serious projects I'm just picturing hours upon hours of opportunity cost.


You make some valid points, but I wouldn't say the word "overwhelming" applies, although if you are doing bigger projects than it does indeed apply more.


About the script variant, it is just another language.  But due to it being "simple" it is actually much quicker to program things in than something like C#, where you have to remember rules like to add "new" keywords at times, among other things.  I've used plenty of both, so I feel I can actually judge here(not saying you haven't).  I totally agree with you about the d&d thing as well, and I've never taken the time to learn how to use it(since I already understood programming and was able to just learn GML right from the start). 


About the team thing...if you have used GMStudio, you will know things have changed in this issue.  Before GMStudio, projects were saved in one lump file, which is of course a big no-no for backups, versioning, etc... but now things are stored separately, and can freely be used with versioning software, etc...  I've even used Dropbox with it successfully, which I can't say about Unity, as I have to turn off Dropbox to not get errors in Unity.


I have no counter about tools that Unity offers for animation(Unity wins in this, the same as UE4 beats Unity on the built in tools side of things).  And I will say Unity's UI system(now that it finally came with 4.6 after much deliberation) is better than GM's though with GM you can get things up running quicker and easier, and Unity's whole d&d script/inspector/component system has some advantages too.  But sometimes those things just get in the way, forcing you to do things the Unity way instead of however you feel like.


About custom shaders...GMStudio has a nice shader system, without tomfoolery.  People have actually used it for 3d, including different shadow systems, deferred rendering, GPU skinning, and other things.  One of my favorites is a thing that let's you apply normal maps to sprites(you can create with something like SpriteLamp, draw manually, or render from 3d).  It makes 2d games look very nice.


About prices and version....Unity can't really say much about this.  I'm sure you know how Unity is suddenly doing a huge price increase and forcing subscription for the long run, which wouldn't be a problem if the pricing made sense like Adobe's does.  Also, I was using GM at the time the whole debacle with 8.0 and 8.1 happened, and I don't remember running into anything that kept me from wanting to upgrade to 8.1.  Yoyogames did not charge people for that upgrade either, and in general were up front and honest about it, and frankly had a good reason for the issue, getting rid of the DRM they had issues with.  Unity on the other hand, at this point announces a price increase at Unite like it is a good thing for the customers.  I'm currently subscribed to the $75 Pro subscription, and I will eventually have to pay $125 for a bunch of crap, like mobile exports, that I don't want.  So please....as far as the companys' actions, frankly they have both messed up in the past, but Unity is messing up right now pretty badly.


Last point...one strength that GMStudio has over Unity for the purpose of 2d games, is outright speed of development.  Despite the GML language that some people don't like, and despite the lack of the whole D&D/component/object inspector system that Unity has going that GMStudio does not have, GMStudio still manages to be able to get games developed much quicker than Unity, at least for me and many devs.  Those features that Unity has that make bigger/3d games easier to make just get in the way and slow people down for smaller/2d games.