Progress of TopDown3D

[Michael Hartlef]

Hi Kent, Hi Petr.

I have some questions for you.

Are you happy with the progress of the TD code so far?
How much time do you wanna spend working on it (let's say weekly)?
Do you guys really wanna finish it or is it something that might get finished but if not, it is ok too?
And if you wanna finish it, when do you envision this?

Michael

[ErosOlmi]

Good questions Mike.
TopDown3D (original project) was really at good point but than something happen.

I suppose that if the intent to recover the project is still alive, the only way to finish is to define the project targets and define a credible plan.
By credible I mean a list of tasks/options/features doable now, with current thinBasic features and not something we would like to have but to have them new development is needed in thinBasic or other modules.
After that, priority number one is: stay with the plan till finish and do not add new requests only because new ideas are nice or fun or whatever (unless very important and shared by the full team).

I will be out for a week but since now I can give my support (read time) on the original TopDown3D project for what I can do for it.

To go on with it, my ideas of the possible tasks in the plan can be:


keep the project little in terms of size but be open for new image additions.
I mean, the final .ZIP do not must be more than 1 or 1.5 MBites otherwise it will be too big to get interest. But at the same time develop the code in such a way that it understand if new background images will be there and if yes, use them. This will allow development of 3rd party backgrounds and it will be easy to distribute and install: just drop into a specific directory
work on ships AI. I mean, associate a specific movement to every ship maybe using specific functions or use EVAL module to write math forulas inside ship file info allowing personalizations
game stages with final monster at every stage.
It is a classic but this create a lot of interest for the player to go on. There will be the interest to see what's next.
Stages features should be defines in external files.

As you can see, for me the list is quite short but even if short it is not easy to achieve. At the same time I think those options are very important for game like that.

So far TopDown3D was a great experience. It has been a great pleasure just looking at all the hard works Ken, Mike and Petr have done. If I can do something to revamp the project, let me know but only if the idea is to continue to a very plan-committed way and have a REAL GAME instead of a very nice thinBasic script.
Sorry since now to be so brute in my post but usually I prefer to express my ideas in open and honest way.

Ciao
Eros

[kryton9]

Well this is all topdown, it is 2 types of games in one. Instant Action and mission based. We could make them 2 separate projects and finish off the instant action relatively quickly if we go this route. It is up to Petr. I am fine with doing that. The mission based game needs lots of tools yet we need to develop and right now we are just testing out ideas.

But instant action once we specify the final plan we could wrap up pretty quickly I do agree. It would be nice to have png or jpg file support to keep the file size down for this project however. That would be the only hold up I would think.

We can see what Petr says when he gets back from his trip.

[Petr Schreiber]

Hi guys,

thanks for interesting posts!

I think topDown "Instant" could be finished quite fast.
Just in following 2 weeks I can't guarantee to be working 100% on it as I plan some more holiday activities :-[

I can see lot of "preproduction" work was done on the story version ( characters, new ships ) ... but I think it will take some time to finish it. The TopDown "Story" edition could be really nice game!

The instant version is way to go, but it will probably has nothing to do with its bigger brother, I think maybe story would be not present at all, just changing environments, enemies and AI. This way we can use most of stuff already done - models.
Goal of the game then would be just to SALAP ( survive as long as possible :) ) and achieve highest score.

So its up to you, maybe finishing instant version could be better, as I am sure you guys want to enjoy summer on other places than with eyes burned to dust from LCD :)

Kent sent me some really nice resources on texture loading, sadly they are quite binded to Delphi ( uses JPEG module for example ). Adding some nicer formats is still high priority to me, but please note that perfectly compressed image formats (JPG) won't make the ZIP with application much smaller than now, as they can be hardly compressed further.

So to answer original Mikes question, yes I want to finish it, especially as long as you guys want too :).

In fact topDown "instant" could be with current time/coding possiblities more fun, as we could play more with gameplay features ( 2D of original topDown is nothing complicated ) than spending days on writing tools.
I know how slow I am progressing with coding part of TopDown 3D, but free 3D movement and such a stuff is still quite new thing for me. So lets go old 2D/pseudo 3D way of instant action game ?


Bye,
Petr

[kryton9]

