Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 04 Jul 2003
Offline Last Active Yesterday, 10:18 PM

#5212929 Stat-stick Syndrome : How to avoid ?

Posted by JTippetts on 25 February 2015 - 10:08 AM

Mastering a complex enough stat system can be a skill of its own. In my opinion, going physical-skill-based (ie, aiming) isn't really the answer because I can't aim. I can't play todays shooters, a consequence of a number of injuries that have affected both hands coupled with a natural general suckitude. So the quickest way to turn me off is to take away my stats and make me have to aim at something to hit it. Similarly with dodging. If my ability to win a game comes down to relying on my screwed up hands to pull off a dextrous act of dodging, then I'm hosed.


Positional requirements and scouting, however, I am fine with. But I guess I'm probably not your target audience. And that, I think, is why so many games go with stats over physical skill: an attempt to not limit their audience by excluding us klutzes.


I'm not sure about your arbitrary "binary" classification. How is increasing an enemy's dps a "binary" action?

#5212675 Sculpting vs. Modeling

Posted by JTippetts on 24 February 2015 - 05:53 AM

If you lack the skills to do the traditional "concept art->base mesh->high poly sculpt" workflow, you can skip right to the sculpt. Personally, I can't really draw my way out of a wet paper bag (to crudely hack the phrase), so I just jump right to sculpting. Using the right tools, sculpting can be a very free-flowing exercise, much like traditional sculpting in clay can be. The character in this screenshot, like all of my characters, was created as a sculpt with no before-hand traditional 2D concept sketching, for example. For someone just starting out, or on a limited budget with a limited traditional art skillset, it can be a workable path.


If you don't want to pay high dollar for ZBrush, Mudbox or 3DCoat, you can pick up the nicely intuitive Sculptris for free from Pixologic (the makers of ZBrush). Additionally, Blender now offers an adaptive subdivision scheme during sculpting, similar to that offered by Sculptris, if not quite so UI-friendly as Sculptris. The adaptive subdivision makes it easy to start from a simple primitive such as a sphere and grab/pull/glob your base shape then iterate, adding detail as you go.


Of course, as previous posters have mentioned, if you want to actually use the sculpted character in something, you're probably going to have to retopo your sculpt to derive a lower resolution version, complete with normal maps and/or displacement maps. High-res sculpts can easily weigh in the millions of vertices, making them unsuitable for animation without expensive high-end cluster hardware.

#5211229 Hiding savedata to prevent save backup

Posted by JTippetts on 17 February 2015 - 11:54 AM

What if I change hard drives and can't find your save files to properly copy them over? Do I file your game in the "broken" bin, and tell all my friends to steer clear of it?

#5211203 Dungeons in roguelike. Randomly generated or not?

Posted by JTippetts on 17 February 2015 - 09:45 AM

If a game has permadeath, the expectation is that the player will replay it repeatedly. In my opinion, fixed dungeons are the very opposite of replayable, regardless of if you refill them or not. The whole point, for me, of playing a roguelike (and man, have I played many hundreds of hours of roguelikes) is the procedural generation so that I don't know what I'm going to get on each replay. Fixed layouts are fine for one-off RPGs that I don't ever plan to play again, but not really for roguelikes where death is permanent and the risks are high.

#5208624 Alternatives to Wavefront Obj format for skinned models?

Posted by JTippetts on 04 February 2015 - 08:38 AM

Why not FBX format?

#5207659 Why mmo companies does not use cloth physics and many physics in general?

Posted by JTippetts on 30 January 2015 - 06:25 AM

I suspect the reason mostly lies in the "massive" part of MMO. Massive anything can be technically difficult to achieve; massive high-level physics simulation, I suspect, would be even more difficult.

#5204278 How to actually learn game development?

Posted by JTippetts on 14 January 2015 - 01:39 PM

Making games IS hard. It's a somewhat Herculean task requiring discipline, effort and organization. If you just follow whims, see-sawing back and forth between languages and platforms then you will never get anything done. At some point you have to stop trying to get other people to do the thinking for you and tell you what to do, and start thinking logically about the problem in front of you. Todo lists, goal setting, time scheduling... all of the things that self-help books advise you to do when trying to make changes to your life are exactly what you need to start doing. And effort. Real effort, not just tinkering around. You're not going to be able to just read the right tutorial and have it suddenly gel in your mind in some kind of Eureka! moment; that just won't happen.


On a side note, watch out for depression. If you feel like depression is holding you back, you might want to seek help. There are a lot of causes for depression, and it's easy to underestimate just how life-devouring it can be, but a lot of those causes can be treated. Diet and exercise help me to keep mine under control, and I notice SIGNIFICANT differences in my ability to be productive when I am eating better and exercising. Some causes might require medication depending on the diagnosis. But it is definitely something you want to be aware of.

