frob

For me:

irfanview (free, Windows) for tiny things and one-off conversion.  It is very quick.  It can handle a few batches, but tends to be too slow on anything above 30 pictures.

The Gimp for visual conversions that need touching up.  Photoshop if you are rich or at a work.

imageMagick for more serious batch conversions.  For example, on my hobby of photography I have an imageMagick script to run through all the newly imported images and create three sizes of thumbnails each with different types of watermarks and file them in various folders.

Every game is different, but when it comes to the communication patterns there will always be similarities.

Networked tic-tac-toe is probably going to be similar to networked chess.  Both are slow, turn based, with static screens.  A move can be transmitted with a byte or two.

But both are going to be different from networked pong.  Networked pong is potentially sending frequent player state change updates.  (It is not necessarily sending ball updates since those can be calculated.  Also it is sufficient to send up/down events rather than a continuous stream of positions.)

A networked First Person Shooter is likely to be somewhat similar to pong, except with more than two players and more game events.

Satharis write it pretty well.

I'm (re)learning Python, and I'm taking an Autodesk Maya and Photoshop course over the summer.

If I want to make a simple running animation,how many frames should I have? 60? 60fps

The question doesn't make a lot of sense.

There is the renderer.  The renderer displays stuff to the screen "as fast as possible".  On low-end hardware it may run at a framerate of 20 frames per second or 10 frames per second.  On very high end hardware it may be 60 or 75 or 120 frames per second.

The renderer should interpolate animations between keyframes.  

The animation keyframes are often done at 30 keyframes per second.  Different games specify different rates, so you may very well have different results.

The animation length, or number of keyframes, depends on the action being taken. An animation may be just a few keyframes long or one hundred keyframes. Our build system complains noisily when the 100 keyframe limit is reached by a new animation.  We have some animations that exceed the 100 keyframe limit, but they are rare.

With their PS4 announcements and in various interviews about it, Sony has been paying a whole lot of lip service to allowing small indie teams to put out games on PSN once PS4 is out.  They seemed to want to make a point about making the PS4 an easier platform to get in on than the 360 has been.

Here's the key.  Define "independent developers".

The definition businesses like Sony use is: "Established game companies that are still small enough to be independent of existing publishers or vendors."

The definition many beginners and hobbiests use is: "We are three friends making an indie game, the entire thing is financed with Monopoly money".

In the past, Nintendo has been the easiest for independent developers.  That doesn't mean two kids in a basement will get devkits.  It means that you could have a relatively tiny budget of a half million dollars and Nintendo was still willing to work with you.

Microsoft stole that mantle from them with XBLA.  Note that XBox Live Aracde you still needed to be a real studio with real credentials.  It is different from XBLIG where anybody with an XNA-compiled game and a few hundred bucks can submit a title.

Sony is currently the odd-man-out, requiring a studio to have a track history of large titles before entering their console space.

This is what they hope to change.  They want to re-enter the competition for the smaller studio.

I don't know if it will be enough with the pressure consoles have been seeing over the past few years, but we shall see soon enough.

Also on a side note, do you feel that the component entity system is a good one? I spoke with a teacher about it and he said it wasn't how he liked to think about things, so he didn't use it. Also mentioning that if you go to EA none of the games he worked on used this system. He wouldn't say that it was bad, he just said that nothing hes worked on has used it, because they didn't need to.

With six years at EA, all but one game engine used this type of system.

I guess it depends on your game team and engine.  There are many to choose from.

What advice could you give.

Get a good night's sleep since they are flying you in.

Get some exercise about a half hour before the interview, such as light jogging.  Just enough to get your blood flowing.

I don't believe cramming for an interview will help.  Either you are a good fit naturally (which will be proven in the first 90 days) or not.

Make sure you ask them questions.  It isn't just if they are a good match for you.  Be prepared to turn them down if they don't fit your needs.

Two maxims: Programmers should never repeat themselves, and magic numbers are bad.

Create a function to snap to a tile.  Perhaps use the signature Vector2F SnapToTile(Vector2F source) { }.

Second, rather than using the constant 64, instead use a static const int defined in a header file somewhere.

Your version will always snap to the nearest border, and perhaps someday you would rather the function snap to the nearest tile boundary.

Hi

 

Thank you for replying

 

So You're basically saying that I shouldn't worry about the number of triangles of each model and just go and purchase the ones I like - or am I wrong ?

 

What information is actually exchanged then ? - ie. it only players' position, current health, weapon damage etc ?

 

I'm sorry for asking, but I simply don't have much knowledge on this subject...

Mostly correct.

Your artists absolutely should be concerned about the number of polygons.  As part of the design of the engine you will need to figure out what your minimum spec machine will be, and roughly how many polygons you can render on that machine with your engine, and then divide by how many objects can be an a region, and then figure out your maximum polygon count and texture size based on that information.

The networking code has absolutely nothing to do with the rendering of graphics.  It has everything to do with keeping simulations in sync.  Please refer to the Forum FAQ (especially Q12) for what should actually be exchanged.

 You could also have a rendering engine for the same simulation that displays a simple unanimated box for each object.

Most advanced MMO ever.

Actually it is a realistically good part of an advanced game engine.  A simplified renderer is ideal for debugging and for running a bunch of automated tests on a single machine.  Often time the complex graphics just get in the way when you are debugging a network simulator or other part of the system.

It looks like you are correct.  I don't see anywhere in their example code that they free the memory the allocated with malloc() except in the case where there is a failure in initialization.

My guess is that they are just leaking the memory, making the OS clean up after them.

I agree it is a bad practice.  You should take ownership of your objects and manage their lifetimes properly.

Has anyone come up with a solution to this?

Ok, so a more generic version of the question: what is the best way to share the data between different classes that are completely un-related?

A singleton is something altogether different.  It says "There can only be one of these.  Ever.  So let it be written."  That is nearly always (but not universally) a bad thing.

Don't use singletons.

The preferred way to do things is that when an object needs data you will either pass the data as a parameter when you need it, or set it using a mutator/accessor pair (get/set method) at some time during the object's lifetime.

In practice you can get very nearly all the data to objects using this method.  A programmer ought to be able to go for many months without touching anything other than direct parameters to their game objects.  

Almost everything should fit this usage pattern.  

Sadly, large programs have some objects that need certain bits to be accessible on a read-only basis to other parts of the system.  It is not ideal, but in the real world there are occasionally good reasons to create a very minimal, tiny, global object that points to the canonical versions of certain factory methods.  These may include links to things like the game clock, a handle to the main simulator, or a handle to the resource manager.  These should be used sparingly.  On the rare occasion that these must be used, keep the Law of Demeter in mind.

@Tom- Did I do something to offend you?  Ever since I joined, to me (and maybe you don't intend to be this way)  but you come off mean.  Maybe it's something that I did that was wrong, but I'd like to know.

Tom is both precise and terse.

Personally I find it refreshing and useful.  It encourages people to refine their facts and just ask their real questions.  Often in the process of refinement the individuals can discover their own answers.