Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

biznatchio: Mar 31, 2001; Buglord

Twiggy794 posted:

I've got a licensing question. I don't think I'm alone when I say that I'm pretty dumb when it comes to legal jargon. Can somebody dumb down exactly what the MS-PL and MS-RL actually do? I noticed on Wikipedia that they were officially approved by the OSI but the description of each is pretty lawyerish.

I'm asking this here because I've begun poking around with XNA and I've noticed that majority of the software examples distributed on the XNA page are licensed with MS-PL. I'm wondering if it might be a good license for my XNA games.

MS-PL:

If you distribute the source code, you implicitly give everyone rights to use any patents or copyrights you own that the code may infringe upon.
Anyone that sues a contributor to the project over a patent claim loses all rights to use the software.
Source code, if redistributed, must retain any included copyright or attribution notices.
Source code, if redistributed, must be licensed under MS-PL.
Waiver of liaibility. No warranties or guarantees are attached to the software.

MS-RL:
Same as MS-PL, but with one added clause:

If you incorporate any of the source code into another project and distribute it, you must license the files that use the source code under the MS-RL.

In summary, MS-PL is like the BSD license. It allows any sort of reuse, even incorporation into a larger, proprietary-licensed project, as long as you retain copyrights, notices, and attributions.

MS-RL is like the GPL. If you use any of the source code in a file of another project, that file of the project must be made available under the MS-RL license. It differs from the GPL in that copyrights and attributions in the source code must be left intact, even when incorporated into another project.

# ¿ Jan 13, 2008 06:38

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 03:30

biznatchio: Mar 31, 2001; Buglord

Twiggy794 posted:

I know it's been said here a million times and it's pretty tired at this point, but look into XNA. You can easily setup a 2D game in XNA Studio.

Very easily. I've been wanting to play around with XNA for a while and just got started with it a couple nights ago. Starting from scratch and no previous knowledge of the XNA classes, I've got a mostly functional side-scrolling platformer engine written. I'm surprised how easy it is.

# ¿ Jan 22, 2008 03:35

biznatchio: Mar 31, 2001; Buglord

I just saw that there were other responses since this post, that'll teach me for not refreshing the thread before typing up a reply; but I'll post the reply anyway in case its helpful:

Morpheus posted:

I've got a program that has a structure similar to this (in C#):
code:
GameObject
     |
MovableObject
     | 
   Entity
   |     |
Player   Enemy
There's a function called collide() in GameObject that is overridden in each of the objects. I also have a List that holds a bunch of GameObjects in it, but they're really Players, Enemies, and other MovableObjects, just stored as GameObjects. Now, if I get an GameObject out of the List, is there anyway to call collide() on it so that Player.collide() or Enemy.collide() or whatever is called, instead of GameObject.collide()?

Yes. In fact it's a key part of object oriented programming, so it's vital that you understand how this works:

In GameObject, declare your collide() method as virtual. In any subclass where you want to replace or supplement its implementation, declare a method with the same parameters, but marked as override. That way even if you have an object that you've only declared in code to be of type GameObject, when you call collide() it actually resolves using the real type of that instance, and calls the deepest, most overridden version of the method.

For example:

code:

public class GameObject
{
    public virtual void Collide(GameObject otherObject)
    {
       // Some general code to handle collisions goes here
    }
}

public class MovableObject : GameObject
{
    // Note that we have the option of not overriding Collide() here
}

public class Entity : MovableObject
{
    // No override here either
}

public class Player : Entity
{
    public override void Collide(GameObject otherObject)
    {
        // Player-specific collision code goes here -- maybe the player
        // dies if he touches an enemy, etc.  If you want to call the
        // Collide() that's defined on GameObject as well, you can do it from
        // here by calling base.Collide(otherObject)
    }
}

public class Enemy : Entity
{
    public override void Collide(GameObject otherObject)
    {
        // Enemy-specific collision code goes here.  You can also call
        // base.Collide(otherObject) here as well if you want.
    }
}

Then, if you have a collection of GameObjects -- some are Player, some are Enemy, some are maybe of some other class, the following code:

