Casey HardmanMember Since 08 Feb 2011
Offline Last Active Jun 26 2016 01:28 PM
- Group Crossbones+
- Active Posts 349
- Profile Views 16,218
- Submitted Links 0
- Member Title Crossbones+
- Age Age Unknown
- Birthday Birthday Unknown
Game design, game programming, writing
Posted by Casey Hardman on 30 October 2012 - 05:41 PM
I'll be compiling the information from this post and the "so you're a programmer" post into a document, so I can have it as a reference if there comes a time where I want to start a team.
If anyone has any other advice or links to possibly helpful threads/articles, I'd appreciate seeing them, too.
Posted by Casey Hardman on 26 October 2012 - 12:37 AM
I have some questions about game development teams in which the developers are not paid (they volunteer to help develop the game). I'm asking because I may want to try this in the future, and I want to approach it in the most professional way possible. So, I'm hoping to get answers to some more specific questions, as well as general advice on the "do's and dont's" when it comes to recruiting volunteer teams.
I understand that, since the developers would not be paid for their work, it's expected that the game would be released for free if it's finished. In this case, any volunteers you would attract would most likely be contributing because they want a finished game where their work is displayed, so they can reference this in their portfolio.
The other case would be when they are promised a share of the profits that the game makes, and they want to rake in the cash when the project is released and sold in the millions. I hear these types of approaches very rarely work out and usually end in either a failed project or a finished project that makes no revenue.
So here are my questions:
1) Is it a bad idea to even attempt to get a bunch of volunteer developers together to make a game? Do these kinds of teams work out often, even if the project is of a reasonable scope?
2) Do those projects which promise a share of profits ever really work out? What must be done to make a project like this proper and professional (e.g. contracts, licenses, and all that legal stuff)?
3) If you finish a game project with a volunteer team, will they expect you to have other game projects ready to develop with them, or will the team split off and do their own thing afterwards?
4) Should the team mark the game with a "company name" or splash screen once it's finished? If the team splits up and the leader later creates a new team to make another game, should the same "company name" be used? Or should there be no such thing used whatsoever, just a "credits" menu in-game which details all of the contributors to the project?
Ok, I think that's all. Feel free to share any advice you can on the matter!
Posted by Casey Hardman on 11 October 2012 - 08:25 PM
What did you do to the input settings when you say you "tried to change it"?
Posted by Casey Hardman on 07 October 2012 - 06:40 PM
I've been scripting/programming for a few years now, and I seem to be progressing rather well. I can do things comfortably and a lot easier than I could before.
I've used C# with XNA a bit, and UnityScript/C# with Unity. I'm familiar with the Unity engine.
However, I didn't really go by the suggested routine: make a simple game and move up. People here frequently suggest that new programmers make a small game, like a Pong game, then move on to something a bit harder. I didn't do that; I just stumbled around making some pieces of a dozen different projects without ever finishing any of the projects. I didn't focus very well, and got sidetracked on lots of stuff.
Now I'm wondering if maybe this entire time, I've been making a lot of mistakes in programming that I couldn't notice, due to my indirect approach at programming.
However, I'm not entirely sure how to go about figuring out if I actually am making mistakes that I don't notice.
I can't just dump a bunch of code on the GameDev community and say "Hey, is there a more efficient way of doing all of this?", and if I try to show smaller blocks of code, how would I know which pieces to show?
So the question is, am I just being paranoid, or should I be worried that I might be doing things wrong without even realizing it? If the code works, does it really matter if I could have done it in 3 less lines, or with 1 less 'if' statement?
Hopefully this doesn't sound completely stupid...I'm just fretting because I've been coding alone for a while, thinking I've been learning and getting better, without really having any 'confirmation' of that by more experienced coders.
Thanks for reading, any help you can give would be appreciated!
Posted by Casey Hardman on 25 September 2012 - 06:43 PM
This applies to responses to NPCs as well. I'd like to know how they're going to react. Sometimes, the tough army veteran dude will get angry at me if I say something too soft, so I should say something badass and rude to get his respect. Other times, he'll just get angry if I try to be badass. There's really no way of me knowing for sure how the NPC is going to react...and if saying the wrong thing permanently makes that character hate me, I'm going to be pretty irritated if I make the wrong choice.
When I played Fallout 3, I would take so long just to make a choice on which quest path to take, or which conversation path to take, because I was constantly quick-saving and loading to try different things and see what happened...
Posted by Casey Hardman on 07 September 2012 - 04:44 PM
But no, honestly, what does your OP even mean? You're going to have to clarify if you want a serious response.
Posted by Casey Hardman on 04 September 2012 - 01:48 AM
You're kind of leaving us shooting in the dark with basic things like genre and setting.
Posted by Casey Hardman on 02 September 2012 - 04:36 PM
Once I got used to Unity's interface, it proved to be very intuitive. It allows you to pull around views to wherever you want, and add new ones wherever you want. Maybe try some customization to make it more comfortable?
Otherwise, if you still dislike it, try UDK and the Kismet system out (which someone else mentioned above). I don't use UDK, so I can't give you much advice there.
More about UDK's licensing can be found here.
Maybe I'm just biased, but it seems like relying on a 'no programming alternative' would limit how specific you could make your game, and if it doesn't, then it seems like it would just be adding a lot of unnecessary GUI to what could just be a text file.
Posted by Casey Hardman on 01 September 2012 - 06:33 PM
"I have a game idea! ... What now?"
In short, the answer is no. People usually don't buy GDDs, even if they are very detailed. The problem is that making a game is hard work. The GDD isn't very valuable to developers, because there's so much more to making a game than the design: programming, art, music, sound effects, etc.
The article pretty much sums it up. I suggest you take a gander at some of the other articles on that site as well. It answers a lot of frequently asked questions.
Posted by Casey Hardman on 06 August 2012 - 10:08 PM
I meant to ask there, would the 2 years I've invested in XNA not be wasted if I decided to switch platforms now?
I would assume they wouldn't be wasted, since you'd still know how to program. You'd just be using a different language.
I'm not even a professional programmer, and I didn't find it very difficult to go from UnityScript with Unity3D to C# with XNA, as far as general syntax goes. I believe it's general programming stuff that's most important, and you'll still use that even if you're using an engine.
Posted by Casey Hardman on 18 July 2012 - 04:41 PM
If so, I suppose each subclass could be treated similar to a "school of magic" or "skill tree". For example, Fire magic excels at dealing damage, Ice excels at snaring and slowing but lacks damage, and so on. Then the player can mix spells from each school/tree to have their own unique playstyle.
Or did you mean that each one is generally similar, but have different art behind their spells? That's kind of what I get from this:
they have very distinct spell effects, nature mages throw leaves and make spikes shoot from the earth while a shadow mage throw shadowy tentacles and swirling patches of darkness. The game effect is pretty much the same, damage and snare or root. But I know players love to customize.
If so, I don't think that'll make players feel like they're customizing, since there will eventually be hundreds of players with the same subclass as them.
Posted by Casey Hardman on 19 June 2012 - 02:59 PM
Maya is a 3D modeling program. In other words, it's used to make models and animate them so you can import them into your game and put them into the game world.
Blender is another 3D modeling program. It's free to install the full version. I use it and I think it has a genius design, though I'm not very talented with 3D modeling.
Now, with 3D modeling programs, you can make crates and characters and creatures...whatever you might need in your game, with enough skill, you can make it with 3D modeling. However, you should remember that 3D modeling is it's own thing, an entirely new practice compared to programming/scripting. It takes artistic skill and lots of practice before you'll start making the amazing graphics you see in AAA games. Also, 3D modeling only makes the mesh and the animations and such. You'd still have to add textures/UV maps to your models to make them not just gray figures with no color. Skyrim and games with high-quality, realistic graphics usually use bump maps (in short, they make textures look less flat) and other special techniques to make things look even better/more realistic.
When I got into Unity at the start, I was only interested in learning how to script with it, so I didn't get into 3D modeling and texturing right away. I got into it later, though, and picked up Blender for 3D modeling and GIMP for the textures (both free).
Now, I don't mean to try and totally discourage you from art if you want to try it. I'm just saying this because I wanted to make sure you knew what it was and that it's kind of its own thing. If you want to do it the way I did and focus on scripting for a while before getting into art, that's fine. If you want to learn 3D modeling and texturing while learning how to script, that's fine too. Really, it's all about what you're interested in. You don't even have to know how to do both unless you absolutely must make games all by yourself. If you don't like 3D modeling, you can wait until later when you're good enough at scripting to get a team to help you with the art.
Anyway, now that I've rambled on forever, here are some links and tuts for Blender and UnityScript:
Here's a link to the official Blender website
Here's a link to forums for Blender (if you have questions about Blender in the future, they might be better fit there than they would be here at GameDev)
Here's a tutorial to Unity's basics
and here's a tutorial to complete beginner's programming with UnityScript
That tutorial supposedly "assumes no prior programming experience", which I believe is what you're looking for.
Good luck and have fun!
Posted by Casey Hardman on 17 June 2012 - 04:33 PM
I only used UDK for a tiny bit and never got into scripting with it, but it seems less beginner-friendly than Unity3D. I believe it comes with a bit more capability of "graphical finesse" and customizable materials (which alter how things look). However, Unity Pro (which costs $1,500 at the moment, I believe) is always an option if you need fancy graphical tools somewhere along the road when/if your game is nearing finished.
Also, in my opinion, scripting with Unity is still very similar to programming and won't be neglecting you of "proper programming skills" as much as some might think.
If you're getting into Unity, here are some tips, just from my personal opinion as a user of Unity and with some experience using Visual Studio and C#:
- If you need help with Unity or scripting something in Unity, you can ask for help on answers.unity3d.com. The community there is active and helpful. Remember to actually try and script something before you ask a question, otherwise you're just asking people to script your game for you!
- Bookmark Unity's scripting reference. It has lots of examples for you to look at, and you can change them to show UnityScript, C#, or Boo.
- You may have an easier time using UnityScript instead of C#. The reason is that UnityScript is more dynamic and might not bother you as much in some situations.
- Don't worry too much about which language you start with. Switching from using UnityScript with Unity3D to using C# with Visual Studio took about a week for me to get comfortable. It's mostly just syntax stuff that you shouldn't have too much trouble with. The largest part is just getting the concepts of programming down.
Posted by Casey Hardman on 22 May 2012 - 05:36 PM
I guess the OP thought of (typical game scenario) and then decided to...get ready for this...DO THE OPPOSITE to create something 100% unique and marketable!!
Seriously, though, I think this belongs in the Completely Raw Game Ideas With Very Little Thought Put Into Them forum. It's just a basic idea that I'm sure has been thought of a thousand times over when people were wracking their brains to find (typical game scenario) so they could...get ready...DO THE OPPOSITE!! or...CHANGE ONE TO TWO THINGS!!
Posted by Casey Hardman on 07 January 2012 - 04:09 AM
I agree. It's annoying when you feel like you "have" to play longer because you'll lose progress if you stop now. Quick-save features like Fallout 3 and Skyrim had were life-savers in situations like these, and both of those games were ones I was immersed with.
In games like Fallout 3 and Skyrim, the save/load feature never really made me feel less immersed. In fact, if I felt I had to go through with my decision to lop someone's head off and face the entire city full of guards and citizens afterwards, I would rarely do it and wouldn't end up having much fun...
Maybe it's just because these games are the type where, if you die, you load your last save and try again instead of having the storyline changed. However, I still feel like I'd like to win if I can, whether it's on the first try or the seventh. I'd prefer trying multiple times.
I don't think this would ruin immersion, because in my opinion, immersion isn't "thinking you're inside the game" - you'll almost always be aware that you're playing a game, but if you're immersed, you'll care more about what happens in the game. If your players care enough to repeatedly try to beat the specific fight, then why stop them?
I say, let them save/load, but tell them and remind them throughout the game that they don't have to win to progress.
Not to derail this post back on-topic, but...this! All of this! It's fun to have the option to try out a few strategies before settling on just one, and sometimes it's fun to just go total rampage on a village, without having the consequences of such permanently tied to your character. Save/load gives players greater options to play the game the way they want to play it; it causes less anxiety about making sure you're always doing the "right" thing, regardless of what you actually feel like doing.
But really, for me it still all boils down to the simple fact that I need to be able to quit and turn off the game when I'm done playing. If a game's going to hold me hostage, making me play for another half-hour before I can save and quit, then I'm not going to be playing that game all that much. Period.
You made my night with those quotes...they were so fitting of the situation.
Please keep it civil guys. Balance is a complex issue, and extremely difficult to evaluate for all but the simplest rulesets. Strong statements such as 'Starcraft is balanced' or 'Classes are always imbalanced' are actually pretty difficult to support, and frankly, off topic for this thread. If you want to discuss balance, please do so in a new thread.