Announcing - Hammer of the Gods

[ColecoGamer]

9 hours ago, phoboz said:

Currently figuring out how to make good enemy AI. I didn't like the AI of Open BOR, e.g. all enemies walking the shortest path to the player (many enemies will overlap). Rather I would like to make something closer to the AI of Final Fight (where the enemies actually try to surround you from different directions)

May I suggest hunting down the source code to games like Knights of the Round or Final Fight? Both games use the AI you mentioned in your post. Maybe these will help you figure this problem out?

Edited October 9, 2022 by ColecoGamer

[JagChris]

18 minutes ago, ColecoGamer said:

May I suggest hunting down the source code to games like Knights of the Round or Final Fight? Both games use the AI you mentioned in your post. Maybe these will help you figure this problem out?

It would be helpful just to link for him

 

https://github.com/originalgrego/FinalFightAE-Source

[+CyranoJ]

Is this based on OpenBOR or a new game?

[ColecoGamer]

52 minutes ago, CyranoJ said:

Is this based on OpenBOR or a new game?

Good question. I always believed it was a new game.

[Eternal-Krauser]

It's a totally new game, if the OpenBOR theme is mentioned, it's because we were discussing what kind of A.I. It would be convenient.

[LordKraken]

22 hours ago, phoboz said:

Currently figuring out how to make good enemy AI. I didn't like the AI of Open BOR, e.g. all enemies walking the shortest path to the player (many enemies will overlap). Rather I would like to make something closer to the AI of Final Fight (where the enemies actually try to surround you from different directions)

Maybe overkilled for a Jaguar game, but dividing the floor into a grid and using A*. Since the grid can be small you should'nt have any performance issue.

[phoboz]

1 hour ago, LordKraken said:

Maybe overkilled for a Jaguar game, but dividing the floor into a grid and using A*. Since the grid can be small you should'nt have any performance issue.

Yes I also thought about a grid based approach. If an enemy already occupies the cell right in front of the player, the next enemy should approach another empty cell close to the player.

 

13 hours ago, JagChris said:

It would be helpful just to link for him

 

https://github.com/originalgrego/FinalFightAE-Source

Thanks for the link.

Unfortunately I am so bad at understanding other people's code, but it may be helpful to see if they also used a grid based approach?

Edited October 10, 2022 by phoboz

[ColecoGamer]

On 10/10/2022 at 5:39 AM, phoboz said:

Yes I also thought about a grid based approach. If an enemy already occupies the cell right in front of the player, the next enemy should approach another empty cell close to the player.

 

Thanks for the link.

Unfortunately I am so bad at understanding other people's code, but it may be helpful to see if they also used a grid based approach?

I’m no expert, but as someone who plays Final Fight constantly, I can say the enemies do seem to move on a grid system. How do I come to this conclusion? When an enemy attacks the player, the other enemies never occupy that spot. If you notice, the enemies will wait for the space in front of the player to clear, or they will walk around the player to attack.

 

Edit: Watch the first stage in the video below to see what I mean.

 

 

Edited October 15, 2022 by ColecoGamer

[ColecoGamer]

On 10/10/2022 at 5:39 AM, phoboz said:

Yes I also thought about a grid based approach. If an enemy already occupies the cell right in front of the player, the next enemy should approach another empty cell close to the player.

 

Thanks for the link.

Unfortunately I am so bad at understanding other people's code, but it may be helpful to see if they also used a grid based approach?

Here is a link to Final Fight’s enemy AI. I agree that it can be difficult to read someone else’s code, but from what I deciphered, this should answer your question(s):

 

https://github.com/originalgrego/FinalFightAE-Source/blob/master/ffight_ae_ai_targeting.asm#L1

if you notice in the code below, Capcom’s programmers seem to use a ‘shuffle’ technique for the enemy sprites, which technically can be seen as a grid-like system.

 

;================================================
 ; Calculate ai target
 org 0x028084
   jmp hijack_ai_targeting
   
ai_target_player_3:
   lea     (p3_main_mem,A5), A0
   move.w  #$4, D0
   rts
      
 org $027BF6
   jmp hijack_shuffle_check_active_player

 org $027C04
   jmp hijack_shuffle_check_player_8E

 org $027C20
   jmp hijack_shuffle_try_next_player

 org $027AC6
   jmp hijack_minor_enemy_targeting
