The Game Developer Thread

To be perfectly honest, Source looks very, very tempting. I'll probably try it if I end up learning C++. At the moment, however, I only know C# and therefore can't even try it if I had access...

Wait, I have Portal, I probably already have access. Whatever, doesn't change that I only know C# at present. I probably can't afford licensing anyway.

Chances are that I'll port my game to it later for the sake of Linux customers.

edited 1st May '12 10:36:23 PM by burnpsy

Isn't it free for personal use?

Also, learning C++ from C# isn't terrible. You're at least familiar with the general syntax of a C based language. The only hard part is wrapping your head around pointers/references.

For personal use.

I think I've gone over this before somewhere, not sure if on TV Tropes, but Turtles all the Way is most certainly not some small hobbyist project. We're talking a primary level count of about 50 for just story mode, in full 3D. And we're not talking Super Mario 3 D Land-level short levels. Most certainly not personal.

I know it's generally bad practice to jump into a big 3D game right away, but TBQH, I have everything significant covered except the 3D art itself, which I'm saving up for as we speak.

I was looking up the pricing for Source, and it looks like it's actually NDA, so I recommend shooting them an e-mail and seeing if you can negotiate. Your baseline will be $2,000 for Unity Pro.

Well, Unity Pro's actually $1500 (last I checked, anyway)...

I'll shoot them an e-mail and ask for their price range.

edited 1st May '12 11:55:55 PM by burnpsy

Ah, I do remember a price drop, so $1500 also sounds right.

It's awesome to hear a game dev group that's gong strong! I hear too many crash and burn stories, really, so this is nice.

Incidentally, I am now at liberty to reveal the core mechanics of the game, in a broad sense.

There are two:

1. Every character flies. Since there are slight genre changes for each of the five character pairs, it essentially translates into implementing some manner of flight into stuff like Hack and Slash and Platformer-genre stuff, which isn't new but isn't seen often, either.
2. The "Sync" system. Nearly every level has some manner of partnership between two playable characters, and the player must balance their use between the two while clearing the level. The player is penalized for not doing so, but maintaining a balance comes with bonuses. This, in particular, is causing balance problems that I'm working on, but explaining it to people seems to get me positive reactions with warning that it could be annoying if not implemented well.

I've actually been going around asking for opinions on that second one.

Yeah, you gotta be careful with applying negative reinforcement because it causes a negative impact on gameplay/flow, but without it, you have no feeling of risk.

My opinion for this, and pretty much any kind of mechanic/UX, is to not just sit down and think about implications, but actually get a quick prototype up and put it in front of an outsider and watch them play with it without telling them anything more than what's already presented in the game. A newbie will break your system, no matter how long you've been working on it, so it's best to let them do that in the beta phase so you can patch it up before releasing.

Sadly, however, I can't get a prototype together just yet for various reasons. One of which is because I'm having a hard time figuring out what to penalize. I've got the bonuses figured out, but not the penalties.

edited 2nd May '12 2:25:48 PM by burnpsy

Make the penalties inverse of their bonuses?

Bit hard. The bonuses are things like elements of the partners' powers being implemented into attacks and other miscellaneous things like that. (For instance, someone who spins really fast to act as a drill has the wind-powered partner make tornado-like wings to make her spin faster)

Unless I went and claimed that they're "out of sync", thereby causing that example situation to be the tornado spinning in the wrong directio- wait, why am I not doing that?

Oh yeah, because most of them don't work out so perfectly. :/

The main combinations that players will be dealing with are:

• Implosions and Fire
• Lightning and Sound
• Ninjutsu + Magic and Shields
• Wind and Drills
• Water and Earth

Now, while I can think of (quite obvious) ways that the last three can both help and hurt, that's considerably more difficult for the first two pairs.

Of course, stuff like power penalties, lowered fatigue efficiency, etc, can be easily translated.