#5203752 inverted GJK --- you're a genius if you can solve this

Posted by JTippetts on 12 January 2015 - 02:41 PM

The gist of my idea is like this (pardon the crudity of the hastily constructed image):



The red area is the mothership, the purple is the ship coming in for a landing. The green area represents the landing bay. The blue area represents the actual collision box for the landing bay, shrunk by an amount proportional to the size of the landing ship's collision volume. The blue area should be shrunk enough that if the ship is in collision with it at all, then it can not be in collision with the walls of the bay because they are too far away. Navigation mesh construction algorithms use a similar technique: they'll render all walkable polygons then "erode" the walkable areas based on the agent radius so that any agent of the given radius, if it is located on a resulting polygon, can not by definition be colliding with the walls. In this case, if the ship is colliding with the red zone but not the blue zone, then it's crashed into the mothership because it lies outside the "walkable" region.

#5203493 lua discussion

Posted by JTippetts on 11 January 2015 - 10:01 AM

luajit just give's native bytecode, but i want to compile them to make executable
how can i link them together and get an executable?
and it prints the directory that is used by the luajit's compiler, but when i've copyed the JIT directory in one of the directories, that error occurs

You know there are much easier ways to create native executables than to try to hack a language that wasn't designed for that purpose, right?

#5202477 inverted GJK --- you're a genius if you can solve this

Posted by JTippetts on 06 January 2015 - 09:53 PM

Can you just shrink the size of the landing bay box by some amount in each dimension, based on the size of the ship coming in for a landing? That way, if a collision is detected with the box you know the object is fully inside the larger landing bay.

#5200278 Warcraft 3 style Collision avoidance

Posted by JTippetts on 27 December 2014 - 11:36 AM

I don't mean prototypes for public demo. I mean prototypes to help you "figure out what strategy is best to use" in your case. Come up with an idea, write a throwaway test case to try it out, discard or iterate. There is only so much you can learn by discussion.

For example, what data forced you to come to the conclusion that re calculating the path every frame would be too slow? Or are you just guessing about that? I'be done that approach before and it was sufficiently fast for my particular test cases and requirements. Unless you are willing to perform an exhaustive analysis based on architecture and machine performance characteristics, then your best Avenue is to prototype.

#5199308 Sprites flickering when deleting (SDL & C++)

Posted by JTippetts on 20 December 2014 - 02:31 PM

Why are you deleting enemies during your rendering section? Wait until after the frame is done to delete them.

#5196062 2D Game Animation Frame to Frame shading and Coloring Variations?

Posted by JTippetts on 03 December 2014 - 07:32 AM

If you are having difficulty with shading and pose (as I do on the rare occasions when I try to hand-draw stuff) one trick you can do is to do a very rough block-out of the character and pose in something like Blender then set up your lighting the way you need it and do a render of the mock-up to use for a paintover. By using a properly lit render, you have a better idea of how the light falls on the shape and of how the limbs and appendages of the character lie at a given pose.

#5195496 fully motivated to make a video game since could not find right one

Posted by JTippetts on 30 November 2014 - 10:28 AM

Your choice of language right now is irrelevant, considering this is your first project. You could try to do it in Whitespace or Brainf*ck and stand about the same chance at getting it done as with Java. That is to say: almost none. Start simpler.

#5192486 Procedural Map Generation

Posted by JTippetts on 12 November 2014 - 02:04 PM

Thanks, I've seen it though. Everything I can find anywhere is having to do with unity and c#. Neither of which we're using

Concepts typically can be extracted from such sources and used in other engines. In the case of the link above, the key concepts are DeLaunay triangulation, BSPs and cellular automata (which, themselves, provide some tasty search terms).

My personal recommendation is to take a look at the games you mentioned (Diablo, Torchlight, Path of Exile) and try to puzzle how they are doing things. There are plenty of algorithms out there (google "drunkard's walk", for example) most especially in the field of roguelike development, but many of them tend to end up in the meaningless "maze of twisty passages, all alike" category--not unlike the three methods posted above. Those types of dungeons can be great fun, but Diablo and such tend to go a different route, using large pre-built "meta tiles" or blocks from which the levels are pieced together. These pre-built blocks follow the theme of the level, be it "torture chamber", "cliffside wilderness", etc... Using such prebuilt pieces tends to dramatically reduce the possibility space of the levels, such that all variations tend to feel similar and follow similar rules.

I suggest that you don't start with the level generator; instead, you should start with the theme of the level and work backwards from there to determine the kinds of building blocks you will need, and determine a set of rules (a grammar) for putting the pieces together. A source for tasty info on such grammars is the Procedural World blog. In particular, the entries on grammars for architectural bits.