;================================================

;================================================
; Group targeting
 org 0x027E44
    jmp hijack_minor_enemy_group_targeting_check

 org 0x027CC6
    jmp hijack_minor_enemy_group_targeting_check_2

 org $027FD6
  jmp hijack_p2_generate_group_data

 org $003DFC
  jmp hijack_p2_init_group_data
;================================================

;================================================
 ; Boss targeting
 org 0x040A6A
   jmp hijack_boss_ai_targeting
;================================================
  
   
;================================================
; Damnd
 org 0x03D40A
   jmp hijack_damnd_initialize

 org 0x03D4CE
   jmp hijack_damnd_choose_initial_player
   
 org 0x03D592
   jmp hijack_damnd_player_status_jmp
   
 org 0x0408D6
   jmp boss_choose_random_player
   
 ; Damnd targeting 
 org 0x0406DC
   jmp hijack_damnd_targeting_2

 org 0x040756
   jmp hijack_damnd_targeting_3
;================================================

;================================================
; Sodom
;================================================
 org 0x040D3E
   jmp $040D82 ; Ignore player status check
   
 org 0x040DF6
   jsr $040E7A ; Always use multiplayer targeting logic
   jmp $040E04   

 org 0x040C64
   jmp hijack_sodom_initialize

 org 0x042AEE
   jmp boss_choose_random_player

; Sodom targeting
 org 0x042742
   jmp hijack_sodom_targeting_1

 org 0x0427BC
   jmp hijack_sodom_targeting_2
;================================================

;================================================
; Abigail
 org 0x04BE40
   jmp hijack_abigail_initialize
   
 org 0x04BEB2
   rts  ; Do not try to assign from health tables...

 org 0x046BE0
   jmp hijack_abigail_edi_targeting
   
 org 0x046C9C
   jmp hijack_abigail_edi_reassign_target

 org 0x04C17A
   jmp hijack_abigail_active_player_check
 
 org 0x04CA46
   jmp boss_check_active_player_89
;================================================

;================================================
; Edi E
 org 0x045F64
   jmp hijack_edi_initialize

 org 0x045FDC
   rts  ; Do not try to assign from health tables...
   
 org 0x04623C
   jmp hijack_edi_active_player_check
   
 org 0x046BAE
   jmp boss_check_active_player_89
;================================================

;================================================
;Rolento
 org 0x048A92
   jmp hijack_rolento_initialize

 org $04AFE0
   jmp hijack_rolento_damage_table_calc

 org $04A85A
   jmp hijack_rolento_choose_random_player
   
 org $049DE6
   jmp hijack_rolento_nuckin_futz_check
   
 org $049E7C
   jmp hijack_rolento_nuckin_futz_check_2
   
 org $04AD02
   jmp hijack_rolento_double_proximity_check

 org $04ADAE
   jmp hijack_rolento_prox_then_random
   
 org $049e20
   dc.w $0064, $0064, $008C, $00B4 ; Rolento health values for 1-3 player to go nuckin futz mode
;================================================

;================================================
 ; Andore targeting
 org 0x02E5C4
   jmp hijack_andore_targeting

 org 0x02E5A4
   jmp hijack_andore_switch_player
   
 org $02DDFE
   jmp hijack_andore_butt_slam_prox

 org $02D124
   jmp hijack_andore_prox_check_other
;================================================

;================================================
 ; Bred, pick active player
 org 0x022AC6 
   jmp hijack_bred_pick_active_player

 ; Bred, pick active player
 org 0x022B1E
   jmp hijack_bred_pick_active_player_2

 ; Bred proximity check, I believe this is what causes waiting enemies to attack
 org 0x0279C0
   jmp hijack_bred_prox_check
;================================================

;================================================
 ;  Two.p, Pick active 
 org 0x028BB6
   jmp hijack_two_p_pick_active_player

 ;  Two.p, Pick active 
 org 0x028BF8
   jmp hijack_two_p_pick_active_player_2
;================================================

