Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411196 Posts in 69314 Topics- by 58380 Members - Latest Member: feakk

March 19, 2024, 02:30:27 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsEL AZOR 1bit (Playable Build)
Pages: [1] 2
Print
Author Topic: EL AZOR 1bit (Playable Build)  (Read 7700 times)
fingerman
Level 1
*



View Profile WWW
« on: October 27, 2015, 07:37:39 AM »

Hi fellow TIG posters, welcome to the once again revamped
TIG FORUMS DEVLOG

There is a playable build out now in APRIL 2018. Unbelievable.



Download it for pc and linux from gamejolt:
https://gamejolt.com/games/azor/332788

Or from the Google Play Store for Android:
https://play.google.com/store/apps/details?id=com.hawkwork.azor



GAME CONCEPT
The emphasis of EL AZOR is on jumping around evading traps and slicing up enemies with different attacks. Allthough there are only four buttons in total (left,right,attack,jump), there are a variety of moves which can be performed with button combinations. The simplest example is that depending whether you tap or double tap the attack button whilst standing, the goshawkman stabs or swings his sword. But there are also roundhouse swings and slide stabs and hawk beak kill drops... All in all the gameplay should let you feel like a superhero who uses his wall jumping skills to prey on his enemies.

The art style is kept simple with just 1 bit per pixel.



TLDR
  • loads of attack and jump move combos
  • simply 4 buttons (left, right, jump, hit)
  • 1 bit per pixel art style




WHO THE HECK IS EL AZOR

The hero of the game is called EL AZOR. He is the goshawk man or rather a bloke who thinks that he's a hawk and jumps around in a tattered cape wearing a bird mask and stabbing people. His origin is as a black and white (1 bit) comic character who gives kids good advice in spanish. Anyway, suffice to say: EL AZOR is a thing.


DEVELOPEMENT

EL AZOR is being developed in Java with LibGDX for desktop and handheld versions. That being said, I hope it is obvious that this isn't intended to be another Google Store moneygrabber! I am just a hobby developer determined to finish this game. My Previous attempts at making games were too ambitious or boring to ever be released.

THUS FAR

As it stands there is a working version with a controlable player character and a few enemies that you can slice up. Most of the work has been to get the collisions and controls for the movement and attacks right. I haven't hooked it up to a gamepad yet, using the keyboard of my old laptop is okay but especially the handheld version with the touchscreen on android feels snappy.


OLD WIP GIFS
proof of concept
jumping over a hidden trap


Thanks for checking out the post! Toast Right
« Last Edit: April 11, 2018, 11:00:39 AM by fingerman » Logged
Esti
Level 0
**



View Profile WWW
« Reply #1 on: October 27, 2015, 03:37:28 PM »

Loving the 1 bit style.
Logged

Music Producer
fingerman
Level 1
*



View Profile WWW
« Reply #2 on: October 31, 2015, 01:05:40 PM »


EL AZOR has had a small update. The resulting changes can be seen in action in this GAMEPLAY GIF (3.05MB).

Reading a sign, activating a hidden spike pit, attack sliding, jump stabbing, taking damage on spikes and bleeding Evil

HUD
I was originally in favour of not having lots of numbers and status bars on the screen, especially as the screen is not very large. Games where for example the health was reflected in the appearance of the player character allways had a certain nifty appeal. By this I mean for example the power glow of the armour or maybe the stoop of the character. Mechanical player characters often take visible damage and start pluming loads of smoke and spraying sparks. This also has the advantage, that the player does not have to take his eyes of the action to look at a status bar in a corner of the screen.

Due to the graphical restrictions and again the small screen unfortunately nothing elaborate is possible here. At one point i experimented with decreasing the size of the viewport to reflect a decrease in vision and strength as the player character takes damage. This proved detrimental to gameplay however. I also tried decreasing the runnig speed and jumping height, same story... What has been implemented, is that the goshawkman spurts blood when injured and more blood when severely injured. This isn't visible enough however, so I needed something more.

The result is a depiction of the face of el Azor the goshawkman's face in it's various states of wellbeing reflecting the health. The obvious comparisson is Doom, I guess. This way the player does get to see a bit more of the goshawkman. Lets face it, the head is only about 9 pixels on the player character jumping around and you cannot see a face. So apart from the health some more information about the character of the grim or dogged mindset of the goshawkman is conveyed!

There is also a score counter which keeps track of the ammount of loot* plunder which you have gathered.
*I think the word loot originates from the British conquest of India which took place much later than the Middle Ages, haha.

Message Boxes
The game isn't intended to be especially story heavy, nontheless sometimes information has to be conveyed to the player in text form. This may include hints and warnings or an explanation of an objective or whatever... So there are now message boxes that can appear when the goshawk man goes near trigger objects like the signpost in the screenshot. The message poxes dissapear again if the player character leaves a slightly larger area around the original trigger.

Non Visible Changes
(Note: I am using Java...)
An important change that is not visible however is that I implemented object pooling for the objects where it makes sense. Basically objects which are not needed anymore are put pack into a pool and reset after use instead of cutting all ties or losing all references to them. Then when they are needed again, they can be reused.

This change had to take place as on the PC version the garbage collector was working fine and I could just create loads of ojects, but on android this was a whole different story and the garbage collctor was taking too long and causing crashes. Objects where it makes sense to pool in EL AZOR: all the particles and effects i.e. blood and dust and explosions... as well as the powerups and hitboxes and shots. You probably understand sorry.

Thanks for taking an interest, if you made it this far! xd
Logged
fingerman
Level 1
*



View Profile WWW
« Reply #3 on: November 10, 2015, 02:50:35 PM »

Hello,

apart from the revamped intro post, here is another update.

A spike ball trap, pouring 1 bit rain and a death vignette. But why doesn't he fall?

Wall jumping and slashing bats whose remains fall off the screen.

Slide to evade the dropping rocks and wall jump up to that leaver.




EFFECTS
There are now effects like the rain or the or the circle that closes around the player character when he dies. (And he didnt fall down on the ground for some reason??? Need to take a look at that.)

SPIKE BALL TRAP
Say no more.

SHADERS
LibGDX uses OpenGL 2.0 by default and allows you to use your own shaders written with the GLSL shader language. A very visible change which makes the display look more interesting and plays into the fake more retro than retro vibe.
(Why did the hipster burn his mouth on the pizza? Because he ate it before it was cool. Waaagh!)

Ok, I have seen that some people have had a look at this devlog, so thanks again for reading!
Logged
RunoverSnoozer
Level 0
**


View Profile WWW
« Reply #4 on: November 18, 2015, 02:38:31 AM »

Hi
This look cool. When i look at the gifs it feels like its rendered on a large sphere.
Mybee its the dark corners make that illusion. bird eye view ?  Smiley 

Nice rain!

Logged

fingerman
Level 1
*



View Profile WWW
« Reply #5 on: November 19, 2015, 02:25:04 PM »

Hello RunoverSnoozer,

thanks for taking an interest! Beer!

Quote
This look cool. When i look at the gifs it feels like its rendered on a large sphere.
Mybee its the dark corners make that illusion. bird eye view ?
ok that's a bad pun Grin but seriously, the effect is not just done with the dark conrners on the screen. There is also a vertex shader at play which changes the positions of the corners of the sprites being drawn. It is meant to represent screen curvature like on old terminal screens or tvs. A mate of mine really disliked it and asked what I had done, so it will be an option that you can turn off I guess...
Logged
fingerman
Level 1
*



View Profile WWW
« Reply #6 on: November 22, 2015, 01:33:51 PM »

Hello fellow TIG posters,

here is a further minor update to EL AZOR:

LIGHTING EFFECT
This lighting effect which allows different light sources to have positive interferance and flicker is a very visible effect. This is also the reason why it could be potentially detrimental to gameplay when overused and the player can't see anything that is happening. This effect is definitely not intended to dominate the whole game or be incorporated into some kind of stealth mechanic or anything, just to add some atmosphere in some short stages.

The light sources have positive interference and flicker slightly.


TECHNICAL
The lighting was not realised using shaders, it is rather based on a system of pre created sprites of concetric filled circles with different alpha values. The Pixmap class in LibGDX comes in handy which allows you to draw sprites in real time. Then the alpha is inverted and converted into pixels with what is essentially a shader but not in GLSL shader language.


Sadly, there is an annoying thing that happens when you attempt to draw filled circles with different alpha overlapping and blending in the Pixmap class: unwanted lines appear for some reason! I don't know why... So I worked around this, by pre drawing seperate pixmaps of the concentric filled cirlces with different alpha while blendind was deactivated, only to activate blending and let these pre drawn sprites be drawn overlapping (to get the positive interference of the lights intensity). This was also good for the performance, I still have 60FPS with this effect.

Ok, thanks for reading and take care!




Logged
RunoverSnoozer
Level 0
**


View Profile WWW
« Reply #7 on: November 24, 2015, 02:25:31 AM »

Hello RunoverSnoozer,

thanks for taking an interest! Beer!

Quote
This look cool. When i look at the gifs it feels like its rendered on a large sphere.
Mybee its the dark corners make that illusion. bird eye view ?
ok that's a bad pun Grin but seriously, the effect is not just done with the dark conrners on the screen. There is also a vertex shader at play which changes the positions of the corners of the sprites being drawn. It is meant to represent screen curvature like on old terminal screens or tvs. A mate of mine really disliked it and asked what I had done, so it will be an option that you can turn off I guess...

Ahh, i liked the effect at least as GIF but maybe when you play the game its disturbing. So the option is not a bad idea.




Logged

skaz
Level 2
**



View Profile WWW
« Reply #8 on: November 24, 2015, 08:08:26 AM »

I really like the old game boy feel of your game! One thing that bugs me is the jumping, there is no visible impulse, like the character just starts flying. Maybe a faked impulse could make it look more natural? Nothing modified in the behaviour, only modification in the sprite.

I had the same problem in a project of platformer I dumped, I could link you to a visual explanation if you are interested.

Keep up!
Logged

LOST FORTRESS site! 2d action adventure exploration in an abandoned Dwarf fortress, overrun by weird slug-like creatures.
fingerman
Level 1
*



View Profile WWW
« Reply #9 on: November 25, 2015, 09:24:31 AM »

I really like the old game boy feel of your game! One thing that bugs me is the jumping, there is no visible impulse, like the character just starts flying. Maybe a faked impulse could make it look more natural? Nothing modified in the behaviour, only modification in the sprite.

I had the same problem in a project of platformer I dumped, I could link you to a visual explanation if you are interested.

Keep up!

Hi skaz, thanks for your interest. I also read your comment in the GIFS thread. As regards the jumping: Yes please link me to an explanation.
I wan the jump to be super responsive, i.e. no crouch prior to lifting off the ground.
A further thin is that I can hear a simple soundeffect when I play arouind with my version which has lead me not to have such a problem.
Also I think I could implement a dustcloud for takeoff and not just landing.
Anyway thanks for the feedback and yes, please do send me thank link you spoke of!

Meanwhile here is a gif of the wip menus. Everything you can see also works but they have not been finalized.
Logged
UmutD
Level 1
*



View Profile WWW
« Reply #10 on: November 25, 2015, 02:21:38 PM »

I like 1-bit projects like this. Also I like the lighting effect, the overall visual impact is more interesting in those versions (though it seems you won't make it the main mode). In previous images, the first thing I notice is the lacking contrast, foreground and background elements seem to clash a bit in them, imo.

Also, the face in the menu is very nice. Perhaps a similar visual might be more fitting as the damage UI? (instead of the frontal view of the face, because it seems really hard to read, at least for me)
Logged

fingerman
Level 1
*



View Profile WWW
« Reply #11 on: March 01, 2016, 02:59:35 PM »

hi folks,

it's fair to say, that this project is on hiatus for the moment. i am very keen to work on it, however i have other more pressing stuff to deal with as it happens. as i mentioned already i am only a hobby developer. thanks to everyone who took an interest so far.

i had changed the jump based on skaz's advice a while back already:

there is a slight extension of the body and a dust cloud when EL AZOR leaves the ground. this should make the jump less crouchhing tiger hidden dragon like.

umutd, your pointers are much appreciated. i tried to go for something out of the ordinary, but all my friends who playtested could not read the damage ui! a change is required.

take care, fingerman
Logged
Overman
Level 0
***


Kid Genius


View Profile WWW
« Reply #12 on: March 01, 2016, 04:35:20 PM »

Looks neat, don't think I've seen a 1-bit game since the Atari days heh.
Logged

Genius game developer.
Me latest game: Rowan
http://www.overman-gaming.com
@OvermanGaming
skaz
Level 2
**



View Profile WWW
« Reply #13 on: March 02, 2016, 01:28:15 AM »

What bothers me now is the camera, having a camera so jumpy will not feel well imho. You probably should trigger the camera going downward if the character falls for a long enough period of time. You should ask yourself: what do I need to show to the player? If the player leaves the ground, and is going to fall back on it, is there a need to show something that's even lower than the ground?

In the case you show, considering the view is really limited around the character, the camera should follow the character when he jumps, stay locked when he falls back, on only start to shift downward if the fall last longer than the jump itself. I made a picture to show what I mean:


Step 1, 2 and 3, the camera doesn't move on Y, only following on X. Step 4, the camera shifts down on Y to reveal more terrain. Step 5 is the camera going back to normal, once back on the ground.

I also made a second picture, to show how the camera worked in my platformer prototype when a character jumps:

I limit as much camera movement, in this case I didn't move the camera at all on Y when the character jumps. I only move it up if the player lands on a position above the camera center. then , the camera gently move back, easing the movement. Well, now that I started, lets make a .gif if it in action:



In the case of falling, I made things the way I presented them in the first picture, only my view is large around the character so I only trigger the camera shift after a longer freefall. In this example, I cropped the view so the character even gets out of the frame :p



Camera is a big subject for platformer, I realised that only after I was deep in the making of my dwarf platformer prototype. But camera is the reason why so many platformers are bad. If it's good? nobody notices. If it's bad? Your games sucks. Pretty important in the end!

I recomend THIS ARTICLE on Gamasutra, all about camera in platformers.

hope I helped, if you want me to remove my pictures from polluting your thread, just ask me, no problem Smiley

Keep up!

-skaz

« Last Edit: March 02, 2016, 07:11:56 AM by skaz » Logged

LOST FORTRESS site! 2d action adventure exploration in an abandoned Dwarf fortress, overrun by weird slug-like creatures.
fingerman
Level 1
*



View Profile WWW
« Reply #14 on: March 16, 2016, 09:22:41 AM »

Hi fellow posters!

Thanks for your very detailed feedback skaz! Hand Thumbs Up Left It is very much appreciated and by no means do I view your examples a pollution of the thread. The article you referred me to was also extremely helpful. I have taken your advice into account to work on the camera.

IMPROVED CAMERA

Vertical movement is an important part of the game. It is important for the player to see what lies ahead when he is jumping up and dropping down. Hence the camera moves ahead in the way that it also did previously. (Similarly to the luftrauser example in the article.)However an issue that was not good to look at was this dip of the camera into the ground after a fall. This happened when the camera moved ahead during especially long falls.


The camera still moves ahead when jumping upwards, to show the player what is there. However when falling the camera does not move ahead too far and does not dip into the ground anymore.

A newly implemented approach is to look ahead for the players movement and to see if he will collide with the ground. If this is the case the camera does not move further than the equilibrium position of the camera when the hero is standing on that specific piece of ground.


Dropping down a shaft and intentionally slowing down on a wall. The camera moves ahead but again does not dip too far into the ground when this is not needed.

Thanks again for your advice skaz, you were totally right, it did look choppy. I hope you understand why the camera still pans upwards during jumping though (and downwards during falls).


Take care, fingerman

Logged
skaz
Level 2
**



View Profile WWW
« Reply #15 on: March 17, 2016, 12:57:51 AM »

This is way better! glad it helped, camera is often overlook by people, especially when starting to make platformer because "making platformers is easy". Well, making bad platformers is easy, what makes them good is often not noticed :p I understand your point, a very limited field of view makes moving up mandatory. My example are very cropped, in my case the field of view is HUGE around the character.

I experienced with the idea that the camera shouldn't dip in the ground when falling, my issue was that the ground may very well be a single block, and while falling you might dodge some blocks during the fall. It bumped the camera upward, but as soon as you moved lateraly, the camera had to start going down again. an issue I decided not to solve by abandoning this idea altogether. Ho w does it behave in your case?

Keep up!

Skaz
Logged

LOST FORTRESS site! 2d action adventure exploration in an abandoned Dwarf fortress, overrun by weird slug-like creatures.
fingerman
Level 1
*



View Profile WWW
« Reply #16 on: March 18, 2016, 11:58:24 AM »

@skaz Gentleman here is your explanation: I now work wih a desired and actual y position for the camera. The camera does not change to the desired position instantly but has to travel there at a certain speed. If the player is moving up the desired y is above the player. If the player is moving down the desired camera y position is below the player. If the player is grounded the desired y position of the camera is on the player.

Then there is a modifying rule: If the camera is traveling down to a desired position while the player is falling and the actual camera position is already below the player then the position at which the camera encounters the ground (solid map tile) is the new desired position.

Effect: There is no dip when falling as the desired position is never in the ground. If the player encounters a ledge earlier than expected and the camera is already actually lower than the new desired position the camera will pan up again smoothly. It works, I am happy Gomez!

take care,
fingerman
Logged
fingerman
Level 1
*



View Profile WWW
« Reply #17 on: March 20, 2016, 06:18:06 AM »

1-BIT ISSUES
I like 1-bit projects like this. Also I like the lighting effect, the overall visual impact is more interesting in those versions (though it seems you won't make it the main mode). In previous images, the first thing I notice is the lacking contrast, foreground and background elements seem to clash a bit in them, imo.

Also, the face in the menu is very nice. Perhaps a similar visual might be more fitting as the damage UI? (instead of the frontal view of the face, because it seems really hard to read, at least for me)

Thanks for your pointers Umudt, I know that you know what you are talking about. I have not made a new UI yet but have adressed this issue for the mean time by displaying a stack of the face like in the gif. The background issue should hopefully be fixed to your liking however.


A less prominent backdrop to avoid confusion about what is in the foreground and background. A sign attempts to teach the player a combo.

BUTTON COMBOS - TEACHING THE PLAYER

An important part of the gameplay are the various button combinations for the hero to perform special moves. They are not that complicated as there are only 4 buttons in total (left,right,jump,attack). An issue that I am facing, however, is how to teach the button combos to the player.

I am vaguely aware of the theory of player learning loops and the design idea of teaching without being too blunt. Also as EL AZOR will be "distributed digitally" (i.e. download it from somewhere) there won't be a manual or something. Again, the combos are not that complicated. Example: jump jump = higher jump, jump hit jump = stab drop.

The method I have opted for sofar was a tutorial level with specific chalenges for the specific moves and signposts which display the the button combination in order (as can be seen in the above blue screenshot). Sadly people whom I gave the game to, to give it a spin did not understand this. They failed due to the timings of the button presses. The timings are quite tolerant, nontheless the controls are twitchy... ... you have to be quite fast. (One of my mates playtesting on mobile even tried touch pressing the button pictures on the sign display, my heart sank! No No NO)

So my new idea is to have animated sign displays with the combos like so:


Mockup of combo display which conveys timing also. Jump, hit, hit! Is this clear?

At the end of the day the pace of learning probably also needs to be reduced and not all the moves taught in one tutorial stage at the same time.

Thanks for reading and take care,
fingerman
Logged
fingerman
Level 1
*



View Profile WWW
« Reply #18 on: March 21, 2016, 08:22:18 AM »

BUTTON COMBOS - ANIMATED SIGNS

Hi folks,

I have implemented the animated signs as planned. Hopefully this will be enough to teach players what to do. I think the GIFS are playing slightly too fast #epilepsie. Thanks for dropping by.


The animated message box in the desktop version of EL AZOR signalling to the player to do a double jump to get up the higher cliff.


Message box from sign in Android version of EL AZOR. The on screen controls are visible.

Take care,
fingerman
Logged
fingerman
Level 1
*



View Profile WWW
« Reply #19 on: April 01, 2016, 04:42:44 AM »


The collision is not quite right.

Fixed now, the indestructable box can fallproperly.

The statue of the ancient AZOR looks on.
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic