The Unity manual has some basic teaching on vectors here, most of which could probably be applied to SFML as well.
Casey HardmanMember Since 08 Feb 2011
Offline Last Active Yesterday, 11:09 PM
- Group Crossbones+
- Active Posts 349
- Profile Views 11,980
- Submitted Links 0
- Member Title Crossbones+
- Age Age Unknown
- Birthday Birthday Unknown
Game design, game programming, writing
Posted by Casey Hardman on 29 August 2015 - 05:52 PM
Posted by Casey Hardman on 05 April 2014 - 03:56 AM
I agree with jHaskell and menyo, but I want to stress that we're not saying "get out of our community!"
We're just saying you should do some research on a topic yourself, using Google to find some articles. If you had done this beforehand, you probably would've figured out that there really isn't much room for opinion when it comes to loops, and you'd easily be able to find out what a loop is, how different kinds of them work, what they're often used for, etc.
You don't have to let the somewhat negative reaction to your post put you off from GameDev.net forever. We're just telling you how things work around here and how you're expected to act, and if you follow our advice, you'll get much more positive reactions.
Posted by Casey Hardman on 06 January 2014 - 09:46 PM
Unity is more beginner-like than UDK (by far, in my opinion) and gives you a cleaner way to get code into your game.
All you need is to get good with C# and programming in general, and learn the Unity classes (GameObject and Transform are important). All you've gotta do is write a script and drop it on something in the game to get the code running.
I would suggest using Visual Studio C# Express or MonoDevelop to write your code. They have convenient features that will help you in the future.
Bookmark/favorite these pages, they're very useful to have around for when you need them:
- This one for the search bar; it lets you search any class in Unity and see all of the methods and variables inside it
- This one to find information about specific components and how to use them (such as colliders, rigidbodies, lights, etc.)
- This one for whenever you need to configure your colliders/rigidbodies; it's helpful because at the bottom of the page it gives you a chart of which kinds of colliders will collide with others
- This one for all you need to know about C# syntax
Also, since I believe you're programming a 3D game, you should know how Vector3's work if you don't already.
Posted by Casey Hardman on 02 January 2014 - 07:37 PM
In my opinion, the language you choose should be more about what you want to do right now than it is about 'what the best language is'.
If you want to make your game quickly, you might want to go for something like C# or UnityScript, so that you can use Unity to make your game, or UnrealScript to use the UDK to make your game, or the Game Maker Language to use Game Maker to make your game, and so on.
If you just want to get really good at game programming and get a career in it, and don't have your own game projects that you'd like to work on, then going with C++ like you are might not be a bad idea. However, if you're interested in getting out there and making your games with less hassle, then it might not be the best option.
Keeping that in mind, it's always great to get out there and start learning. Don't think about the language too too much, or you'll just sit around never learning how to actually program, and like Godmil said, programming skills are transferable to other languages.
Posted by Casey Hardman on 23 October 2013 - 06:10 PM
I've been using Unity for a while. I never got that much into XNA, so maybe I'm biased, but...
Based on my experience, I'd recommend you go with Unity. It's a very polished and powerful engine, and it'll get you up and running quickly. The community is bustling and helpful, so you shouldn't have too much trouble figuring out how to do what you need, if you ever find you don't know how to program something (chances are, someone else has already asked how to do it and gotten help).
Just get Unity and give it a shot.
Bookmark this page (the search bar lets you read about all of the Unity classes) and read through this short little tutorial, which will teach you how to get your scripts running in-game (it's simple and organized) and other basic fundamentals.
I use Microsoft Visual C# 2010 Express to edit my scripts. It's free and very useful: you may not want it right away (I thought it was confusing at first), but the shortcuts and member info features come in handy later. I'd recommend it over the script editor that comes with Unity.
Lastly, if you ever find you have problems that you can't solve yourself, you might get more help on the Unity Answers site than you will here on GameDev. Specifically, questions that relate to the engine itself in any way are probably best on the Unity Answers site, but general programming questions are probably best on GameDev.
Posted by Casey Hardman on 18 July 2013 - 06:41 PM
In my opinion, you could absolutely make games with Unity's free version. All of the main functionality of the engine is in the Unity free version. If you need your game to have top-notch, amazing graphics, then you'll probably need Unity Pro for that because a handful of important graphics features are locked in the free version.
So I'm of the opinion that if you're trying to make games, you should go with Unity. If you're trying to become a great programmer and make engines, then go with something else that is more in that realm. It's not bad to use Unity and purchase/download other peoples' tools to help you make games. It'll save you a lot of time.
Posted by Casey Hardman on 21 May 2013 - 03:21 PM
If I want to add some article which I found out to be good, how can I share that here?
Send me a PM and I'll check it out
Posted by Casey Hardman on 18 May 2013 - 09:32 PM
I've experienced the same problems with UDK as you: it's a huge pain in the ass to try and code things with it. It's just...ugh...
A while ago, I made this reply to a post about the differences between Unity and UDK. My opinion still stands, though I now dislike UDK a little more...
It just seems poorly designed, especially in comparison to Unity. It might have a lot of fancy features and it may be powerful, but I don't really care if it takes me 15 hours to do something with it that I could've done cleanly with Unity in 15 minutes. Unity's development process is intuitive and it gets out of your way; it lets you program your own way. I'm not sure if I ever even figured out how to code something and make the code run in-game with UDK, but with Unity it's as simple as making a script, putting down some code in one of the event functions, dropping the script onto a GameObject, and playing.
Also, Unity is constantly and visibly improving, whereas UDK seems to be slower about this.
I use Microsoft Visual C# 2010 Express to edit my code (a later version is probably out by now). It doesn't allow you to set up breakpoints that will activate while you play in Unity, whereas I think MonoDevelop does (or did at one point), but it's a very robust tool and I think it's great.
So, to sum it up, I can personally recommend you stick with Unity. If you need to optimize your performance sometime along the road, then as you said, you can purchase Unity Pro. If Unity can't do something you want it to do, then you could probably figure out a way to do it yourself, or find someone else's method of doing it.
Posted by Casey Hardman on 13 April 2013 - 04:15 PM
Also could the following sections be added (either by you or someone else).
"I am new, what language should I learn"
"Should I use a game engine or make one"
"What should I pick C++ or <insert managed language here>"
I just did some revamping to the Introduction to Game Development article. In the 'Getting Started' section further towards the bottom of the article, you can find some extra resources are now available for programming, including one that answers the questions you've asked.
Hope it helps
Posted by Casey Hardman on 13 April 2013 - 01:57 AM
Greetings and welcome to GameDev.net!
This thread is here to provide new users with information that they commonly come here seeking. The goal is to get you to the resources that will answer your questions quickly, without you having to post and wait for replies. Also, we often get the same questions asked by many different users many times; it'll be more convenient if they're all answered in one place.
If you're completely new to GameDev.net and haven't been lurking around for a while, then reading these resources will help to answer all kinds of questions you may have in the future.
If you came to the forums because you have an idea for a game, then this resource is for you. It clears away many misconceptions you may be holding about game development, and puts you on the right path to getting your game made.
If you're here because you have a general curiosity for how games are made, what they're made of, and/or how to start making them (or parts of them) yourself, then this resource is for you. It's a broad description of game development and its individual aspects. It also has resources for learning more about specific fields of game development.
Note: This resource is rather unfinished at the moment and could use some help from the community; but it can still serve as a good starting point for now.
This Frequently Asked Questions page for the GameDev.net "Breaking into the Industry" forum has a collection of helpful resources for people who are interesting in getting a job in the games industry.
I'd suggest you keep this page bookmarked for future reference.
Chet Faliszek, a writer for Valve, talks about how to get a job in the games industry in this YouTube video.
If you're looking for a book, this is a link to an Amazon page for a book by Ernest Adams.
Suggested by user pyxunyann
Posted by Casey Hardman on 07 April 2013 - 03:44 PM
Disclaimer: I'm not trying to be rude, just trying to help you out on your journey through the wonderful world of game development
You should put a little more time into making your posts use proper (or somewhat proper) grammar.
Personally, when I'm playing games I don't use proper grammar, but I suggest you put some more effort into your grammar when you're on forums and such. The posts on forums are lasting; they'll be here for years to come.
It doesn't have to be perfect (mine isn't).
Second, some people will suggest that you don't start with C++ because it can prove to be harder to use than some of the other alternatives. You could try using Unity as your game engine, with C# or UnityScript as your language (I personally prefer C# because it can do more). Or, if your game is 2D, you might have an easier time making it with the Game Maker engine and their scripting language, GML (Game Maker Language).
There are other engines you could use that would probably get you up and running faster and with less loss of hair than with C++.
I'd suggest you start learning general programming stuff before getting into a specific language. This is the thing I didn't do when I started learning programming. My learning was very hackneyed because of it; I kept learning how to do X with this language, instead of what X is, what it should be used for, etc.
The most important parts of programming aren't language-specific. The language is just the way you write the code, but you're still coding even if you're using different languages.
Posted by Casey Hardman on 27 March 2013 - 01:22 AM
OK, I'll do some improvising.
A spell that...:
- increases fire damage dealt by you, but deals damage to you over time (or nukes you when a spell is cast)
- conjures a large scythe of flames to damage everyone in an area around you (deals extra damage to Plant type enemies; the farmer's scythe is their greatest fear!)
- conjures a fire 'geyser' that spews flame/lava upwards; also consider a variant of the spell that summons an array of 'geysers' scattered across a large area, if you want something less predictable
- conjures a miniature volcano that lava will pour out of for a duration, forming streams of lava across the ground around the volcano
- conjures a pool of ashes on the ground for a duration, slowing enemies in the area. If a fire spell touches the ashes, they will all ignite, burning enemies in the area for damage over time (or just nuking them once, if that's what you would prefer)
- spits a cone of ashes in front of you, blinding/stunning/knocking back/slowing/whatevering enemies it touches
- summons a whip of flames that repeatedly flings in a circle around you for a duration, damaging enemies it touches and having a chance of burning/slowing/stunning them
- summons a circle of fire around a location that gradually grows smaller; if an enemy touches the fire, they begin burning, increasing the damage they take to fire magic and damaging them over time; once the circle of flame forms a ball in the center of the targeted location, it explodes outwards, nuking enemies in range.
- burns all poison or other negative buffs off of you; for each effect removed, you are nuked for some damage and are buffed to deal a percentage of extra fire damage for a duration.
Posted by Casey Hardman on 22 March 2013 - 06:14 PM
Ive tried to finish it a number of times, but somehow, whatever I write is crap.
(Going back off topic again; sorry)
Not sure if you two are talking about an article for one of your own websites, or if you're talking about an article for the GameDev article database...but if it's the latter, then I could help you with wording and formatting and such, if that's what you think you're having trouble with. Just shoot me a PM if you want.
Posted by Casey Hardman on 20 March 2013 - 03:45 AM
Writing game stories really isn't different than other kinds of writing
I disagree. I mean, by that logic, why is there a "Writing for Games" subforum at all instead of people just using one of the dozens of other creative writing forums out there?
The way a game portrays a story is much different than the way a book portrays a story. A game has so many different things to offer to the narrative, and often consists of much less exposition-through-text than movies, and especially less than books.
The player has to actually play through the game to reveal its story, unless your game is just 100% cut-scene. This provides challenges like keeping the player interested without bombing them with text, which usually just disinterests someone who's playing a game, because games are interactive - if someone wanted to read a lot, they'd read a book.
Games should use the tools at hand to provide their story, and not rely solely on text and linear storylines.
While a movie might portray a character's badassedness through elaborately planned stunts during a fight scene, a game might portray it through an intriguing boss fight that puts you on the edge of your seat.
While a book might explain the way something looks and leave the rest to imagination, games provide all the appearance right up front.
While a book would explain a whole fight scene, games let you carve them yourself, with the potential of making it feel all the more personal and making you feel awesome by the end of it.
I know reading about Lloyd and his group of Exsphere-wielding friends kill Abyssion on Mania difficulty in a book called "Tales of Symphonia" would be a lot less interesting for me than playing through the fight myself (and smack-talking Abyssion whenever I used Guardian before his Meteor Storm could hit me).