;================================================
; Axl active player check
 org 0x02ADA8
   jmp hijack_axl_pick_active_player

; Axl active player check
 org 0x02ADF4
   jmp hijack_axl_pick_active_player_2
;================================================

;================================================
 ; G. Oriber proximity test
 org $032BC8
   jmp hijack_g_oriber_targeting

 ; G. Oriber proximity test
 org $032C3E
   jmp hijack_g_oriber_targeting_2
;================================================

;================================================
 ; Roxy proximity test
 org 0x03A610
   jmp hijack_roxy_proximity_3

 ; Roxy proximity test
 org 0x03A59A
   jmp hijack_roxy_proximity_2

 ; Roxy proximity test
 org 0x038AD4
   jmp hijack_roxy_proximity
;================================================

;================================================
 ; Hollywood, proximity test
 org 0x036A5A
   jmp hijack_hollywood_proximity
;================================================

;================================================
 org $0514E0
   jmp hijack_andore_boss_proximity
;================================================


;================================================
 org 0x00302E
   jmp hijack_major_enemy_hit_tageting
;===========================================

;===========================================
 org 0x002F80
  jmp hijack_enemy_health_calc
;===========================================

;===========================================
; BELGAR
 org $04EA20
   jmp hijack_belgar_initialize
   
 org $04EAB6 ; Do not assign belgars health from table
   nop
   nop

 org $04F058
   jmp hijack_belgar_update_player_position

 org $04F346
   jmp hijack_belgar_update_a6_a8

 org $04F6C2
   jmp hijack_belgar_update_a8

 org $04F0EE
   jmp hijack_belgar_target_other_player

 org $04F2B8
   jmp hijack_belgar_active_or_random

 org $04FB08
   jmp hijack_belgar_prox_check

 org $04FC9C
   jmp hijack_belgar_active_or_C9_check

 org $04FCBE
   jmp hijack_belgar_active_or_x_prox_check

 org $04F2DA
   jmp hijack_belgar_active_or_y_origin_prox_check

 org $04F670
   jmp hijack_belgar_active_or_y_origin_prox_check_2

 org $04FC6E
   jmp boss_check_active_player_89

 

Edited October 15, 2022 by ColecoGamer
Added Final Fight game code.

[phoboz]

Januari 2023 update.

Very basic AI.

 

 

[mdkdue]

23 minutes ago, phoboz said:

Januari 2023 update.

Very basic AI.

 

 

This is extremely impressive. Amazing work, well done.

[UHATEIT]

This looks fun. Me likey!

[Guest]

When I first came into this thread I was gonna say it reminded me of Sword of Sodan. But I think most would take that as an insult. After watching the January 2023 update I’m super impressed with this game demo. Really makes me want to get back into computer and 3-D rendered art again. Just want to say bravo guys it’s impressive. 

[phoboz]

27 minutes ago, Zeptari1 said:

When I first came into this thread I was gonna say it reminded me of Sword of Sodan. But I think most would take that as an insult. After watching the January 2023 update I’m super impressed with this game demo. Really makes me want to get back into computer and 3-D rendered art again. Just want to say bravo guys it’s impressive. 

Yes Sword of Sodan looked very nice, but I don't remeber much about the gameplay.

[Senneman]

4 hours ago, phoboz said:

Januari 2023 update.

Very basic AI.

 

 

 

Nice work! Seems like a very fun game!!!

 

... I don't want to intrude myself but I have a few suggestions, such as the animation of the sword - it has some weird smears, sometimes it looks like a white flag. The walkcycle of the main character also does not always seem to be correct. For example: it is standing still and has 3/4 view, when walking it is in profile. Just feels not solid enough. Example from the Animator's survival kit:

 

The artwork overall feels a bit muddy ... but i suppose some of them are placeholders? 🙂.

[SlidellMan]

You did an excellent job on the parallax and subtractive colors. Is line scrolling for the ground in the foreseeable future?

[phoboz]

14 hours ago, SlidellMan said:

You did an excellent job on the parallax and subtractive colors. Is line scrolling for the ground in the foreseeable future?

Probably not line scrolling, as we use larger images as layers on the levels.

 

