[Alephmodular-devel] 0.4 Planning and future

[Br'fin <br...@ma...>]

I've been making slow progress in converting all the shorts and longs  
to be a more platform neutral int16 and int32 as part of 0.3 (And  
trying to remember what other things I might like for developers in  
basic mass edits at the moment)

Anyhow, I believe my initial concept had been to settle platform issues  
for 0.4 and then settle modular issues for 0.5. And recently I realized  
that this is probably backwards. We might want to have a plan for  
platform specific issues currently, however if we do anything now, then  
we'll just be tripping over those same changes for 0.5

If we settle modular issues for 0.4, then platform specific issues  
should fall under the realm of adding new files, not rearranging  
existing ones.

Anyhow, I was musing over specific modules. And I was also musing over  
the scope of certain modules.

The main divide is between the game elements and the GUI elements. With  
most of the GUI elements being platform specific.

GUI
	Preferences application
	Main menu
	Load/Save dialogs
	Display lib
	Input handling
	Sound handling

Game specific
	Game Core
	Animation
	Rendering
	Files
	Networking

This isn't to say that Files and Networking are platform generic in and  
of themselves. But they are separate from the GUI. For instance, a game  
server would have need for files and networking, but have no use at all  
for a gui, rendering, or animation.

I do believe that these things can be implemented roughly one or two at  
a time as well.

A rough order might be
	Modularizing basic file capabilities
	Modularizing basic display capabilities
	Modularizing sound handling
	Modularizing preferences
	Modularizing gui
	Modularizing game elements
	Modularizing networking

A rough layout of the source directory might look like

source
	gui
		shared/base gui defines
		macosx
			preferences
			shell
			interface
			etc
	support
		astream
		cross platform files
			(Ifdefs within for different platforms)
	game
		monsters
		physics
	network
		ethernet
	rendering
		software

Some things to note

The CSeries code has a strong possibility of being pulled apart. Some  
parts, like macros and types should go into support. Other parts, like  
dialogs and alerts are better put into either shared gui definitions or  
left platform specific.

Animation is separated from game core. The main goal of this would be  
to let the two have separate tick counters. So a game_tick always  
happens 30 times a second. But animation could either be dropping  
frames or drawing excess frames over and above 30 frames a second and  
smoothing by interpolation. (Monster was at point X, is moving towards  
point Y, we're drawing a frame eery 1/3rd of a game tick, so we'll  
first draw it at 1/3rd the way from X to Y) From speaking with Woody  
this separation also seems like it could aid in clearer networking. Or  
at the very least would be similar to the way Doom appears to operate.  
A game server that you connect to, even if running the game locally.
This might introduce a off by one game tick delay, though this doesn't  
seem like a major problem.

I'm not sure how to separate the way the main game loop operates with  
how it might be best to implement for different platforms. I do know  
that handling input in a vbl thread has proved problematic for MacOSX.  
Specifically for Mouse input handling. But cropping up in a couple  
other ways as well in the interaction between mouse and GUI.

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------