www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - ICE 0.1: a moddable shoot-em-up in D

reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
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).
Dec 20 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 20 2012
parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
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 :)
Dec 20 2012
prev sibling next sibling parent reply "ponce" <spam spam.org> writes:
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.
Dec 20 2012
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
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.)
Dec 20 2012
parent "ponce" <spam spam.org> writes:
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 :)
Dec 20 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
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.
Dec 20 2012
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Did you do something special about the GC?
Does it run at all or do you somehow pool your objects?

Kind Regards
Benjamin Thaut
Dec 20 2012
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
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.
Dec 20 2012
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
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.
Dec 20 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 21.12.2012 00:07, schrieb Kiith-Sa:> 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.


It is nice to hear that leaving the GC enabled did work out for you.
But basically is sounds like you are doing manual memory management 
after all.

Kind Regards
Benjamin Thaut
Dec 20 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 20 December 2012 at 23:15:39 UTC, Benjamin Thaut 
wrote:

 Am 21.12.2012 00:07, schrieb Kiith-Sa:> 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.


 It is nice to hear that leaving the GC enabled did work out for 
 you.
 But basically is sounds like you are doing manual memory 
 management after all.

 Kind Regards
 Benjamin Thaut


I believe when D's GC gets improved this would be less of a 
problem.

While working at a well known Finnish communications company, we 
ported "legacy" high throughput communication servers from C++ to 
Java and the performance was quite comparable.

--
Paulo
Dec 20 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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.


I've compiled the game on Mac OS X now and get the following runtime error:

Failed to construct a video.sdlglvideodriver.SDLGLVideoDriver: Could not 
load OpenGL: Failed to load symbol glMatrixIndexPointerARB from shared 
library ../Frameworks/OpenGL.framework/OpenGL
Perhaps you need to install new graphics drivers?
Segmentation fault

This is on a computer using Mac OS X 10.6, I'll try later on a Mac OS X 
10.8 computer.

Fork: https://github.com/jacob-carlborg/ICE/tree/osx

-- 
/Jacob Carlborg
Dec 20 2012
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Friday, 21 December 2012 at 07:54:19 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.


 I've compiled the game on Mac OS X now and get the following 
 runtime error:

 Failed to construct a video.sdlglvideodriver.SDLGLVideoDriver: 
 Could not load OpenGL: Failed to load symbol 
 glMatrixIndexPointerARB from shared library 
 ../Frameworks/OpenGL.framework/OpenGL
 Perhaps you need to install new graphics drivers?
 Segmentation fault

 This is on a computer using Mac OS X 10.6, I'll try later on a 
 Mac OS X 10.8 computer.

 Fork: https://github.com/jacob-carlborg/ICE/tree/osx



This shouldn't happen as I don't even use that extension.

It's possible that it's a bug in ICE's (outdated) copy of 
Derelict2.

I updated Derelict2 now. Can you try pulling the changes?
Dec 21 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-21 14:13, Kiith-Sa wrote:


 This shouldn't happen as I don't even use that extension.

 It's possible that it's a bug in ICE's (outdated) copy of Derelict2.

 I updated Derelict2 now. Can you try pulling the changes?


I'll give it a try.

-- 
/Jacob Carlborg
Dec 21 2012
prev sibling parent reply "Rob T" <rob ucora.com> writes:
I get a few compilation errors using dmd 2.060,

nothrow that can throw, pure that calls impure, as well as 
several warnings such as unreachable code and warnings concerning 
 safe and  trusted.

After patching some of it up to get rid of the fatal compile 
errors, this last error left me scratching my head

[Errno 2] No such file or directory: 'pong-debug'


I had to give up, but I'm still interested in getting this game 
to work, so please let us know when you manage to solve these 
problems. thanks!

--rt
Dec 21 2012
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Friday, 21 December 2012 at 22:00:27 UTC, Rob T wrote:

 I get a few compilation errors using dmd 2.060,

 nothrow that can throw, pure that calls impure, as well as 
 several warnings such as unreachable code and warnings 
 concerning  safe and  trusted.

 After patching some of it up to get rid of the fatal compile 
 errors, this last error left me scratching my head

 [Errno 2] No such file or directory: 'pong-debug'


 I had to give up, but I'm still interested in getting this game 
 to work, so please let us know when you manage to solve these 
 problems. thanks!

 --rt


Are you sure you cloned ICE, not DPong?
DPong was an older project that is unmaintained; although ICE 
reuses
some of its code.

ICE is developed with 2.060 and there're no compile errors there
(although there are some warnings due to keeping backwards 
compatibility with
DMD 2.058)

ICE git repo: https://github.com/kiith-sa/ICE

I did a grep and found some mentions of "pong" in ICE codebase, 
but
it was just comments and an outdated packaging script (which I 
removed).
Nothing that would affect compilation.
Dec 21 2012
next sibling parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
Also note: ICE does have some compile errors with git master DMD;
at least because it uses D:YAML, which has known issues there.
Bot there are no errors with DMD 2.060.
Dec 21 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Saturday, 22 December 2012 at 00:48:51 UTC, Kiith-Sa wrote:

 Are you sure you cloned ICE, not DPong?
 DPong was an older project that is unmaintained; although ICE 
 reuses
 some of its code.

 ICE is developed with 2.060 and there're no compile errors there
 (although there are some warnings due to keeping backwards 
 compatibility with
 DMD 2.058)

 ICE git repo: https://github.com/kiith-sa/ICE

 I did a grep and found some mentions of "pong" in ICE codebase, 
 but
 it was just comments and an outdated packaging script (which I 
 removed).
 Nothing that would affect compilation.


I thought I downloaded from the link posted, but for all I know I 
did something horribly wrong, so I'll try cloning directly from 
git this time. If it works, I'll post that in here. Thanks.

--rt
Dec 21 2012