Some layers are parallax behind the player, but some levels also have a faster moving layer in front of the player's layer.

 

It was done differently for the various stages based on what would look best for the specific environment.

Edited January 31, 2023 by phoboz

[phoboz]

16 hours ago, Senneman said:

 

Nice work! Seems like a very fun game!!!

 

... I don't want to intrude myself but I have a few suggestions, such as the animation of the sword - it has some weird smears, sometimes it looks like a white flag. The walkcycle of the main character also does not always seem to be correct. For example: it is standing still and has 3/4 view, when walking it is in profile. Just feels not solid enough. Example from the Animator's survival kit:

 

The artwork overall feels a bit muddy ... but i suppose some of them are placeholders? 🙂.

Interesting points.

 

We chose a specific art direction for this game, as we wanted to have a post 16-bit look. It's a little bit hard to define what that is, but if we would have gone for the classical Capcom look it would have become very synonymous to the 16-bit era.

 

That's not to say that we are ignoring specific opinions on the animations.

@Eternal-Krauser also had similar impressions on some animations when he saw them in action (even if I didn't notice)

 

In some cases it was I that didn't implement his timing and framing fully according to his specification, in other cases he thinks that a re-work is needed on the actual animation images.

Edited January 31, 2023 by phoboz

[agradeneu]

2 hours ago, phoboz said:

 

We chose a specific art direction for this game, as we wanted to have a post 16-bit look. It's a little bit hard to define what that is, but if we would have gone for the classical Capcom look it would have become very synonymous to the 16-bit era.

 

 

 I hope you are kidding a bit  

 

To recreate the famous Capcom style and to do it any justice, you would need a bunch of top level pixel artists and probably a decade of work,  to pull something off at a professional level, e.g. like Paprium. 

 

Iam not kidding here, I know why I would not attempt such a game as an hobby project. At least if I was aiming for real good pixel art quality.

 

Going with prerendered/digitized graphics is much more feasable for a hobby project, especially if you plan to finish it within merely 1 year development time.

 

 

However, defining pixel art generally as "16 bit" is a curious way of overselling your choice of style though. Because it is not, actually. 

 

90s Capcom arcade games like Darkstalkers demand  much more powerful hardware than 16 bit consoles, e.g. CPS2, and they command hardware of the likes of PSX or Sega Saturn (or later also Dreamcast) for faithful home ports.

 

Many refer them as "32 bit" pixel art graphics, as these graphics showed way more color detail and animations than classic 16 bit consoles (SNES or MD) could realize. 

The catch is that every additional animation frame needs to be drawn by hand, which is the reason what makes those games so demanding for pixel artists.

 

The same goes for any multi parallax backgrounds, that would require weeks/years of work to hand pixel every detail, quite the opposite of  photoshopping ready made images.

 

 

 

 

 

On the other hand, digizited or prerendered graphics were quite common on 16 bit consoles and even 8 bit, e.g. Mortal Kombat or Donkey Kong Country. 

 

Of course, a lot of those prerendered gfx were brutally downscaled on 16 bit machines due hardware limitations but something like DKC looked almost "nexgen" on the SNES.

 

 

Not trying to criticize the project or choice of style as such, IMO, it is a good compromise to create good looking gfx for such a demanding game in a reasonable time frame, especially for a free time project.

 

 

 

 

 

 

 

 

 

 

Edited January 31, 2023 by agradeneu

[SlidellMan]

I understand, Phoboz. If you need another person to help with the pre-rendered assets, I know quite a few who can help.

[phoboz]

1 hour ago, agradeneu said:

 I hope you are kidding a bit  

 

To recreate the famous Capcom style and to do it any justice, you would need a bunch of top level pixel artists and probably a decade of work,  to pull something off at a professional level, e.g. like Paprium. 

 

Iam not kidding here, I know why I would not attempt such a game as an hobby project. At least if I was aiming for real good pixel art quality.

 

Going with prerendered/digitized graphics is much more feasable for a hobby project, especially if you plan to finish it within merely 1 year development time.

 

 

However, defining pixel art generally as "16 bit" is a curious way of overselling your choice of style though. Because it is not, actually. 

 

90s Capcom arcade games like Darkstalkers demand  much more powerful hardware than 16 bit consoles, e.g. CPS2, and they command hardware of the likes of PSX or Sega Saturn (or later also Dreamcast) for faithful home ports.

 

Many refer them as "32 bit" pixel art graphics, as these graphics showed way more color detail and animations than classic 16 bit consoles (SNES or MD) could realize. 

The catch is that every additional animation frame needs to be drawn by hand, which is the reason what makes those games so demanding for pixel artists.

 

The same goes for any multi parallax backgrounds, that would require weeks/years of work to hand pixel every detail, quite the opposite of  photoshopping ready made images.

 

 

 

 

 

On the other hand, digizited or prerendered graphics were quite common on 16 bit consoles and even 8 bit, e.g. Mortal Kombat or Donkey Kong Country. 

 

Of course, a lot of those prerendered gfx were brutally downscaled on 16 bit machines due hardware limitations but something like DKC looked almost "nexgen" on the SNES.

 

 

Not trying to criticize the project or choice of style as such, IMO, it is a good compromise to create good looking gfx for such a demanding game in a reasonable time frame, especially for a free time project.

 

 

 

 

 

 

 

 

 

 

As I am not an artist myself I cannot tell. You are probably definately right that it is not an easy task to draw a lot of high quality pixel art by hand. It probably takes a long time too.

 

I am aware of later installments of Capcom games like the ... vs. Capcom series and the later Street Fighter games on the Dreamcast. At the same time, this art direction is not as iconic to me as it was in the original Street Fighter II, Final Fight, Magic Sword etc.

 

It's not easy to have a clear definition of post 16-bit style graphics, but a lot of it was indeed pre-rendered in the 90's. That is not to say that it was the only direction, and later we saw a lot more cartoonish art when higher resolutions became available on the game consoles (e.g. from Dreamcast on onwards)

 

Some may also consider digitized graphics, like in Mortal Kombat etc. to be post 16-bit, at least we have seen some of it in the Jaguar spin-offs of Mortal Kombat.

 

I guess Hammer of the Gods is a mix of pre-rendered characters, and digitized graphics for the backgrounds. If you forgive me for making up my own definition of the term "post 16-bit graphics"

Edited January 31, 2023 by phoboz

[agradeneu]

12 minutes ago, phoboz said:

 

 

If you forgive me for making up my own definition of the term "post 16-bit graphics"

No

 

Lets say Iam not really convinced.

 

It somewhat resembles Ataris mistake of marketing prerendered graphics as "nexgen", no matter the actual visual quality, like e.g. Crescent Galaxy.

 

Prerendered gfx CAN look very sharp, detailed and fluid, like some stuff NG Dev did for NEO GEO.

 

 

Edited January 31, 2023 by agradeneu

[mdkdue]

2 hours ago, SlidellMan said:

I understand, Phoboz. If you need another person to help with the pre-rendered assets, I know quite a few who can help.

Just what we need to see..positivity and enthusiasm to help.
 

Kudos to you.

 

I really love my Jaguar and THE Jaguar, but ironically this forum can make that rather painful, surely it should be the opposite as that’s why we are all here right?

Edited January 31, 2023 by mdkdue

[agradeneu]

From what I have seen of Eternals render artwork in e.g. Asteroite boxart, it is really good creation of character designs.

 

However, Phoboz, maybe you can explain why they translate to such blurred out and pretty flat appearing sprites in HotG, killing most of the details that the original renders might have displayed?

 

Iam just wondering if there was a way of improvement, and why this hard downgrade was necessary?

[agradeneu]

4 minutes ago, mdkdue said:

Just what we need to see..positivity and enthusiasm to help.
 

Kudos to you. Too much negativity, over analysing and boring nit picking is really rather tedious.

 

I really love my Jaguar and THE Jaguar, but ironically this forum can make that rather painful, surely it should be the opposite as that’s why we are all here right?

Believe me, from my perspective,  cheerleading from the sideline is not really help. 

 

I comment honestly what I think about this, let's say the glass is half full. There are many positive things, sure.

 

As the game is far from completion, some suggestions might lead to some improvements maybe?