code:

    foreach (GameObject obj in myCollection)
    {
        obj.Collide(collideObject);
    }

will automatically call Player.Collide, Enemy.Collide, or GameObject.Collide; whichever is the one that's most appropriate for each individual object's actual type.

In fact, if GameObject.Collide doesn't really have an implementation of its own, if it must be overridden by subclasses, you can mark it as abstract instead of virtual; and it works the same way -- except you don't have to give it a method body in GameObject, and the compiler enforces that you must supply an implementation for it in a subclass in order to create instances of that subclass. Just note that if a class includes any abstract members, the class itself must be marked abstract as well; and any intermediate subclasses that don't yet provide the implementations for abstract members must also be marked abstract.

# ¿ Dec 20, 2008 03:54

biznatchio: Mar 31, 2001; Buglord

Vinlaen posted:

1) Drawing tiles with different heights. Eventually I'd like to implement a Final Fantasy Tactics system where each corner of a tile has a different height and can create sloping terrain, but I'll leave this for later since it seems much more complicated. For now I just want tiles with varying heights to create bridges over terrain, etc.

From the isometric systems I've seen, to compensate for height on a tile you basically just move the output Y coordinate up. As long as you draw your tiles back to front, you're fine as far as overlap goes.

To draw a sloped tile, calculate the points of each corner of the tile at zero-height, apply the appropriate Y offset for each point's height, then distort your tile's texture to fit the polygon of the resulting points.

# ¿ Jan 21, 2009 16:01

biznatchio: Mar 31, 2001; Buglord

Dijkstracula posted:

Which puts it on the same playing field as C# being compiled to MSIL?

Does CPython JIT?

# ¿ Oct 26, 2009 14:37

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 03:30

biznatchio: Mar 31, 2001; Buglord

Obsurveyor posted:

You can write HTML5 applications that will "just work" in most browsers(this is the subject that started this discussion), you can't really do that with C++. Javascript is the only language that has nearly universal browser support, therefore, Javascript is the best tool for in-browser HTML5 apps/games.

It's awfully telling that when asking for advantages that JS gives you in development over C++, the first thing you went to was "well it's the only option you have so deal with it" rather than actually listing real language advantages. Advantages and disadvantages of dynamic versus static typed languages is one thing, but the only reason Javascript gets the attention it gets is not because of Javascript's own inherent design being superior in any way as it is that Javascript just happened to get hitched to the most successful platform of all time. It won in spite of itself.

I'm of the opinion that every additional line of code you write and every additional developer on a project is adding to the argument against a dynamically typed language and for a statically typed one; because each line and each developer increases the pressure that the codebase's lack of any formal data modelling is going to cause the project to collapse under its own weight.

This can be worked around to some extent, but the workarounds typically employed to make dynamically typed projects more suitable at scale start to increasingly become pidgin reimplementations of what a static compiler provides for you in the first place. The type annotation comments that large team Javascript projects often end up enforcing are nothing more than non-enforced, non-validated static types. The additional unit tests required to verify assumptions made on the shapes of data being passed around end up both costing you just as much developer time to write as it would have cost you to formally define the type of the data in the first place; and continues to accrue greater required investment as the codebase continues to grow.

To put it briefly: a statically typed language's compiler is merely a very thorough automated unit test suite that, as your dynamically typed language's project size increases, your likelihood of reimplementing functionality from -- poorly -- increases. (Though, let's also be honest here -- fully unit testing your Javascript is like brushing and flossing three times a day: most people simply don't do it no matter how badly they should; and that is a significant contributing factor to the 'speed of development' Javascript enjoys having a reputation for.)

There's also the consideration that while dynamically typed languages may be faster to write in, they're certainly much slower to read and comprehend:

"Fred Brooks, [i posted:

The Mythical Man-Month[/i]"]Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.

Of course, we're talking about game development here; so it's important to keep in mind the scope of the project at hand, and unless you're creating the next AAA title, chances are you're not going to be writing enough lines of code for the benefits of static typing at scale to make themselves completely evident over the rapid iteration and ease of dynamic typing.

biznatchio fucked around with this message at 00:16 on Sep 29, 2013

# ¿ Sep 29, 2013 00:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread