Jump to content

  • Log In with Google      Sign In   
  • Create Account

Nick Gravelyn

Member Since 14 Aug 2005
Offline Last Active Oct 05 2014 03:38 PM

#5131340 [Question] Regarding calculating tile position from GID

Posted by on 14 February 2014 - 12:06 PM

Notice in that thread they're using the width in both the x and y calculations whereas you swapped in the height. I believe that could be causing you issues.

#5057017 xna random number in 2d

Posted by on 26 April 2013 - 11:04 AM

Random r = new Random(DateTime.Now.Millisecond);
Vector2 randomVector = new Vector2(r.Next(0, SCREENWIDTH), r.Next(0, SCREENHEIGHT));

I would make two notes here:


1) The default constructor for Random already handles seeding by time; you don't need to do it yourself.

2) Because of #1, you want to reuse the same Random instance as much as possible. For example if you ran this:


for (int i = 0; i < 100; i++)
   Random r = new Random();
   someVectorList.Add(new Vector2(r.Next(0, ScreenWidth), r.Next(0, ScreenHeight));


You would find that quite a few (if not all) vectors would have the exact same values. This is because each new random instance would have the same seed and therefore generate the same sequence of numbers.


So in general you want to create one Random per method at the least, but most people generally just make one Random instance as a public static member on some type and reuse that everywhere.

#5052558 C# include?

Posted by on 12 April 2013 - 01:42 PM

You can use #if/#endif in C# for using preprocessor directives.


You can also add files as a link, so you keep the file in a common directory and any number of projects can include the file as a link which means they'll all share the same C# file, but it will be compiled into all the projects. As long as the projects don't reference each other you should be fine (if the projects reference each other, you're likely to get an error for having the same type compiled twice).

#5043198 C# for 2D game

Posted by on 14 March 2013 - 05:17 PM

XNA isn't dead. Dead implies it doesn't work, isn't available, and isn't supported by Microsoft. None of that is true. The only truth is that there will be no more updates to XNA. If the current feature set of XNA meets your needs, there is no reason to avoid using it to build your game.

#5040947 C++ for Gaming Industry

Posted by on 08 March 2013 - 02:18 PM

I'd toss out that C# can be a good language for studios. Lots of C# used for tools, build systems, etc. You may not be directly engineering the game, but while on a tools/pipeline team you can learn a lot about the studio, the code, and build familiarity/skills over time that will enable you to move into a different engineering role if you want.


I'd also mention that Unity is becoming more prevalent of an engine which uses C# for scripting (technically also UnityScript and Boo). It's obviously not taking over the AAA spectrum yet, but a decent number of companies are starting to use it and I expect that number will continue to rise.


And lastly, in my experience, the really hard core C++ needs are deep engine work. Many studios (especially as you get away from the smaller ones) have dedicated engine teams leaving many of the remaining devs to write higher level concepts. Even if you're still in C++ and not some scripting language (some studios break out Lua or another language for scripting) the requirement of knowing the nitty-gritty C++ stuff starts to loosen as you're writing more game-specific code (so you don't have to have a general solution that works for 100% of scenarios) that can start being less performance critical (such as simple UI backing logic).


Everyone starts somewhere and it usually isn't the role of most knowledgeable C++ engineer in the company. You need to learn enough C++ to be competent and show an aptitude for quickly learning new skills. That's what I'd recommend, anyway.

#4872257 Legend of Zelda Corner-cutting

Posted by on 13 October 2011 - 12:02 PM

The first thing that pops to my mind is to not treat the player as a square (or rectangle) but rather as a circle. By interpreting all the player collisions as a circle hitting a corner, if you implement the resolution properly he'll naturally slide around the object. It also creates nice collision resolution between the player and other characters and so on. I haven't played a classic Zelda in a while, but I'm fairly confident that's how the SNES version handles collisions.

#4866989 "Quests" vs "Favors"

Posted by on 28 September 2011 - 05:08 PM

I actually really like both of your separations as I think the two generally could go hand in hand (after all, how is killing ten bunnies going to get me closer to defeating the uber dark lord?). I think there are other things you could use to further differentiate, depending on the nature of the game and how far you want to take it:

- Favors increase goodwill with townspeople, leading to lowered prices for goods or increased selling rates.
- Quests give more sizable rewards such as new weapons and armor, whereas favors yield smaller amounts of money or items.
- Favors could lead to side quests. Perhaps you do a couple favors for a townsperson afterwhich he mentions a friend in a nearby town. Upon visiting his friend, you're given the opportunity to do more favors, quests, or side quests. (In this context the "side quest" would be identical to a standard "quest" other than it doesn't progress the main story arc but would still be large and potential yield good rewards).

#4863525 Might just be my way of seeing things, but........

Posted by on 19 September 2011 - 03:15 PM

What's up with all these "tools" nowadays? Free source game engines? Really? That's depriving programmers the actual work of the game as a whole.

Sure, but it enables designers and artists to build games they previously wouldn't have been able to without learning how to be expert programmers or trying to find expert programmers to work "for" them.

I mean sometimes these "tools" may come in handy, like game engines, but understanding what they are and how to make them yourself would be much more rewarding

It depends. For some people (generally programmers), building the tech is the rewarding part. For others, the rewarding part is shipping a game that people can play. Tools like Unity and UDK enable people to build higher quality games in less time than it would take for most people to build comparable technology.

Ultimately I think having things like UDK, Unity, and CryEngine 3 available to the wide development audience is the best thing to happen to the games industry in a while. Hopefully it will allow more teams to build amazing looking games using existing technology rather than having every person start off by figuring out how to write an engine. For example Adhesive Games, the people behind the amazing looking game Hawken, are mostly artists: http://www.adhesivegames.com/team.html. That team make up is only possible because they have the UDK to handle the hard technical work for them.

I flip between both views with my personal projects. Sometimes I just want to make the game and ignore the tech. Othertimes the tech is the interesting part. It all depends what you're trying to get out of game development and what your personal skills are.

#4857924 Engines Performance

Posted by on 05 September 2011 - 12:48 PM

The core of Unity is native C++; the only managed code is their scripting languages (which use C#, a slight offshoot of JavaScript generally termed UnityScript, and a dialect of Python called Boo). But even those might get compiled to native code prior to distribution of your game. In any case, the point is that all the really expensive costly operations like physics and the rendering pipeline all run native code and not in your scripts so performance of the scripting languages is largely a non-issue. If you decide to use Unity, pick whichever of the three scripting languages you are most comfortable in.

For a beginner I recommend the approach of "pick one and work with it". You're unlikely to learn the be-all-end-all of game engines out the gate. If you are just starting out, the most important thing is to learn the basics of game development. Once you're comfortable writing games in one or two languages, it becomes much easier to take your experience and move to another system. So if you decide that BGE looks the easiest to get into, start there. Once you've gained experience and found out whether BGE can do what you want, then you can decide to jump to other technologies.

In short: don't worry too much about it right now. If you're just starting out, you're not going to make a AAA quality game for quite a while. It's just how it is for everyone starting out. Find a language and tool set you find easy to use and make some games. :)

#4855668 XNA 4.1 Confusion

Posted by on 30 August 2011 - 04:59 PM

There is no XNA Game Studio 4.1; it's XNA GS 4.0 Refresh just to be clear.

As far as your question, yes you can use Silverlight on top of XNA Framework graphics or using a standalone Silverlight page for when you don't need complex rendering. We have a few pieces of education over at App Hub that show off the new Silverlight/XNA integration.


#4726969 how to kill your wife in 24 hours

Posted by on 31 October 2010 - 12:59 PM

I fail to see any entertainment in considering how one would commit murder, especially against someone they, at least at one point, said they loved.

Original post by toony
i have seen this on many forums so why not here?
I'd hope because people on GD.net aren't horrible people.

#4573364 Best Game Engine for Indie Game?

Posted by on 15 December 2009 - 05:34 AM

Another recently free engine: UDK from Epic is basically Unreal Engine 3 but free. You can sell your games with some royalties after a certain amount (I want to say it's 25% after your first $5K but that could be completely wrong).

#4313884 What IDE are YOU using?

Posted by on 14 September 2008 - 08:57 PM

For the day job: Visual Studio 2005 Team Suite (specifically C#) on Windows Vista.
For the hobby XNA stuff: Visual Studio 2005 Team Suite (again, C#) (soon 2008 when XNA GS 3.0 comes out) on both Vista and XP.
For the hobby iPhone/OS X stuff: Objective-C using Xcode 3.1 on OS X 10.5.4.