TheSasquatch

Adobe has known for many years that most of its users are pirate and so it is just trying to combat that.

 
Counterproductive. Piracy can't be stopped--all DRM can and will be broken. Any attempt at prevention inevitably alienates users and creates more pirates. As does price gouging, which was the root of their piracy problem in the first place. If they really wanted to minimize piracy, they'd have to lower their prices and be more ethical, i.e., by respecting their users' property rights (preferably by throwing the entire EULA concept out the window).
 
I doubt it's about piracy at all, though. Much like certain game companies, they want to be able to, at any time and for any reason, flip a switch and kill the product, forcing everyone to "upgrade" whether they want to or not. It's taking the old concept of planned obsolescence to an extreme--rather than simply building cheap products that will quickly break, they're going to break them themselves, and on a schedule. They want to ensure their continued profitability without having to worry about their new product ever actually being a worthwhile improvement over the previous one. Every corporate suit out there is drooling at the prospect. If the idiotic masses can't be educated as to why they should be furious about this, it's going to spread to every possible industry, and it won't be long until we'll all look around our rented apartments and realize we don't own anything in them.

This is the kind of anti-consumer behavior that really pisses me off. Every company wants to do it, too--it's class warfare 101: don't let the peasants own anything, only rent it from you. The rich get richer while the poor--including their employees--get poorer (it's a statistical fact that average middle class income is dropping despite executive income increasing to record levels). They deserve whatever backlash they get, regardless of its legality.

 

I'll stick with open source. A little inconvenience isn't an issue when the alternative is giving money to corporate monsters dead-set on eroding individual property rights simply to expand their own ill-gotten fortunes.

What in particular strikes you as being difficult in drawing or creating 2D assets?

 

The biggest one for me is people. You're already covering proportions and anatomy, which is great. Not sure if you're including this in anatomy, but facial expressions, portraying emotion, and avoiding that crazy "uncanny valley" effect would all be good topics.

 

You know, I've yet to create a decent sprite animation. Mostly just stick figures that flail their limbs in a rapid, unsettling manner. A good article on sprite walk/run/jump/attack animations would be great; I've only found a few of those online, many of them involving multiple dead forum links before finding an archived post from the 90's in some forgotten corner of the internet. Bonus points if you can find out how they did the animations in high-res 2D fighters like Guilty Gear or BlazBlue; seeing the extreme end of the sprite animation spectrum compared to the relatively simple ~32x64px/~10 frame platformer stuff would provide some good perspective.

 

Seeing the "Color" entry on your list reminded me of another subject I've never quite gotten; I normally draw in pen, so when confronted with RGB/HSV sliders or color pickers in software, I freak out and start picking colors at random. Terrible colors. Some general advice on choosing palettes would be great.

Now installed monoGame, and created project, and seeing that xna is included. So it use XNA libs?

 

As I recall, they've actually recreated XNA's functionality without using -any- XNA code. Otherwise, I think Microsoft's lawyers would have a problem wih MonoGame being open source.

 

Anyway, XNA is still a great choice for 2D games on Windows-based platforms. If you want cross-platform support, or just feel like learning something new, use MonoGame. Otherwise, for the time being, there's no reason you need to switch from XNA (especially if you've already gotten started with it); it's not going to lose features, it just won't be gaining any new ones.

Sounds perfect for a small and/or indie developer; someone with a shoestring budget who can't afford programmers and artists. Unfortunately, they won't be able to afford to pay very well, either--if at all--but at least you'll know it's because they genuinely don't have the cash, and not because the execs are paying themselves much, much more than they're worth.

 

Major corporate developers like EA, Activision, or Ubisoft probably won't be interested; creativity frightens them, unless you're suggesting a creative new way to screw their customers for a quick buck, in which case they'll just take credit for the idea themselves.

 

As for your art, you're willing to post samples and ask for critiicism, so you're doing better than most. If I had to make a suggestion, I'd say you should try adding color; it's hard to read pure black and white.

What programming language? If it's C#/XNA, this example project might help. I harvested a few of it's rectangle-related helper methods for my own collision system (particularly, getIntersectionDepth() was useful).

 

Otherwise, the basic logic I've been using is as follows:

1. Find what index in the tile array the sprite is currently in.

2. Based on it's size and velocity (speed+direction), determine the range of tiles to check.

3. Create a new rectangle identical to the sprite's collision rectangle (which should be smaller than its actual frame for gameplay reasons), and move it according to the sprites velocity--but only in the X direction (ignore Y velocity for now).

