Checking in

Haven't been updating, and that's due to heaps of assignments @ uni. I'll restart working on HQ on the 16th, where I'll be trying to link this with Java3D (for performance gains).



Azriel~

Slow motion enabled

I've finally implemented slow-motion with more or less no bugs (at least, I have only encountered one so far which I haven't had time to fix.

Updates:
- Time slow
- Special effects can be set for every object on the field excluding the caster, or for all objects not on the same team
- Objects inherit their opointer's frame speed and degree of time-stop

Bug fixes:
- Floating chars did not work well after the previous re-ordering of the frame processing sequence. This has been fixed

Bugs found:
- Characters can float (watch julian in the video) if they return to the airborne frame just as they are landing.
- Flying characters float all the way to the screen in slow-motion

Next update won't contain "new" features. I'll be focusing on fixing what I already have.



Azriel~

Special effects - timestop

Added "special:" tag to implement special in game effects
special: 1 enables one degree of timestop to all Actors
special: -1 disables timestop

Been quite busy with uni work, and gameplay isn't my main focus ftm - gotta get the UI remade properly.



Azriel~

Little update

Nothing to show here, but I fixed the platform "teleporting" bug by including a special fixed bdy into each object. This way, even if with user defined bdys in each frame with different coordinates/dimensions, the platform/wall detection will use the fixed bdy's area (extends equally in both x/z axes, fixed single extension in the y axis). The fixed bdy can be denoted in the using the tag

bound: x [y [z]]

(i.e. an argument tag that takes 1, 2 or 3 arguments). If you leave this tag out, the program will use preset values. However, I still have to fix this bug for cpoints and wpoints (opoints as well?).

Another thing I've started working on is a better code structure for the main program. The version in the last release was rather messy (all "sections" of the menu were closely coupled). I've split each menu into a different class, and written the code so that future changes would be easier (keep reading). With the new structure, it will be easier for users to write their own themes/skins, and possibly write their own user interfaces in the future. In the next post I will give a preview of the new UI.



Azriel~

[Release] 31st August 2009

Download

Hero Quest - 31st August 2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Characters:
- Aeron (YinYin/Havoc Creator), slightly modded by Azriel (flight)
- Joe (Siegvar)

Backgrounds:
- Lion Forest (Marti), edited by Azriel (vertical scroll, castle)


Notes:
~~~~~~
More of a feature preview than a "playable" release, you can write your own code to test stuff, but a rundown of some of the differences between HQ's data files and LF2's data files:

x new tags
Backgrounds:
- [friction] fx: 1.25 fz: 1.25
- [ybound] y1: -600 y2: 0
- [opoints] check bg/sys/lf/bg.dat

Characters:
- [hold_<a,j,d>]
As long as you're holding A, J or D, your character will go to the frame number specified in hold_a: # (for example) after the wait: # is up. i.e. This serves as an alternative next: # frame. hit_a: will have priority over hold_a: (if you press A on a frame with both tags enabled)

- [z coordinate areas]
z1: z2: are used for bdys and itrs. This is an alternative to the zwidth: tag whereby z1 == -z2 if used. If none of these tags are specified, the data will treat it as LF2 does - z1: -12 z2: 12.

- [z axis opoint]
In LF2, objects spawned via opoint are always Parent.z + 1. With the z: tag, you may opoint relative to the Parent's z coordinate. Using z: -1 will cause the spawned object to have the same z-axis coordinate as the Parent.

*Parent here means the object with the opoint:


---------------------------------------------------------------------

The castle object is made from a few different "objects" (single data file, different frames). This is to give the impression of a "room" with different z-levels. If you try and get on top of the castle via the stairs, you'd notice that your character tends to "teleport" to different places. This wouldn't happen if there is only a single identical bdy used for all of the frames, which would be much easier to work with for wall/platform detection. However, bdys keep varying in each frame, so to not have it buggy is near impossible.

Don't kill yourself trying to get onto the castle with Joe, it takes quite a number of tries.

charging/continuous inputs enabled

New tags have been implemented: hold_a: hold_j: and hold_d:
Basically they're the same as hit_a: hit_j: and hit_d:, but it doesn't care how long ago you pressed the keys, as long as you are holding it on the frame. also, it doesn't just "skip" to the frame, it waits for the wait: value to be up, and then goes (as in, it's the same as just having the hold_x: frame # as the next: #).

In the video, when you do D (forward) A with firen, you do the normal fireballs. however, if you do D (forward) A and hold A, it will shoot the big fireballs. Also, when you do DVJ, it just does a single flame; if you hold J continuously, he will keep breathing fire.

Azriel~

Small updates

Tested out Aeron on Hero Quest today. Exposed a number of bugs, some of which I fixed. Messed about with 2 players flying around. It was cool:



updates:

• improved code structure and condition checking for interactions
  


• added loading for light weapons and heavy weapons
  


• added rebound functionality for energy blasts


• set dv[x|y|z] 550 to stop Actors from moving


• implemented state: 100 (next: to frame 94 when you land on ground)


• enabled z axis movement for dvz: in the frame header

bug fixes:

• fixed data loading for extra unused tokens (e.g. wait: 10 6)

Azriel~

Platforms, camera, opoints

Updates:

• Camera scrolling works perfectly (y/z axis scroll may need correction of coordinates)
  
• Platforms (buggy)
  
• Multiple opoints
• z coordinate opointing

Azriel~

Camera scrolling - extended

adding on to the camera scrolling, there's y and z axis scrolling now (both planes taken into account, shown in video by jumping up while on different z coordinates).

layer scrolling half works, I've got the algorithm slightly wrong (that's why you see the black bars on the right). Gotta fix those in the next update.



Azriel~

Camera scrolling

I've started the basic scrolling (x-axis) of the game's camera. Worked out some algorithm that seems to simulate LF2's camera quite well. y/z-axis scrolling may be a bit different though, seeing that extreme platforming may cause unexpected behaviour.

change log 28th July 2009
updates:
- type 3 loading
- opoints
- camera scrolling

bug fixes:
- holding down A during jump/dash causes it to be set to true even while on ground
- mid air "walk"
- dash dirchange could allow you to glide above the ground.
- falling landing in mid air
- various small bugs



Azriel~

Layout

Trying to find the right layout to use. There's the

LF2 layout, 2×4 boxes on top of the frame (HQ view)
Rumble Fighter 4 boxes on top of the frame, 4 below (HQ view)
Electronic popple, Player bars at the bottom of the screen, boss bars at the top
latest:

backgrounds need to be done, frame bars may be changed. Overall, kinda getting positive feedback.



Azriel~

Beginning of Hero Quest

Little Fighter 2 is one of the most successful games to be made. Its "moddability" is one of the main reasons for its long popularity and survival. It has also inspired me to create a game of my own.

Hero Quest will be an action beat-em-up, with multi-player support with certain playability similar to rpgs. The basic engine is under development. Currently this is quite new, and a lot of work has to be done.



Azriel~