I am for finishing the instant action version and the idea of dropping any story is a good one for it and make it as Petr mentioned.

With the new commands for 2D and making a GUI, we can make it looks really cool.

I don't like any of the current player ships other than the very first one that was a conversion of the 2D Sprite.

Here is my idea on work for this, does this sound good?
Kent:
I concentrate on new models for the player.
Write a png or jpg command in delphi to use temporarily for textures
Make better backgrounds and some nice background models.
Help with anything else that might be needed.

Mike:
Music
Enemy Ships and other models he would like to make, for example backgrounds.
Input code
Splash Screens

Petr:
Game Code
New AI for ships
Effects for new stuff
GUI

[Michael Hartlef]

Mike:
Music
Enemy Ships and other models he would like to make, for example backgrounds.
Input code
Splash Screens


Kent: what do you mean with input code? What do you mean with models->backgrounds? Can you also please specify Splash screens? Just the intro screen or what was your idea?

Petr and Kent: How many different enemy ships will be needed? Also will you need different races or just the one we have now?

[Petr Schreiber]

Hi guys,

Mike, do as many different ships as you want as long as you feel not bothered with that.
My idea is to not show all enemies in one level, but to reveal them like reward for the player.

Regarding backgrounds I have one idea which is maybe wrong, please stop me in such a case: Drawing any bitmaps results in blury look in fullscreen, what about "random" space composed from primitives like stars, nebulas ... on the fly like it is done in 3D topdown ? This way we can blend multiple layers, while rendering them at resolution which will not look blurry.

It occured to me one thing for top down gameplay ( TopDown 2D ? Top Down Instant ? How we will call that ? ):
- Money system : Shoot enemies to gain money for buying new ship for next level.

My idea for player ships - 4 classes ( light, medium, strong, beast), in each 3 ships ( I know this is horrible amount of work :-[).

Player could choose if to stay with ship as long as he wants, when in mood he can upgrade. Choice of 3 ships in each class makes it more entertaining and probably better for replayablity - the ships would differ slightly in each class with positions of cannons and their powers + speed and agility.


Bye,
Petr

P.S. Mike - would it be possible to not make splash screens like fullscreen bitmaps but just smart "logo like" pictures to be placed on black background ?

[Michael Hartlef]

Mike - would it be possible to not make splash screens like fullscreen bitmaps but just smart "logo like" pictures to be placed on black background ?

Isn't it the same like hanlding particles. A quad with a texture? Or did you ment small 3D meshes for stars/and nebulars.

[Petr Schreiber]

Hi Mike,

logos - square bitmap, just not mega one :)
space - like particles, probably quads or pseudo volumetric like explosions in other demo. It would be generated on the fly, according to some "recommendation" parameters.


Bye,
Petr

[kryton9]

Wow lots of new info. I will throw my opinions in from all the new posts:

Mike:
backgrounds, was if you wanted to model something for the backgrounds, like a space station, pickups. Just if you feel creative and wanted to, I wanted to let you know I wouldn't mind. As Petr says having more items makes it more interesting as one progresses in the game. Petr, replied about splashscreens. You already made nice small banner type ones, so maybe those would be good but geared towards the instant action game.

Petr:
I am all for going away from the bitmaps as they eat up too much space. I like the idea you have to make it nice and sharp looking and small game file size.

About having 12 ships, the only problem is making them look different enough at that small scale. To have 24 very differnt looking ships is going to be tough at that scale.
Maybe having something like 6 ships, but the power of their shots could be the 4 levels. These could be upgrades they purchase, so the ship would look the same, but its fire output strength and color might change. What do you think?

Also what sort of powerups if any are you thinking about?

I think this is already a fun game and it will just get better now that we are focusing on it!

[ISAWHIM]

I am just curious...

I have a few questions, before I ask more questions...

The ships you are making, are they 2D or 3D?
If they are 2D, you can make layered sprites...
BODY, GUNS, JETS, WINGS... Separate.

Just set the position/orientation, as each would be for each level of growth. You could cheat, and just make them larger scale, or wider from the center, to give the illusion of growth also.

Once oriented, the ship and all parts use the offset of the 2D origin, plus the rotation of the relative location.