4. Check all tiles in range for non-zero intersection depth; if found, move the rectangle by that amount.

5. X check is done; sprite should now be in correct X position.

6. Repeat 3 and 4 using the adjusted X position and the Y velocity.

7. Your new rectangle should now be in the correct X and Y position; set your sprite's position accordingly.

 

Can't say it's the best way, but it worked for me. Arbitrarily changing the sprite's size doesn't even break it. Doesn't handle slopes or platforms yet, though.

Thank you for book suggestions! I saw that these books: Beginning Game Programming 3rd Ed., Advanced 2D Game Development requir basic skills of C++, so what does it actually mean? Can I get basic skills just by doing some online tutorials?

It's been a year or two, and I was pretty new to programming at the time, but I remember those books being pretty bad. I spent more time searching online for corrections to the author's faulty code than I spent reading the book; you can find free tutorials online that cover the same material (and with far fewer errors).

For basic C++ programming skills, the most recommended book, according to the guys at stackoverflow, is C++ Primer, 5th Ed. You might just want to check out their whole list; it's sorted by level (beginner, intermediate, advanced, general reference). There are a lot of bad C++ books out there, but apparently 2200+ upvotes say these are the good ones.

EDIT: And the same goes to #2 it says not for beginner so how good should I be?

You probably won't need it until you have a solid grasp on C++ and have written a few simple games. It won't teach you how to make a game, just how to do so better/cleaner.

About the books: what do you think about these?
 
1. http://www.amazon.com/Beginning-C-Through-Game-Programming/dp/1435457420/ref=pd_sim_b_5
2. http://www.amazon.com/Game-Coding-Complete-Fourth-Edition/dp/1133776574/ref=pd_sim_b_4
3. http://www.amazon.com/Introduction-3D-Game-Programming-DirectX/dp/1936420228/ref=pd_sim_b_17

Never read #1, but I have a few other books from that series (Beginning Game Programming 3rd Ed., Advanced 2D Game Development--same exact cover art as #1, but a different author) that I actually regret buying. I'd suggest trying to find a copy to skim and make sure it's what you're looking for before buying.

 

#2 is great, but I wouldn't call it a beginner's book. It's really more about best practices for full 3D games, written by two professional developers based on their experiences in the field. Valuable info, but not particulalry helpful when you're just starting out.

 

#3 is, allegedly, the best intro to DirectX11 available. I hear it's also pretty intense; it spefically lists its intended audience as "intermediate C++ programmers," not beginners. I haven't actually read it yet, but I have a copy on my desk, and I'm really looking forward to starting it. Got to brush up on my C++ first, though; coming from C# and Java, C++ syntax is... frightening.

 

I'm not familiar with the Unity books, or Unity in general. As for Blender, I'd suggest finding video tutorials online; I always found those more effective than paper. Also cheaper (i.e. free). I haven't touched Blender in about three years, but I hear they've redesigned the interface to make it a lot more user-friendly.

Well, I'm fairly confident I know the language well. My problem is the actual game design and architecture. What would you recommend for that?

 

Also, any ideas for projects that I should work on?

Find a 2D Java graphics library (look into Slick2D or LWJGL) and just dive into making a game. I'd suggest something like the original Mario. 2D, a generic tile engine, basic bounding box collision. It can't be too complex, or you'll get frustrated; if it's too simple, you'll get bored. If there's a feature you're curious about, try to add it; if you can't figure it out on your own, search for an answer online. Between here and places like stackexchange, you'll find advice on how to implement almost anything, along with known best practices--following those can save you a lot of headaches, but sometimes it's better to find out why they're considered best practices rather than taking someone else's word for it.

 

You'll know you're learning when you look back at code you wrote earlier, or even the way your entire game is structured, and think it's terrible--and that you know how to do it better. That's what I assume it means when it happens to me, anyway.

Also it's not specific to a topic, but I have trouble finishing drawings and paintings. I leave a lot of sketches half-polished. The looseness of the sketch lets me see what I wanted in the image, while obscuring the elements that weren't clearly defined in my head, or that I didn't want to bother finding reference for.

 

I have that same problem with design, programming, essentially everything--once my curiousity is satisfied, that's it. I'm bored. It doesn't get finished, and I move on to whatever gets my attention next. I have a terrible feeling that I'll get the game I'm working on just far enough to see that the engine is working properly, then lose interest and never actually add any content. It's a 2D game, you see, and I have a copy of 3D Game Programming with DirectX11 (Frank Luna) on my desk, taunting me, saying "Two dimensions? Pfft. I have three. Read me." It's maddening.

 

Anyway, I bought a sketchbook today with the intention of trying to get over my phobia of drawing people. I think most of it is rooted in a fear of criticism, or some such nonsense, hence why I'll limit my practice to this one discrete sketchbook that no one but me will ever see (it's identical to several others I have, and won't stand out amongst them). Ideally, I'll improve enough that I'll no longer be ashamed of the drawings and they'll feel just like architectural or landscape drawings do--I welcome criticism with those; it's praise I can't handle. At all. ...I should probably just see a therapist.

thanks alot i will try all of thse softwares, by the way my other question do i need eny skills with drawing, cause at the moment i have no skill with painting, drawing and things,

but if it is needed for my dream job i will work really hard to learn how to paint,

but just want 2 know if i need before i dedicate hours of it. enyway thanks everyone that has helped.

In my experience, painting is a novelty that's never really necessary. I only ever did it maybe twice; it just takes too long to be useful. Drawing with pen and pencil (and sometimes marker, but those things are really expensive) is a far more useful skill, especially if you're good at sketching out the basics of your concept quickly (we always called it "rapid sketching"--I don't know if that's a widely used term or something unique to my professor). Getting good at that comes down to practice. A lot of it. As in never be without a pen/pencil and paper.

 

If you absolutely can't draw, keep in mind that 3D modeling is a completely different skill--you can be great at one and terrible at the other. I've known a lot of people who used modeling software exclusively, and a few who never even needed to touch a computer to get their point across. As long as the underlying idea is good, it can be expressed effectively in any number of ways; you just have to find the one that works for you.

 

Granted, my experience comes from an architecture degree, but I'm sure some of that transfers to game art (at least in terms of environments and basic design principles).

There's not really a reason to stop using XNA if you like it. They may stop updating it, but it still works. Otherwise, MonoGameis an open source, multi-platform alternative based on XNA so it should be easier for you to pick up.

 

I agree with this. If you're concerned about continued support (or want to develop multiplatform games), switch to MonoGame. I don't see much of a reason to use Java; the languages are extremely similar and C# has better libraries, so you'd be breaking even at best, or downgrading at worst. If you're looking for a challenge and/or are a masochist, you could always take the opportunity to try C++ and DirectX.

So my question is, is there a good action adventure engines out there that can handle a lot of custom modding or would it be easier to just plan to eventually build my own engine?

 

There's one called Torque 2D that recently went open source, I hear. Used to cost money. Comes with the box2D physics engine built in. Haven't checked it out myself, but I've seen a lot of people recommend it.

 

And no, it's never easier to build your own. It takes a looooong time. I've been working on mine for months (for a game similar to the one you want to build, except it's a sidescroller--think Castlevania/Super Metroid, but with heavy RPG elements). That's not to say there's no benefit in doing it yourself--you'll learn a lot more, you'll be sure it does exactly what you need it to without a bunch of unused/unwanted features, and it's fun, too.

My biggest concern is graphics. I have absolutely no concept of graphics and am not exactly an artistic guy. What do you do for graphics?

If you're talking about assets (player/enemy sprites, tilesets, etc.), you can either harvest some of the free stuff floating around the internet, or throw together your own "programmer art." It doesn't have to be pretty if you're just using it for testing. I've gone with the latter thus far, although I do have somewhat of an art background (Protip: don't get a degree in architecture. Ever.).
 

Of C# and Java, which would be best? (I know, I know.. the generic no language is best answer). What's positive/not-so positive about each of these languages in game development terms?

C#: XNA exists. Microsoft may have dropped their official support, but it's still great. There's also MonoGame, an open source XNA implementation, which is cross-platform if you're into that sort of thing. As far as I know, the guys behind it intend to keep going despite Microsoft's bizarre loss of interest in XNA.
 
Java: I can't think of a reason to recommend Java over C# for game programming if you're equally comfortable with both. Err... Minecraft is Java. So... there's that, I guess.

the free online repository site I'm using has a built-in issue tracker

 

Which free online repository site are you using?

Didn't want to sound like I was advertising, nor stir up a Git vs. Hg firestorm, so I didn't name names, but I suppose there's no harm in saying Bitbucket. Github probably has similar features, but the deciding factor for me was Bitbucket's unlimited free account for those with a .edu email address. As a broke grad student, I couldn't turn that down.