Rapid shotgun prototyping is one strategy I like to use in the cases when I have no idea what to do. Make a list of possible things that you can penalize and spin off a different build for each of them. Throw them randomly at people and see what gets good results and hopefully you'll have an idea of which direction to go.

If you want to be more scientific about it, do the same thing of listing out every possible thing to penalize, but instead of immediately spinning off builds and testing them, figure out the relationships between them—some of them will be similar to one another and some of them will be clear opposites.

Once you have opposites, that means you have an axis. Take two of these opposing pairs and make a graph. Spin off three builds based on three arbitrarily chosen quadrants (this is why you wanted to figure out which ones were kind of related). For example, let's say we're graphing color instead of concepts: one axis is blue-yellow and the other is red-cyan. I'd then spin off a blue+red build, a yellow+red, and a yellow+cyan, or something to that effect.

Now get a tester. Throw all of these in front of them. The trick here is that because you are giving them three opposing things, they are able to better describe what they like and dislike about things due to having things to compare against. As they test and talk about their experience, you'll notice them lean toward a certain quadrant. In this way, you now have a general idea of what path may be better than another, and you kill two possibilities with one stone—possibly more if there were strong relational links between things.

Sounds logical. I'll be working on that soon enough, but certain other things need to be put out of the way before I can even do it, not really things I can reveal, but yeah.

This thread is relevant to my interests...

Our ACM group did the Ludum Jam a few weeks back. Two groups.

The other group finished a game, while ours was playable, but not completable.

The people out there at Valve have taken a week and haven't even given me a response. I'd understand if they were checking to see if they'd accept my game on their service, but just asking if I could start to negotiate a price for a license to use their engine?

Yeah, they clearly don't want my business. I'll try again when I'm a not-startup.

give them a second e-mail. Maybe it got caught in a deluge of other stuff.

I'll do that. If I don't get a quick response, though, I'll just keep working on it in C#.

Interesting report of another indie studio's initial costs after a successful Kickstarter, in that only about 1/2-2/3 of what they raised went into directly funding the game

There's a couple thousand dollars that I'm not sure about (namely feelies and premature advertising; I'd also say lawyer fees, but it looks like they're doing something that can be tied to Star Trek, so they're going to want someone protecting them), but other than that, I'd say that's about right.

Lawyer fees should be included regardless of content.

But, in any case, I saw that ages ago. The only thing I question is the PAX costs. They should have honestly just not done that at all and put that toward the game.

yeah, that's what I was talking about with premature advertising. No need to spread the word about your product if the kickstarter campaign is already done and the ball's barely begun to roll on the actual thing.

So I've been learning C# over the past few days and I can feel myself getting ever closer to the point of maek gaem, albeit a primitive one. Any commentary on what kinds of games are the easiest to make, ignoring the clone answer? I suspect highly abstracted space shooters would count high among the "easy, bro" list, but that's a suspicion rather than being based on any actual fact.

Easiest type of game to make? Visual Novel.

Puzzle game? Dunno how easy that is to make, though.

edited 13th May '12 1:27:16 PM by RocketDude

^^

> implying I can draw complex art
> implying I can write anything worth a damn

I know you don't want to do a clone, but clones are the best answer. Tetris is a really good exercise because it teaches you about about input, data structures, etc. Alternatively, Asteroids is also another good thing to implement because it teaches you about vectors and collision detection. Personally, I've built most of my knowledge off making Asteroids in pretty much every new language I learn.

Most importantly, by doing a clone, you have a very concrete goal, so you can accurately measure how close you are to finishing. You're probably not going to release your first game, since it's an exercise anyway, so it's really not that big a deal. Also, remember you don't have to do a 100% clone. Just clone the abstract idea and then eventually, when you've got the base down, you can start adding features of your own make.

I keep linking to him, but Chris DeLeon has more in depth points as to why cloning is good

edited 13th May '12 2:00:58 PM by ch00beh