The images, if you use 256 color images, can have pallets swapped for the illusion of variation also. (Or just a simple colorize or gamma adjustment... Brighter for lower levels, stronger colors for bigger and badder.)

Remember, smaller sprites can use less color, without much loss to detail. It is the larger images which loose a lot, and it is noticed. (Not sure if you are using a separate mask, or a color mask, if these are 2D, but a color mask is better, unless you purposely reduce the bitmap mask to a 2 color BMP.)

You said size was an issue with the files... Are you making two flavors? The full-commented code, and a play-only version? The comments, variables, and functions can be reduced in a play-only version. Shorten them to no-comments, and reduce the variables and functions to unique values only...

FUNCTION Billybobjoemarie (x_val3DvectorQuadA as LONG, y_val3DvectorQuadA as LONG, z_val3DvectorQuadA as LONG, q_val3DvectorQuadA as LONG)

Turn it into...
FUNCTION f_000 (v_000 as LONG, v_001 as LONG, v_002 as LONG, v_003 as LONG, )

In the end, once zipped... All the " v_00" will reduce well. Just test the reduced code, after you force a strict format. (I never trust a "FIND and REPLACE" 100%.)

Sprites are fast, space is easy to fill with disposable sprites of animated stars. Using bitblt api you can have over 5000 moving sprites, and not even have a screen flicker. All you need is a screen-mask of the rendered content, and it can be forced to look like it is below the game. (Not sure if you are using DX or GL or API stuff for this.)

You can make the stars animated by using one image, shifted x-pos, like a GIF, based on time, with a random start cell position, and use a random time trigger to make them seem non-scripted.

Do you zoom-out as players get near the edges of the screen? Allowing a larger play field? But zooming in, when they are more near the center, allowing more refined control in close proximity, or just as a dramatic effect... like at a boss stage, or just to add difficulty in later stages. (Screen being 1024 x 768, but virtual area being 2048 x 1536, zooming or shifting around to maintain a full view. Could be a strategy if used wisely... draw in close to get precise shots, and pull away for more coverage... which would result in zoomed in, while close, and zoomed out while spread.)

Using a pallet-swap can also create power-up effects. Even a pallet shift/reassignment to give the illusion of change/glow.

If the ships are 3D and small... you only need ICON size art, (64 x 64, and 32 colors) Don't use one large file with full RRGGBB, it is a waste of space. Enemies can be modular also... thus, expandable and mergeable... 2 small wings, 4 small wings, 2 large wings, long double body, tentacles, double-cockpits, offset cockpit, single-jets, double-jets, triple-jets.

Enemy moves...
Simple swarming, attracted to a common point, without being too close to one another.
Attractive drifting, veering towards, or away as an apparent maneuver.
Kamikaze, um... does not need explanation.
Paranoid, avoiding any busy location, or pulling to an unoccupied spot.
Innocent bystander, happily darting along, without any defence or offence, just target practice.
SIN^COS, those annoying ones that follow a ritualistic path, but are still hard to hit.
Spiro-graph, Like SIN^COS, but drunk, and all over the place in odd loops.

Mode fills...
Scare mode, silence followed by a faint sound of something big...
Panic mode, massive fly-swarms of super easy to kill enemies, that don't attack much...
Hahaha you can't hit me mode, swirling around a player, or playing peek-a-boo out of fire range...
Surrender mode, purposely pulling back, allowing a larger enemy to take the front line...
WTF OMG STFU, Innocent bystanders turn kamikaze and dive-bomb without attacking...

Random madness...
Happy face bopping around... no reason, just floating around... and knocking out enemies...
Star attack... Stars vacate the background and slaughter all enemies... swarm style...
TYPE: "thinbasic" at any time... plays the "MajorTom.midi" file...
Warp to "Joes Diner"... stars blur and do the warp-speed thing... Tires squeal, and a broken intercom voice greets the players to order a thinbasic value meal from "Joes Diner"... Returns back to the game with no explanation as to why that just happened... (sound would be a nasty super reduced file, which sounds like a messed-up take-out drive-through intercom.)

That's all I can think-of off the top of my head, without seeing the game or the code.

I am sure I will find that post next, or soon...

[Petr Schreiber]

Hi Jason,

lot of nice ideas.
You can download the game here:

Download post (http://community.thinbasic.com/index.php?topic=621.0)

There is one ZIP file to download, and one patch. Download and extract the ZIP first, and then overwrite main file with new TBASIC script ( both attached to mentioned Download post )

We are currently busy with the Coding Monkey contest, so we will not add features to the TopDown in next 4 months, but to get idea you can try it out :)


Petr

[ISAWHIM]

Thanks, got it...

I had the original 3D one... I was thinking that the 2D one was, well, 2D...

I stink at that game... too many things for me to run into, and my ship seems to drive itself once hit a few times. (Not sure if that is programmed or a glitch. (Where the ship is at XY then seems to move forward, left, back, right, all by itself.)

I think there is a bug in the screen also, it keeps flashing, and whole entire star-images appear for a few frames, then disappear overlapped onto the background.

Might be a sound issue also... can't describe the sound, but it stacks and stacks and stacks, until the sound just crackles... (Sounds could use a priority and a buffer with a delay kill. Only 16 total sounds play, on the 17th sound, the oldest disposable sound is dropped/muted. After 8 sounds, the older ones should decay volume faster. Locking things like music channel to high priority on channel 1. Etc...)

Never got past stage 1, due to an inability to dodge the full-screen of random fired shots.

I would suggest that there are less shots, justified by the ships having more hits to be killed. They only fire when you are near alignment, able to shoot them, since they seem to be on a defence. (As opposed to them hunting you on an offence.)

I think the overall game-scale should be smaller. Giving the ships more room to work, since they don't use collision, and seem to all overlap due to the tight space.

The side-side movement seems unnatural. Ships don't seem to lean into the direction they are going, and they can move sideways faster than forward???

But those are just tune-issues, for the most part.

Code looks interesting. Though there is no FPS constraints that I saw. (Keeping the flow within 30FPS to a max of 60FPS, since your eyes can't see faster than 60FPS, which is also most peoples refresh frequency. 30FPS is a common low-end limit, that you notice, but it usually does not interrupt playability.)

The flow seems all reactive, with no overall primary loop. Each element seems to be X/FRAMERATE...

I would suggest, if this project continues, that a primary loop be created, to help people understand flow and flow-control better.

Function MAIN_LOOP()
get xNewTick
TrimFat = FALSE
AddFat = FALSE
Select Case xNewTick - xOldTick
Case > xFPSmax
TrimFat = TRUE
Case < xFPSmin
AddFat = TRUE
Sleep((xFPSmin - (xNewTick - xOldTick))*0.5)
End select
xOldTick = xNewTick
(Do key-state collections)
(Do Update Moves {AI and Player and Shots})
(Calculate Damage, alive?) {Player was alive last round}
(If AddFat then... do additional "Thinking", "Drawing") {Creates stuff that might later need removal}
(If TrimFat then... remove additional "Thinking", "Drawing") {Removes things that were created}
END FUNCTION

Obviously, that is not code...

But some "FAT" would be... opening more sound channels, drawing more complex backgrounds, higher detail models, fancy overlay effects, complex paths, extended space collision, extended space distance drawing, 1/2 moves...

Removal of those items, just removes the lowest priority functions from being parsed in the loop, or sets them up for a decay/removal, or lowers values to shorten thinking loops.

The main loop is also where you would use a "CASE" with a counter... Use key-frames for updates to the GUI, if there are 4 GUI elements, all 4 should not update at once, every 1/30th to 1/60th of a second. Each should be set to a CASE value. Each 1/10 second, that control updates and only if there is a change in value.

A @ 1.10 sec
B @ 1.20 sec
C @ 1.30 sec
D @ 1.40 sec

Looks like ABCD all happen in the same time, and using CASE is faster than 4 seporate IF THEN, on a heavy loop.

[Michael Hartlef]

What system do you run it onto?

[ISAWHIM]

Oh, sorry...

WinXP SP3

But I have wide-screen resolution, not sure if that has any impact. (1280 X 800) Run in full screen.

I think the flashes are "Lightning". Just a little over saturated when it hits the screen as a whole. (Usually space doesn't light-up, and the blackness going to grey looked like a graphical glitch.)

Though, I am still seeing the double-layer of stars, overlayed at random times, for random lengths of time.

The sounds, I believe are impact sounds... I get hit a lot, so the sound just gets overlapped and louder and begins to crackle. Could be the lower MP3 encoding. (Saves space, but gives a performance drop, since it requires additional processing to turn into PCM. Are you using standard encoding or progressive? Might help to pre-render the MP3 to WAV once loaded, and keep the WAV memory handle for playback. I am not sure which BASS likes better for streaming.)

The background music could also be pushed to windows, since it does not change much, and would free a mixing channel for active sounds.

While you guys are busy doing the contest, I will see if I can offer anything productive to this, while it awaits your return. If not, I may just try to make a pong-game, to show you some of the things I suggested. (This way I am not defacing your property while you are not around to smack me around for going too crazy with it.)

P.S. I already broke my copy... (Not sure where, but now I die 10x faster.) I was converting some of the formulas so they used (Z * 0.5) instead of (Z / 2), which is faster. (I think I know where I messed-up, where there was a more complex formula, with "i" in it... that was something like, (Z/4+i*X), but I converted it to (Z*0.25+i*X)... Should have worked... But I guess that one didn't. Maybe it did, and I just got worse at playing.

I also moved a few lines of code, to reduce the file-reads, where the backgrounds were loaded.
FOR i = 1 to 3
xFILE = OPEN(...)
xFILE = CONVERT(xFILE...)
xVALUE = Somecode...&i, more code
NEXT

The value of the paths did not use "i", and the file was read all three times, with the same values.
So I did this...

xFILE = OPEN(...)
xFILE = CONVERT(xFILE...)

FOR i = 1 to 3
xVALUE = Somecode...&i, more code
NEXT

That kept only the code that changed with "i", in the loop, but it only reduced file-reads from 3 to 1, and 3 conversions to 1 conversion. (Was only at a loading stage, so it did not actually gain any performance, possibly slight faster loading, by a micro-second.)

There is a couple of spots, where things are continually divided by the TIMEFRAME, which would greatly help speed, if they were translated only once per loop, and the values simply used, as opposed to calculated over and over in the loops.

[ISAWHIM]

Nope... not lightning...

I am seeing...
A background of stars and a nebula...
A sub-background of more stars (Doubled-over, 2 more images.)
A flashing foreground with the same nebula, but offset.

Occasionally, the images seem to continually overlay, adding themselves together. Brights get brighter (Which I thought was lightning. But looks like windows media player visualizations... layering and layering, getting brighter as they move.)

On some occasions, the whole screen just resets to a normal playing field, like when I first start the level. Only the one moving background.

[ISAWHIM]

Ok, it wasn't my code changes that made it do that...

At first, I get hit... 6% damage...
next, jumps to 36%...
next, jumps to 78%...
than death...

(Actually hit a few times in that progress, but the longest I can last with a screen full of shots is about 5-10 seconds.)

Instant, is a little too instant... no real time to get fingers ready on the keyboard before getting pummeled with ships. I look up after hitting enter, and BOOM, instant action/death.

BTW this is the ALPHA 3.0 that I am playing from the link above, on version 1.6.0.10 thinAIR/thinBASIC.

[Petr Schreiber]

Hi,

thanks for your impressions.
Could you please do the following?:

Run script from here (http://community.thinbasic.com/index.php?topic=668.0) to detect your graphichardware
Run DxDiag ( Click the Windows Start button / Run / DxDiag ) read DirectX version and have a look at tests related to sound system
Attach screenshot demonstrating issues


Regarding difficulty ... yes, it is high :) The trick is to avoid shots from the blue aircraft, they have more impact and their bullets are less visible.
I think that each 100 points of score recover your damage. So you need to find balance between defensive and offensive style of game :). It needs practising to go high with score.

Regarding graphic performance - this game can be slower on low end, as it does fullscreen blend. In such a cases I recommend running the game windowed.


Thanks for your input,
Petr

[kryton9]

I personally found the new version too hard and busy for my tastes. I run an older version of the game.

I should mention that TopDown3D the story version is on hold till thinBasic and tbgl are more developed. Both have come a long way since the first topdown. The new commands being developed for the Coding Monkeys Contest will go a long way in getting us closer to what is needed for the big version. Perhaps in another year we will be perfectly setup to pick that back up.