attempting an actual game...

ok, fairly recently the idea popped up for attempting making an actual game
(I had long since rescended into pure technical stuff, and was feeling too
much like I was existing in a void).

if anyone has any thoughts, this might be cool.


thoughts:

rpg, sci-fi+fantasy, ...
eg: in a world where elves and other races have space travel (within the
solar system), monster battling for mysteriously present gold and items
takes place.

ok, I am more leaving the story to my brother, my task is the engine (and
art+modeling+mapping+...).
or, at least, this is if I can avoid getting too distracted by other crap.

yeah, before I had vaguely been trying for fps like stuff, but fps does not
give much motivation to put really any real effort into the "game" part,
leading to a kind of ongoing obsession with the rendering and physics in my
experience...



I will use skeletal-modeled characters.

yeah, all in all, it is my opinion that this is probably one of the easier
animating teqniques (well, apart from maybe clay and a camera, or
construction paper and a scanner).
the models are segmented (vs a single mesh), allowing changing out parts
(armor bits, ...) and also simplifying modeling (reduced need to worry about
mesh structure or vertex placement).

I am doing my own animating tools (partly because the existing ones I had
were giving me crap...). current stage is that of allowing me to pose the
models and similar, but animations/keyframing have yet to be implemented.

I am likely going to use a basic skeleton and set of animations, which will
be reused for pretty much all humanoid characters/races.

this feels rather off track, but, I need working tools at least. completely
un-animated models would just suck...


the maps will be more or less grid based, though it may make sense to allow
using some arbitrary meshes as well. partly because, my alternative is
mesh-based or polyhedral maps, and these would be more work (for my existing
stuff, I was primarily kludging over quake mapping tools for my uses,
leading to annoyingly small maps).

a grid should be a lot easier to manage absent good tools (though an actual
mapper may be implemented eventually).

likely, the engine is likely going to need to do a lot of work here (eg:
deciding how to draw tiles based on adjacent tiles, ...).
a lot of the tile types are probably going to be hard-coded as well, ...


I can probably reuse my existing physics engine, though the fact that the
worlds are tile based (and the engine was designed more for fps like games)
could pose efficiency issues (I would need to make sure the engine doesn't
do anything stupid, like wasting time doing collision checking between tiles
and whatever). luckily at least only a certain number of tiles are actually
visible, so I could effectively disable everything that is out of range
(this leaves at least a linear overhead for invisible parts of the world at
present, as disabling objects is presently done via flags...).

alternatively, I could build a mesh for the world and use it to construct a
bsp tree, but this seems pointless.


I don't know, maybe I am on the wrong track here...

but, hell, it seems more useful than sitting around worrying about the
stacking behavior of obbs and convex polyhedra...

cr88192 wrote:

> I don't know, maybe I am on the wrong track here...

Given your propensity for getting distracted and not finishing existing
projects, this one is a doozie. You're probably best off picking
something much smaller scale and much more manageable as a first serious
project.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Most men do not mature, they simply grow taller.
-- Leo Rosten

"Erik Max Francis" <max@alcyone.com> wrote in message
news:1PKdnWh7oL5afRLeRVn-tw@speakeasy.net...
> cr88192 wrote:
>
>> I don't know, maybe I am on the wrong track here...
>
> Given your propensity for getting distracted and not finishing existing
> projects, this one is a doozie. You're probably best off picking
> something much smaller scale and much more manageable as a first serious
> project.
>
yeah, keeping from getting distracted will definately be difficult.

at least, as a first step, I got the skeletal animator tool written to more
or less usable levels. was able to do a few basic animation sequences
(walking and swinging swords). in total, it involves a lot less clicking
than is needed for operating milkshape, but the need to move the camera
around is more of a hassle than in milkshape (milkshape has a 4 views
layout). luckily I at least added in a feature that makes aligning the
camera a lot less work (shift+home, snap camera to nearest 45 degrees).

as a negative point, I lack a conventional gui (nor, at present, have I even
added in a basic set of console commands).


