next »

[astrofra]

ASTLAN
(Astro Lander)

PROJECT RESTARTED - JAN 2017  

Astlan is on Steam/Greenlight, click here to visit my page.

Hello,

Here is my new game project, I would be happy to have a feedback from you guys.
It is a rather simple mix of 'Lunar Lander' and 'Gravity Force' where the player will have to search & find for a list of items in order to complete each level.

So far I've been trying to define the ideals controls to make the game fun on a tablet/smartphone, hence the two buttons control.

At the moment there are 24 levels (some of them are unfinished...). After you finished all the levels, the game might quit (or crash? ).
Feel free to test it, and report anything that annoys or inspires you

Win32 and Android(2.3.1) binaries to download & try / v0.9.0

To control the ship use the keyboard :
The Left/Right arrow keys will control both left & right thrusters. Both keys pressed simultaneously will thrust vertically.

Platforms planned (so far)
 - Windows
 - Android


(updated) Title Screen


Android (draft) Version


(v0.2.7) Aquatic level, lasers & various pitfalls.


(v0.1.9) Video capture if you can't/don't want to launch the game.



Todo list:
 * Update the toto list.
 * IMPROVE THE DAMAGE EVALUATION.
 * Add visual hints (arrow?) when the player is close to the next item.
 * Change 'Damage' to 'Health'.
 * Implement an uv-based animation class, to display animated 'sprites'.
 * Add a visual feedback when the player grabs an item.
 * Implement a system of 'Achievements'.
 * Add some sfx.
 * Implement a minimap with the position of the player & items.
 * Keep track of the player's performance in a file.
 * Create new levels.
 * Implement a level editor.

Change log:


V0.6.2
 * Added and Normalized a dozen of audio tracks
 * Improved the touch/click reactivity of the main GUI
 * Write a few common function to create UI buttons and ultimately refactor the existing UI code
 * Added a “Pause Menu” when in-game. Works perfectly and stops the game completely (display, stopwatch, physics, particles and whatnot)
 * Fixed an inconsistent design in the score calculations
 * Renamed a dozen of scene files and their respective classes
 * Fixed a nasty frame skip issue.
 * Added an end-of-level screen that counts points & bonuses.
 * Added a set of 6 illustrations that tells the main story to the player during the game.
 * Added a new kind of deadly trap : green slime on some walls.
 * Optimized a lot of visual & physic elements while targeting the Android build.


V0.3.1
 * New title art.
 * Added a main menu, with level selection & basic options.
 * Basic save/load game state routines.
 * Mouse cursor when playing on a PC.

V0.2.7
 * Moved the minimap.
 * Added a visual feedback when the player hits something.
 * Added half a dozen of levels, tweaked & improved the existing ones.
 * Changed the 'damage' display to make it clearer.
 * New type of environment (aquatic levels).
 * Added a 'bitmap to level' routine that creates a level from a simple PNG file (un-used so far).
 * Added a few mobiles obstacles (lasers)

V0.2.0
 * Added a minimap with the position of the player & items
 * Added a visual feedback when the player grabs an item.
 * Added half a dozen of levels, tweaked & improved the existing ones.
 * Changed the 'damage' display to make it clearer.
 * Added a 'bitmap to level' routine that creates a level from a simple PNG file (un-used so far).
 * Added a few 3D assets (columns, trees...)
 * Added a few mobiles obstacles (rotating barrier, rotating cog, hatch)

V0.1.7
 * Added a stopwatch, for a future scoring purpose.
 * Refined the damage evaluation, using the incidence vector of the collision.
 * Shield bonus, that protects the lander from collisions during 5 secs.
 * Added a rotating barrier.

V0.1.6
 * The controls can be reversed, (left = left, or left : right), via the main menu.
 * The auto-align routine is now enabled all the time, less stress for the player.
 * Camera is now (un)zooming automatically, according to the action.
 * Background update (temporary stuff).
 * Level 3 (unfinished).

V0.1.5
 * Win condition implemented, can now go to next level.
 * Two test levels fully working.
 * The player can now grab a fuel supply.
 * The amount of artifacts is now displayed in the HUD.
 * A small compass/scanner helps the player to find the artifacts.

V0.1.4
 * Implementation of 2 death conditions (no fuel, damage)
 * Win condition partly implemented

V0.1.3
 * Implementation of the state system to handle the different phases of gameplay
 * Collision sfx

V0.1.2
 * Camera motion if now framerate independent
 * Thrusters sfx
 * Placeholder intro music
 * Fuel & Damage are now displayed in the HUD



Any feedback and critics will be much appreciated.

[Giaddon]

Hey astrofra!

I spent a few minutes this morning playing with this.  So I assume the "auto-stabilizer" is that the ship automatically returns to it's upright position? 'Cause that worked! The controls felt good to me -- maybe even TOO good, considering that struggling with the controls is the main player interaction with this kind of game.

In any case, I was pretty easily able to get the ship to land where I wanted it to. So it's much closer to accuracy right now than frustration.

Good luck!

[Ninomojo]

Hey Fra

To me it's difficult to judge the controls because there is no goal to achieve. If there was a clear goal of say, "don't touch the walls" or "land on the marked spot without bringing your ship's shield to zero", then it would be easier to say whether the controls allow you to do that with a fair amount of challenge.

But for now, the "stabilizer" works, and I can feel it removes some of the "frustration" that there could be already. But why are you talking of frustration right from the start? Frustration is a bad word and a bad thing. It should never emerge from your controls, it should never be there. In the ideal game, if the player fails, they should not feel frustrated about this ("unfair"), they should understand why they failed and the challenge is fair (even if it's freaking hard).

As usual with game controls, I think you should design them on their own in an empty or almost empty level, until they feel really nice and fun (they're already pretty responsive which is cool). Then when you're set on the controls you design levels AROUND those controls. A concrete example in your case: If in your game touching walls is bad, then there's probably a certain width of passages below which you probably shouldn't go. This width is going to depend on the controls. If your ship is super fast it will be impossible to play if everything is narrow, and reversely if your ship is super slow, it will be boring and un-challenging to play if everything is wide and large.

So first question, what's the goal of the game?
- is it to land safely anywhere?
- is it to land safely only on a give spot? (and you lose if you land somewhere else)
- is it to race to the exit without dying?

The answers should affect your controls, I think.

[Ninomojo]

Also, touch controls for tablets are something very specific that will (should) affect your game design. Ideally your game is built around them, it's not made in a arbitrary way and then "let's just change the controls for touch".

If you want to do this on a tablet, I would advise that you do the touch/motion controls first, and now.

That is, unless "touch /motion controls" for you is just displaying HUD buttons on the tablet to mimic the keyboard.
(*cough* lame *cough*)

[astrofra]

So I assume the "auto-stabilizer" is that the ship automatically returns to it's upright position? 'Cause that worked! The controls felt good to me -- maybe even TOO good, considering that struggling with the controls is the main player interaction with this kind of game.

Thanks for taking the time to test it and report your experience
As you and Ninomojo stated, there gameplay was not clearly detailled (if not detailled at all), so it's not obvious to say exactly whether the controls are relevant or not.

This is the next step on my todo list :
- Implement a basic HUD
- Display the FUEL & DAMAGES
- Implement the death conditions (to be refined)
 * Out of Fuel
 * Out of Time
 * Critical damage
- Implement an inventory, so that the player can grab the artefacts/items as told by the level's mission.
- Implement a victory condition : all items where successfully grabbed.

After that, it should be easier to :
 - Tweak the controls
 - Test & design some level patterns.
 - Get some feedback from the amazing TigSource community.

 

[astrofra]

But for now, the "stabilizer" works, and I can feel it removes some of the "frustration" that there could be already. But why are you talking of frustration right from the start? (...)
If your ship is super fast it will be impossible to play if everything is narrow, and reversely if your ship is super slow, it will be boring and un-challenging to play if everything is wide and large.
(...)

Well, my main concern is that, when adapting an old (early 80's) game concept to a recent hardware, it is important to adapt the context as well. As in nowadays flying vehicles (airliners, drones, toy-quadrotors...) I didn't want to player to mess with the roll axis.
That question is typically down to the onboard computer, so that the pilot can focus on controlling the direction & speed.

That's what I meant with frustration : what could experience a player when the lander is upside-down, whereas most of modern aircrafts are able to avoid that automagically

Regarding the need of settling on a clear set of end/victory rules, you are perfectly right. This is on my todo list, before anything else (see above).

As for the iPad question ... well, this is most theoretical so far. But the final controls is definitely a 'two buttons'. The player controls the left & right thruster, period. No accelerometer, no emulated directional cross

Thanks for the great feedback !!!!

Btw, there's a new binary online :
 - Less gravity, less thrust power.
 - Particles to make the thrust visible (should help the player)
 - Controls are now Left/Right arrow to control both left & right thrusters

[Ninomojo]

Hey there François !

The two buttons only controls are MUCH more interesting! (not to mention perfect for touch controls too). I say you're on to something.

Now of course it's a bit slow and boring as is, but with this simple control scheme you're in for a fun little game if you tweak thrust and gravity well and the levels are interesting.

(Boy, isn't that "10%" at the top of the thread optimistic )

[astrofra]

The two buttons only controls are MUCH more interesting!

Thanks. The two buttons control was suggested to me by Emmanuel. And yes, it's definitely more appropriate.

(Boy, isn't that "10%" at the top of the thread optimistic )

Errr. Yes. I lied. Except if I keep my original idea of doing one mini-project in one month.

[Naufr4g0]

I think the two thrusters should be a bit inclined downwards, so the ship could receive a boost upwards every time you press a button.
I like a lot the controls in Uchuusen (http://www.afroboss.com/)

[astrofra]

hey Naufr4g0 !

Gosh, I really love this game. Ha ! Amazing !
Regarding the thrust that could be more vertical, I tried at first, but then, the Lander keep flying upward way to much. The solution would be to increase the gravity, but then it's less a Lunar Lander than a Gravity Game.

But it worth to mention, definitely. I need to explore that.

[Naufr4g0]

hey Naufr4g0 !

Gosh, I really love this game. Ha ! Amazing !

I'm happy you like it. Chris Nimmo is happy, too!

Regarding the thrust that could be more vertical, I tried at first, but then, the Lander keep flying upward way to much. The solution would be to increase the gravity, but then it's less a Lunar Lander than a Gravity Game.

But it worth to mention, definitely. I need to explore that.

You could also use a vertical thrust independent from the others, located below the ship.
I think would be useful to give to the player a chance to brake the ship when is falling too fast.

[astrofra]

Graphic update.

I'm re-defining the atmosphere of the game, going to something more 50's SciFi...  
This is the look of the Lander...)-, not textured yet. It's a ship with 3 thruster, and a glass tank with a brain in it.

[astrofra]

Quick update, screenshots of the in-game result

[astrofra]

Update :
 * Levels are working, the player can die or win.
 * Physics are rather OK.
 * Sounds are partly implemented.

Here's a video capture :
The gameplay seems a bit laggy, mainly because of FRAPS, running on my laptop, and recording the video to disk :p



More on the first post of this thread, above

[astrofra]

Hi Tigers,

I just re-upeloaded a quick update, with an additional routine that zoom/unzoom the camera, according to the action (mainly based on the ship acceleration, actually).

I would like to have an overall opinion about the whole thing, how it feels, is it controlable, too fast, to slow ?  /

[Ichigo Jam]

I played v0.1.5 yesterday, and 0.1.6 today. I found you'd already addressed the main things I was going to complain about! (The reversed controls and the zoomed-in camera)

So good work on that; the game is quite pleasant to play now and I like the art style!
I found the overall pacing worked nicely - slightly laid-back rather than very arcadey.

Just some minor niggles:

I think you could make the default camera zoom a bit farther out though, or add some sort of map. Currently it's kind of hard to get much feeling about the overall layout (although I'm sure a part of this is the current repetitive scenery graphics.)

When travelling at high speed, the camera lags a little which means your ship gets closer to the edge of the screen in the direction it's travelling. Which is kind of the opposite to what you want when you're playing.

The damage level for hitting things feels a bit off - I think you're using the total speed of the ship to calculate damage, rather than the component of the velocity that is perpendicular to the surface. More importantly, there isn't enough feedback to the player as to how much damage they're taking. (Oh, and using a damage bar rather than a health bar makes it quite hard to tell how close you are to a game over.)

[astrofra]

Interesting !
I knew that people could go crazy with the reversed controls, so I hurried up and fixed that.

It works better, indeed.
I'm happy to read that the pace actually appears as a good compromise.

You comments about the formula used to evaluate the damage is incredibly relevant : I spent the whole week to find a correct formula based on the speed, 'trying to avoid the classic dot product between the 'collision_normal' and 'velocity' (as I'm not that comfortable with it ).

I'll have to get rid of this crappy formula, and do what you suggest.

Good remark about the 'health' VS 'damage' bar.
Thanks for all these constructive comments !!!!!

[astrofra]

A small update, with a few gameplay elements added (stopwatch, mobile obstacles, shield...)
See the details here -> http://forums.tigsource.com/index.php?topic=20609.0

[astrofra]

Late update

I worked on a minimap. Currently, only the shape of the level appears on the map, but it will be easy to add the location of the artifacts, bonus, the current position of the player and such...

This map is automatically traced by the game (a double for() loop with a series of raycast...), so that I won't have to touch the maps manually each time a level is updated.

[astrofra]

'Started a new one this morning



This minimap made me realize how the level really look like. I definitely love this 'cave' atmosphere. Besides, I might help the player to identify the level rapidly, even more than the name of the level itself (that I should swap with the artifact counter, btw).