This is the first release of ICE, a small game project I'm working on at the university.

ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows.

There's still a lot of work to do (moddability is there but no user-friendly editor, no ship upgrading, need better sounds, bosses), but at least the game is playable.

We're using a component-based entity system (where components behave as
plain data), allowing various custom entities to be created without touching
the code.

The game is pretty slow on older PC's; this is not a D issue, but some
code (graphics) is just written very inefficiently right now. It's getting
better, though; D features made it easy to write tools to profile memory
allocations and frame times; we can do stuff like find the slowest frames,
break them down into zones to find out what took the most time, even
find the allocations made during these frames. (I'd like to separate thisinto another project in future).

See the full announcement here:
http://icegame.nfshost.com/index.html

Download the game:
http://icegame.nfshost.com/pages/downloads.html

Forums:
http://iceforum.nfshost.com/


Comments/criticism welcome (I've worked on a few toy game projects, but this is
the first one that actually had a release; there are likely many beginner
errors).

On 2012-12-20 19:41, Kiith-Sa wrote:
> This is the first release of ICE, a small game project I'm working on at
> the university.
>
> ICE is a vertical shoot-em-up created with moddability in mind. Its
> gameplay resembles games like Tyrian and Raptor: Call of the Shadows.

Cool, but where is the Mac OS X binary :)

-- 
/Jacob Carlborg

On Thursday, 20 December 2012 at 19:24:40 UTC, Jacob Carlborg wrote:
> On 2012-12-20 19:41, Kiith-Sa wrote:
>> This is the first release of ICE, a small game project I'm working on at
>> the university.
>>
>> ICE is a vertical shoot-em-up created with moddability in mind. Its
>> gameplay resembles games like Tyrian and Raptor: Call of the Shadows.
>
> Cool, but where is the Mac OS X binary :)

I don't have a Mac. It can probably run on Mac OS X,
although there might be some bugs, as I have now way of testing it.
If you manage to get it to work on Mac, pull requests welcome :)

On Thursday, 20 December 2012 at 18:41:13 UTC, Kiith-Sa wrote:
>
> Comments/criticism welcome (I've worked on a few toy game projects, but this is
> the first one that actually had a release; there are likely many beginner
> errors).

Hi,

If you are making a shoot-em-up (especially horizontal or
vertical) you should be aware that the players in this space can
be quite ann... er, hardcore. There are two things in your game that they
hate with a passion: player inertia and lifebar. You might want
to remove those because this will probably backfire in
shoot-em-up communities.

On Thursday, 20 December 2012 at 20:18:42 UTC, ponce wrote:
> On Thursday, 20 December 2012 at 18:41:13 UTC, Kiith-Sa wrote:
>>
>> Comments/criticism welcome (I've worked on a few toy game projects, but this is
>> the first one that actually had a release; there are likely many beginner
>> errors).
>
> Hi,
>
> If you are making a shoot-em-up (especially horizontal or
> vertical) you should be aware that the players in this space can
> be quite ann... er, hardcore. There are two things in your game that they
> hate with a passion: player inertia and lifebar. You might want
> to remove those because this will probably backfire in
> shoot-em-up communities.

Interesting. I do play shoot-em-ups but I wouldn't call myself hardcore,
so I guess I might have missed something.
Removing/decreasing inertia might be a good idea, I see why it might
frustrate some players.

However, what's the issue with a health bar? Most shoot-em-ups I play
have one (and I'm not making a one-hit-you're-dead game.)

Is health bar undesirable because it obstructs the view?
(i.e. would a different way of showing health be preferrable?)
Or is it simply "not hardcore enough"? (i.e. player having no information about health would be better? That would make the gameplay worse in my view.)

On Thursday, 20 December 2012 at 20:40:35 UTC, Kiith-Sa wrote:
>
> However, what's the issue with a health bar? Most shoot-em-ups I play
> have one (and I'm not making a one-hit-you're-dead game.)
>
> Is health bar undesirable because it obstructs the view?
> (i.e. would a different way of showing health be preferrable?)
> Or is it simply "not hardcore enough"? (i.e. player having no information about health would be better? That would make the gameplay worse in my view.)

Well there was such "life bar" talk in shoot-em-up communities
like
http://shmups.system11.org/viewtopic.php?t=7874&postdays=0&postorder=asc&start=0
I think it has to do with hardcore players targeting error-free
runs.


I have nothing against lifebar and inertia myself :)

On Thursday, 20 December 2012 at 18:41:13 UTC, Kiith-Sa wrote:
> This is the first release of ICE, a small game project I'm working on at the university.
>
> ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows.
>
> There's still a lot of work to do (moddability is there but no user-friendly editor, no ship upgrading, need better sounds, bosses), but at least the game is playable.
>
> We're using a component-based entity system (where components behave as
> plain data), allowing various custom entities to be created without touching
> the code.
>
> The game is pretty slow on older PC's; this is not a D issue, but some
> code (graphics) is just written very inefficiently right now. It's getting
> better, though; D features made it easy to write tools to profile memory
> allocations and frame times; we can do stuff like find the slowest frames,
> break them down into zones to find out what took the most time, even
> find the allocations made during these frames. (I'd like to separate thisinto another project in future).
>
> See the full announcement here:
> http://icegame.nfshost.com/index.html
>
> Download the game:
> http://icegame.nfshost.com/pages/downloads.html
>
> Forums:
> http://iceforum.nfshost.com/
>
>
> Comments/criticism welcome (I've worked on a few toy game projects, but this is
> the first one that actually had a release; there are likely many beginner
> errors).


Awesome! Works perfect (without errors) on Arch Linux x86_64.

Did you do something special about the GC?
Does it run at all or do you somehow pool your objects?

Kind Regards
Benjamin Thaut

On Thursday, 20 December 2012 at 22:45:10 UTC, Benjamin Thaut wrote:
> Did you do something special about the GC?
> Does it run at all or do you somehow pool your objects?
>
> Kind Regards
> Benjamin Thaut

I do use the GC; however, in general, I avoid using it for anything
that gets called very often; e.g. once per entity per frame.
Code that calls the GC once per frame is not a problem.

The game entities are composed of components (disjoint in memory;
every component type has a manually allocated array of all components of
 that type, and an entity has indices into these arrays), which
are structs. When some action triggers an entity spawn (in SpawnerSystem,
one of subsystems working on entities), an EntityPrototype - (struct
of components, not yet an entity) is either reused or allocated. I preallocate
a large number of these. Once the time comes for the entity to appear in the game, components from the EntityPrototype are copied to their respective arrays.
These arrays are once again preallocated, and if they run out of space, they are enlarged. These are actually "segmented" (arrays of arrays), so I never reallocate, just allocate a next segment.

Overall, memory allocation is no longer a concern.
Actually, GC was never a problem (I always worked with the rule -
if called many times per frame, don't use GC). However, manual allocation
_was_ a problem; until I rewrote most of the code to preallocate.
The worst case I had with the GC was about 10% of total time;
now both GC and manual allocation is below 1%. Actually; just
profiled (two-level game)- GC about 0.2% ; malloc & friends about 0.4%.

In some cases I use pooling for structs that get created/destroyed often;
these usually are arrays stored within components, e.g. WeaponComponent, which might have any number of weapons. I do this in a very hacky way, using
an allocator template argument for my (custom) collections; this allocator
is generally static and specific for type being allocated.

To clarify: yes, GC runs all the time. It doesn't have a whole lot to collect, though. It'd be inconvenient to disable it as I use stuff like closures for
GUI, etc.