now, for the engine, luckily most of the basic code exists allready from
previous projects, but, the world structure and a lot of the rendering stuff
is new (plus, I am doing my skeletal stuff slightly differently than in
previous projects, eg, segmented models, and using matrices as opposed to
quats for internal stuff). all this may require being written...

(matrices vs. quats, quats may be "better", but I find it easier to imagine
what is going on when I am using matrices). in any case I end up needing the
matrices anyways, but don't really need the quats, so there is not that much
compelling reason to make use of quats most of the time...

I am presently unsure whether my use of linear interpolation (followed be
"filtering" the matrix to correct length and orthogonality issues) is "good"
(as I am not currently sure how one would do spherical interpolation on
matrices).
it seems to look fine for cases < about 90 degrees. 90-180 degrees results
in noticable non-uniformity (slow near the extremes with very rapid movement
in the middle). 180 degree movements tend to go in a single jump. >180
movements go in the opposite direction.

it could be argued though that it is "reasonable" that interpolation of
signifigant changes in position not look quite right, one "should" then set
up more keyframes to correct the movement anyways.

but, oh well, I guess this shows how easily I am distracted.
having to keep get up and doing crap doesn't help. no one can apparently do
anything for themselves it seems...


but, yeah, maybe getting the basic engine crap working would be a good next
step.

maybe, even if this project does not really go anywhere, I may still get
some useful stuff from it...


> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> Most men do not mature, they simply grow taller.
> -- Leo Rosten

cr88192 wrote:

> yeah, keeping from getting distracted will definately be difficult.
>
> at least, as a first step, I got the skeletal animator tool written to more
> or less usable levels. was able to do a few basic animation sequences
> (walking and swinging swords). in total, it involves a lot less clicking
> than is needed for operating milkshape, but the need to move the camera
> around is more of a hassle than in milkshape (milkshape has a 4 views
> layout). luckily I at least added in a feature that makes aligning the
> camera a lot less work (shift+home, snap camera to nearest 45 degrees).
>
> as a negative point, I lack a conventional gui (nor, at present, have
> I even
> added in a basic set of console commands).

And this is only one of the many tools you want to build from scratch
for this project.

> maybe, even if this project does not really go anywhere, I may still get
> some useful stuff from it...

It may well, and probably will. That's probably the case for most of
the projects you've engaged in, more so even than maybe most people.
But if your goal is to end up with an actual presentable game, then you
probably need to scale back your plans to something much more manageabl
or it's very unlikely to happen, regardless of your intentions now.

One approach would be to break the project down into smaller levels that
expand on each other, so that you can get to one level and derive some
satisfaction out of it and get some use out of it, whether or not you
move on to the next level. In this particular case, for instance, you
could consider completely ignoring the character modelling and animation
before you get to a workable game system, and then consider adding that
in once you get past that phase (or at least to the point where it's
presentable). Otherwise, you're working on N different subsystems,
where if any one of which doesn't get to a usable state, then you never
have anything to show for all your work.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
The most exhausting thing in life is being insincere.
-- Anne Morrow Lindbergh

"Erik Max Francis" <max@alcyone.com> wrote in message
news:H9-dnYzWmNpZjA3eRVn-rA@speakeasy.net...
> cr88192 wrote:
>
>> yeah, keeping from getting distracted will definately be difficult.
>>
>> at least, as a first step, I got the skeletal animator tool written to
>> more or less usable levels. was able to do a few basic animation
>> sequences (walking and swinging swords). in total, it involves a lot less
>> clicking than is needed for operating milkshape, but the need to move the
>> camera around is more of a hassle than in milkshape (milkshape has a 4
>> views layout). luckily I at least added in a feature that makes aligning
>> the camera a lot less work (shift+home, snap camera to nearest 45
>> degrees).
> >
> > as a negative point, I lack a conventional gui (nor, at present, have
> > I even
> > added in a basic set of console commands).
>
> And this is only one of the many tools you want to build from scratch for
> this project.
>
yes. luckily, many other tools have been made in the past, but often with
similar issues (eg: I have never really been one to make ui's that are worth
a damn...).

