New developers, please read this (common mistakes)

[retlaf]

And then you might as well not be using GC at all.

There are lots of advantages to programming a game in a managed environment over C++ even above the usual "it's easier to debug" and "shorter dev cycles" arguments, such as one code-base for many platforms. The performance difference these days is generally too negligible unless you're working on fixed hardware.

Not to mention a small mistake with the GC can skip a couple frames while a small mistake with new and delete can put your game into an unplayable state.

[zaphod]

Some more notes.

"It has a lifebar and you will get hit and it's fine."

NO. It is NOT fine. If it seems fine, then the lifebar is too easy to keep topped off, and the challenge is sucked off. TO actually remain challenging, you have to either a) have enemies/attacks that ignrore your life bar and 1 hit kill you regardless, or b) put in enough undodgable stuff to wear you down so the boss is a threat again. If you do the former, you might as well leave off the undodgable stuff and the lifebar. If you do the latter, people will be in the state of "dead and not knowing it yet" when they inevitably screw up between waves of forced hits.

Good memorizer vs. bad memorizer.

When playing a good memorizer, knowledge of what is coming is a big help, but is NOT REQUIRED. Having an instakill beam coming out of nowhere and zapping the entire right half of the screen instantly is just cheap anyway you look at it.

R-type (the original) is one of the rare examples of a GOOD memorizer. Here is what makes it good.

1) There are ample clues to what is safe and what is not. Enemies don't walk on from the back of the screen when the player is lkely to be there. On level 4, a large boss comes in from the rear, and yet it's not cheap. Why? because just before said boss shows up, a popcorn enemy come sin from the right, flies up out of your shot range, then loops around and comes at you from the rear. It's not a threat, but it's a BIG clue that something will probably come from the rear, and because it drove you away from the rear of the screen you won't be there when it flies in without a lot of effort on your part. ANd if you do somehow retreat to the rear and it rams you, you feel like an idiot in retrospect. It demonstrates very early on in level 4 that the top and bottom edges are not safe if you can see open space, long before you go anywhere near them. Of course once you know the spots and timing they come in at, then those unsafe areas become safe again. The explosions that insta kill you in level 7 are colored differently from the usual harmless ones, and you are in very little danger of running into the first couple of them. By giving you clues, it turns what would otherwise be a cheap shot fair.

2) even if you don't know what's coming, death is not unavoidable on first playthrough. You can try to play it "safe" and wing it and get very far if you have good skills. But once you know what's coming, the difficulty massively drops for the first 2/3rds of the game.

Many people think that because it's a home game, they have license to be cheap, because they aren't costing people quarters. Home exclusive installments of franchises (R-type 3, i'm looking at you!) tend to be particuarly bad about this, as a way to increase longevity and make up for the fact that the player has infinite continues. But the shmup is inherently an arcade genre, and this should NOT BE DONE. I've seen this even in ports (such as Life FOrce for NES) when the cheap shot wasn't present in the arcade original.

TO checkpoint, or not to checkpoint.

Most manic shmups do not have checkpoints. You just respawn where you die, get 3 more bombs, and continue on. But checkpoints aren't inherently bad. They can force players to use skill instead of credit feeding. BUT... it should always be possible to beat the game from ANY CHECKPOINT. Sure, later ones can be harder to recover on then earlier ones, but a sufficiently skilled player should be able to pick up the controller when someone dies at one of the last few checkpoints and go on to beat the game.

On the same vein, if you are even going to allow continues, it should be possible for an expert to take over from any continue point and win. If you are going to have a continue feature, make it worthwhile to use it. This is why most modern shmups will gie you a max power item when you continue, so you can get back to playing instead of trying to scramble for scarce powerups and not die.

[BPzeBanshee]

Good god, not this memorisation curse word bullshit again.

That said your explanation makes sense. Clues are key, or otherwise sticking to convention. You don't see huge lasers attack you from behind in Raiden Fighters for example.

[nasty_wolverine]

okay, this is a language/API question:

Choices->
1) C++/Directx - i know c++ and advanced concepts, but directx is just confusing me, takes hell lot just to set up a window and that awful window msg loop, but i did go through the API quite a lot in detail.
2) C++/OpenGL/GLFW - GLFW makes the boilerplate code pretty tolerable, handles input and joystick and multithreading, and OpenGL and C++ are cross platform and fast.
3) C#/XNA - this ones just easy, getting things on screen is a piece of cake, pretty easy to get demos up and works on the 360, but the talk about the GC in above post kinda scared me now.

now, i have been sketching up some plans for a shmup with a programmer friend, and i have a pretty good idea of how its going to look inside my head, the idea is heavily inspired from Cave shooters like DOJ and treasures RS.

which choice is the way to go???

[Udderdude]

Personally I use Allegro, it's cross-platform and has built in OpenGL support now.

http://sourceforge.net/projects/alleg/

If you're going C#/XNA it's really the only way to get on XBox Indie.

[nasty_wolverine]

i cant get on xbox360, coz i stay in india and MS doesnt have indie dev programs for the country...
In todays world of global economy, they say its hard to negotiate finance exchange with the devs in India when some of the bigger name FPS, RTS and couple of other games get outsourced here for assets and porting...
bunch of BS from MS....

[BPzeBanshee]

Personally I use Allegro, it's cross-platform and has built in OpenGL support now.

http://sourceforge.net/projects/alleg/

If you're going C#/XNA it's really the only way to get on XBox Indie.

Are you using Allegro for the XOP engine?

If so (for curiositys sake), what's restricting it from a cross-platform release?

[Udderdude]

Personally I use Allegro, it's cross-platform and has built in OpenGL support now.

http://sourceforge.net/projects/alleg/

If you're going C#/XNA it's really the only way to get on XBox Indie.

Are you using Allegro for the XOP engine?

If so (for curiositys sake), what's restricting it from a cross-platform release?

I'm lazy :3

[BPzeBanshee]

[nasty_wolverine]

the lack of pointers in c# and xna being only 32bit... isnt that limiting?

(spent 4 hours trying to setup VS 2010 express C++/C# to compile 64 bit)

[Ixmucane2]

the lack of pointers in c# and xna being only 32bit... isnt that limiting?

Java does really well without pointers, and I don't see why C# should be worse. You have object references when you want reference semantics, arrays when you would do pointer arithmetic, and (assuming you have something similar to the Direct3D C++ API) efficient enough objects for 3D graphics.

And if you feel constrained by 32 bit addresses because your game needs several gigabytes of RAM, it's your fault for wasting memory.

[nasty_wolverine]

as of now i am going with SDL/OpenGL with C++, cross platform, 64 bit... (SDL neatly wraps up platform dependent stuff, but the whole LGPL dynamically link library, if not "your source code are belong to us" approach kinda ticked me off, oh well...)

wudnt scene graph creation without pointers be a pain and also cycling through things in draw methods, dynamic memory allocation isnt there in C#(or i cudnt find it), plus if things get worse throw in a lua wrapper, viola scriptable NPC's (in a shmup that wud be baddies). You can just compile a engine and write the game as a lua script...

[Ixmucane2]

wudnt scene graph creation without pointers be a pain and also cycling through things in draw methods, dynamic memory allocation isnt there in C#(or i cudnt find it)

Dynamic memory allocation is implicit: every time you write a=new B(c,d) you create a B instance in the heap. Sorry to burst your bubble, but such gross misunderstandings mean that you don't know C# well enough for a somewhat complex project like a game: start working on it only after you really learn the language.

[Ex-Cyber]

Also, if you really just want some bytes (for some reason) you can do something like

Code: Select all

byte[] myDumbBytes = new byte[524288];

Also^2:

the whole LGPL dynamically link library, if not "your source code are belong to us"

That's not how LGPL works, but it is true that it's preferable to link dynamically.

[nasty_wolverine]

okay to clear things up:

1) I have been working with C++ for 4 years now (played around with OpenGL and DirectX, and know programming from when i was 14), and C# only for 2 months.... is just that when i was going through it, it didnt look worth the trouble, the only thing i found going for it was that it works with XNA ( VC++ doesnt support XNA, MS dont want).

2) SDL 1.3 moved to Zlib license (still in beta)... SDL 1.2 comes with a precompiled dll (also easy to compile since i wanted 64-bit) and including the SDL.h header means you dont have import each function one by one, so, I am actually happy with SDL even if its under LGPL. Now if all you got was source files, which you had to compile to a dll and export all the functions, i personally wouldnt like it... (I do know that only when statically linking LGPL stuff will also mean that i wud need to make my code LGPL too, dynamically linking is fine and can be made commercial, they do this so newer versions can be installed by end-users for bug fixes and improvements)

3)

Code: Select all

                                 (object)-----------(object)--------------(object)--------------(object)---------(object)
                                    |
                                    |                                                        (object)--------------(object)
                                    |                                                           |
         (root)-----------------(object)-----------(object)---------(object)--------------(object)---------(object)

Pointers would make cycling through something similar and bigger that alot easier for me with some nifty binary tree data structure and a do while end of tree reached draw function just by passing the root pointer

just my opinion, not trying to start a war...

edit: did some research, you dont have to make your code LGPL, just have to provide source if someone wants to make changes to link to newer SDL or change your custom implementation of it...

[retlaf]

Pointers would make cycling through something similar and bigger that alot easier for me with some nifty binary tree data structure and a do while end of tree reached draw function just by passing the root pointer

C# does contain pointers: every time you declare a variable of an object (ie, non-value type variable), it is equivalent (I think) to declaring a C++ reference pointer (it automatically dereferences). The proposed tree can be achieved with this in mind:

Code: Select all

Class Object
{
  int someData
  int someMoreData
  List<Object> children   // Pointers to all the children of this node.
}

You don't have to instantiate the children inside the object: you can assign any object variables to it since they are treated as pointers.

[Sumez]

3) C#/XNA - this ones just easy, getting things on screen is a piece of cake, pretty easy to get demos up and works on the 360, but the talk about the GC in above post kinda scared me now.

AFAIK the GC in .NET runs on a different thread than your main program, keeping it from interfering with the program and cause frame drops.

Also, you CAN use pointers in C#, but there's no real reason why you would, if you're using it properly.
http://msdn.microsoft.com/en-us/library/y31yhkeb.aspx

[Deadly Red Cube]

AFAIK the GC in .NET runs on a different thread than your main program, keeping it from interfering with the program and cause frame drops.

This is somewhat accurate, but not quite the whole story, and it depends on the platform.

On Windows, the GC is generational - that is, certain types of objects can be collected very efficiently, and you frequently won't see any framerate drop from then. However, if you ever need to do a Generation 2 collection (and, sorry, I cannot remember the exact triggers), it will be a bit more spendy and use a bit more resources. However, overall, on Windows it's not such a big deal.

On the Xbox (via XNA), however, it's a different story - the GC is just a mark and sweep collector. Basically, it has to halt all threads, do a quick mark of all of the objects that are currently in use, then sweep through all objects to clear the ones that aren't in use. Then it will, generally, compact the heap to make it more contiguous in memory. For reasons that you can probably figure out, this type of operation can't be done while objects are changing, hence the need to freeze everything.

In any case, the GC is generally only triggered when new memory is allocated - that is, if you don't allocate things on the fly, you won't get garbage collection on the fly, either.

The funny thing about the focus on the GC causing performance issues in C#, to me, is that in C++, you also generally avoid allocating memory on the fly - instead relying on pre-allocated memory pools that you manage to avoid the expensive cost of malloc or new. This is the exact same technique that you can use in C# to totally avoid the GC hurting your framerate - simply allocate what you're going to need up-front and don't allocate anything during critical points of game runtime.

This is something that you should probably be doing regardless of the language you're working in

[Sumez]

Thanks for clearing that up, I was wondering how it worked on X360, which generally seems a lot more fragile when it comes to RAM stuff.

In any case, the GC is generally only triggered when new memory is allocated - that is, if you don't allocate things on the fly, you won't get garbage collection on the fly, either.

That's a little complicated with shoot'em ups though, as you need to constantly spawn new enemies and missiles on the fly. Especially the missiles seem like something that could be a little complicated to "reserve".
Any good ideas here?

This is something that you should probably be doing regardless of the language you're working in

I thought the same thing, too. Memory allocation in C++ is at least as much of a pain in the ass as keeping your GC in check. But I guess it does allow for some shortcuts if you're clever.

[Deadly Red Cube]

That's a little complicated with shoot'em ups though, as you need to constantly spawn new enemies and missiles on the fly. Especially the missiles seem like something that could be a little complicated to "reserve".
Any good ideas here?

Just make sure to make a big enough pool My project (which is written in C#/XNA) has a pool per enemy type (sized by the maximum number I'll allow, via the level design, on screen at one time - some enemies have a pool of about 3, some have a pool of 100) as well as pools for player and enemy projectiles (I think I allow a few hundred or so enemy bullets - but I'm not a bullet hell so it could be that a larger pool would be needed there).

Again, it's basically the same thing you'd ideally be doing in C++ - creating a giant reservoir of pre-allocated objects and using and re-using them. Reusing can get tricky for enemies and projectiles with more complex behaviors (I've had quite a few instances where I forgot to reset some value and enemies that were re-used ended up behaving oddly), but it's totally doable.