>> maybe, even if this project does not really go anywhere, I may still get
>> some useful stuff from it...
>
> It may well, and probably will. That's probably the case for most of the
> projects you've engaged in, more so even than maybe most people. But if
> your goal is to end up with an actual presentable game, then you probably
> need to scale back your plans to something much more manageabl or it's
> very unlikely to happen, regardless of your intentions now.
>
maybe, but it is worth noting that this is currently somewhat scaled back
from what a lot of my previous projects were (eg: immitate hl2, ...) which
basically go nowhere (I can't even gain a satisfactorary approximation of
havok, but at least what I have will probably work for most basic stuff, so
long as I don't want stacks of objects, brick walls, ...).

> One approach would be to break the project down into smaller levels that
> expand on each other, so that you can get to one level and derive some
> satisfaction out of it and get some use out of it, whether or not you move
> on to the next level. In this particular case, for instance, you could
> consider completely ignoring the character modelling and animation before
> you get to a workable game system, and then consider adding that in once
> you get past that phase (or at least to the point where it's presentable).
> Otherwise, you're working on N different subsystems, where if any one of
> which doesn't get to a usable state, then you never have anything to show
> for all your work.
>
dunno.

actually, I was just working on getting the character modeling to a
basic/usable level, for which I think I am probably at now (the tool is
written, and a simplistic character model has been made and animated some).

as for doing it in-engine, nothing new here. this is about the 3rd time I
have written this kind of stuff (ok, not the tool though), so not that much
is new (apart from, well, using segmented models and dropping use of quats,
and using a custom file format).

prior to this, I had done my animating in milkshape (but most of my modeling
in ac3d). milkshape was giving me crap, so I figured "what the hell" and
wrote my own (most of the basic coding was done yesterday morning, followed
by getting a lot of the rest written this morning). this period was
interrupted by going to classes and sleeping. luckily, my classes are ending
soon (until next semester at least).

but, yeah, on to the engine and maps probably...
a lot is being reused, but a lot will need to be new.
many things I am still unsure about, since this project is different than my
previous ones...

> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> The most exhausting thing in life is being insincere.
> -- Anne Morrow Lindbergh

> Given your propensity for getting distracted and not finishing existing
> projects, this one is a doozie. You're probably best off picking
> something much smaller scale and much more manageable as a first serious
> project.

Perhaps the thing that he needs to do is to approach the project as
four or five smaller tasks/games. Create stand alone modules that will
eventually interact with each other. Things like character creation,
man-to-man combat, exploration, vehicle design, vehicle combat, etc.
can be broken down into smaller projects.
--
TAZ

"zircher" <tzircher@yahoo.com> wrote in message
news:1133536524.750970.223430@g14g2000cwa.googlegr oups.com...
>> Given your propensity for getting distracted and not finishing existing
>> projects, this one is a doozie. You're probably best off picking
>> something much smaller scale and much more manageable as a first serious
>> project.
>
> Perhaps the thing that he needs to do is to approach the project as
> four or five smaller tasks/games. Create stand alone modules that will
> eventually interact with each other. Things like character creation,
> man-to-man combat, exploration, vehicle design, vehicle combat, etc.
> can be broken down into smaller projects.

well, I do approach things in a modular manner, but I am trying to imagine
what I want up front (as, otherwise, I go ahead with little direction, and
sometimes accomplish things but sometimes get stuck when I run out of
ideas...). I am also trying to avoid going off on a tangent, which occures a
lot more often if I don't think of things up front.

right now, I am writing stuff for dealing with maps (basic drawing and
stuff). it is working, but there is imo a lot of ugliness with tile maps it
seems.

next up, probably adding in a controllable avatar or similar (and having the
camera follow said avatar).


vague ancilary thoughts (need to get to eventually probably):
me thinking of redoing the internal file-system stuff.
I have my old system, which has been being dragged along since about the
late 90's, and has become an imo horrid mess that I no longer maintain.
considering rewriting it, but keeping about the same external interface.
right now I am using stdio's files, which I don't particularly like (I have
to manually alter the names to reference crap in my resource directory).

also considering a resources format. deciding if I should compress the
contents.
I could use zip (would need to write the code for zip files, luckily I
already wrote the inflate code when I wrote the png loader), but the zip
format is kind of ugly.
zip is de-facto, but I am not entirely sure if this matters in this case.

I could do something custom, eg, a format similar to the pak format used in
quake1/2.
then, I could decide whether or not to compress contents, possible is
arithmetic coding and a variation of bwt (the algo used in bzip2). the code
would be fairly simple and elegant, and ratios would likely exceed those of
zip+deflate, but speed would not be as good.

then again, right now this would count as me getting distracted...

> --
> TAZ
>

In article <88e04$4390f425$ca83a6d2$7426@saipan.com>, cr88192
@NOSPAM.hotmail.com says...

> vague ancilary thoughts (need to get to eventually probably):
> me thinking of redoing the internal file-system stuff.
> I have my old system, which has been being dragged along since about the
> late 90's, and has become an imo horrid mess that I no longer maintain.
> considering rewriting it, but keeping about the same external interface.
> right now I am using stdio's files, which I don't particularly like (I have
> to manually alter the names to reference crap in my resource directory).
>
> also considering a resources format. deciding if I should compress the
> contents.
> I could use zip (would need to write the code for zip files, luckily I
> already wrote the inflate code when I wrote the png loader), but the zip
> format is kind of ugly.
> zip is de-facto, but I am not entirely sure if this matters in this case.
>
> I could do something custom, eg, a format similar to the pak format used in
> quake1/2.
> then, I could decide whether or not to compress contents, possible is
> arithmetic coding and a variation of bwt (the algo used in bzip2). the code
> would be fairly simple and elegant, and ratios would likely exceed those of
> zip+deflate, but speed would not be as good.
>
> then again, right now this would count as me getting distracted...

Every single one of the things you suggest above count as you getting
distracted, if your purpose is to complete a project - any project.

- Gerry Quinn

On Fri, 2 Dec 2005, cr88192 wrote:

> yeah, before I had vaguely been trying for fps like stuff, but fps does not
> give much motivation to put really any real effort into the "game" part,
> leading to a kind of ongoing obsession with the rendering and physics in my
> experience...
>

As a quick note, even after the source release I spent more time on
gameplay-type things (including control physics) in Quake than rendering.
It's a matter of having an active interest in such things - there're still
experiences I'd like to get round to building sometime.

--
flippa@flippac.org

Ivanova is always right.
I will listen to Ivanova.
I will not ignore Ivanova's recomendations.
Ivanova is God.
And, if this ever happens again, Ivanova will personally rip your lungs out!

In article <88e04$4390f425$ca83a6d2$7426@saipan.com>,
cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>I could do something custom, eg, a format similar to the pak format
>used in quake1/2. then, I could decide whether or not to compress
>contents, possible is arithmetic coding and a variation of bwt (the
>algo used in bzip2). the code would be fairly simple and elegant,
>and ratios would likely exceed those of zip+deflate, but speed would
>not be as good.

>then again, right now this would count as me getting distracted...

This is why using other people's libraries-- such as zlib, libpng,
jpeg libs, etc-- is a *feature*, not a bug. By using them, you get the
infrastructure in place, and quickly, and then you don't waste time
reinventing the wheel a few dozen times. Even using other people's
modeling, skinning formats will let you work on the gameplay that much
sooner.

Ultimately, this project of yours will succeed or fail depending on
whether you can actually stop this bad habit of being distracted by
any little issue that comes your way, and actually *finishing* a task
before even considering another. If your aim is to merely learn, then
knock yourself out with distractions. If your aim is to finish this
project, you're going to need a major change in mindset. Even time
spent with your blog-like postings of what you've done recently is
also a distraction. Produce results, not attention-seeking posts.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein