Strides Interactive

Problem Solving - Which way out?Filed Under: Discussion, Weekly Tuesday Dose of goodness

Hi all,

This week I have a little special article for you guys. Instead of talking about what I feel, I’m going to share something that I’ve done instead. And yes, it’s related to problem solving.

This problem is a direct problem I have in the game - Jedi Wing 2 that I’m currently developing.

Wanna know more? Read on…

As we all know, programming and software development by right should lead to one thing - solving problems.

In a typical software house, such problems are defined by business and user requirements.

Now, in Jedi Wing 2, no doubt it may only be a free-ware fan-based game, it’s still a whole game with its own set of problems.

One of the many problems that I’m currently facing is to develop the effect to show that a ship’s hull is seriously damaged.

You see, how do you know when a ship has a certain status? You decorate them right? Sometimes with icons, avatars, color mappings and even particles attached to it.

Here’s a picture of an example of an enemy ship:

So, what’s expected to happen during the course of the ship being attacked by the player? Here it is:

Once the shields are down, here’s what happens:

As the player continues to attack the ship, here’s what will eventually happen:

There’re a few ways to get explosions to appear on the enemy ship. But before we go into the solutions, let’s take a look at the constraints.

Constraints:
1) Explosions must appear in the vicinity of the enemy ship
2) It should be spawned from an emitter with random frame rate, timing and position
3) The frequency of the explosions must get slightly higher as the hull percentage becomes lower

Proposed Solution #1: Deriving more tech

1) Modify the collision manager, collision unit and collision unit instance class to allow picking of a position within the boundaries of the game object.
2) Since a single unit of a boundary is interfaced by iIntersectable, changes will have to be made across the board to accommodate a new method to retrieve a random location.
3) Since each boundary can be in different forms, we’ll need to implement the new method for at least but not limited to the following:
- Axis-aligned bounding box
- Oriented bounding box
- Planes
- Triangles
- Spheres
* Not to mention, these boundaries can be rotated prior, so the whole equation can be very messy
4) A vector system must be in place to store the random positions so that it’ll be exposed to the script user for orchestration
5) Additional FOA methods will be required for the vector system
6) Additional FOA methods are required to pick a random but valid position within the boundary
7) The collision unit instance will have to transform the random location with the game object’s matrix (containing scale, orientation and position) so that the location is a valid world coordinate.

Effort required: Hell a lot! At least 4-5 days of coding and testing. Includes making it stable and qualified for release.

Effects achieved: It satisfies only but 1/3 of the entire requirements. The other 2/3 of the requirements require some periodic calculation of the game object’s actual status. This will eventually require an entity manager which handles internal game object state transitions.
Conclusion: In the end, only the vector system is implemented due to its imminent requirement for upcoming in-game mechanisms.

Proposed Solution #2: Using what’s available

The proposal below is based entirely on using Strides Scripts to achieve the objectives without writing a single line of throwaway code.

1) Create an unique collision list known as the HullBurstList
2) Orchestrate all crafts from the ImperialBodyList to perform collision detection against the HullBurstList
3) Create a dummy sprite, known as HullBurstSprite with any texture, preferrably the ones commonly used so that texture switching is minimized.
4) Set the alpha value of HullBurstSprite to zero. This will allow the sprite to exists and checked against even when it’s technically invisible to the players.
5) Set the speed of HullBurstSprite to a speed where it can easily catch up with its targetted ship
6) Create a particle emitter known as HullBurstEmitter which is responsible for emitting instances of HullBurstSprite
7) Set emission parameters to default, emission style should be manual.
Create a template script that describes an orchestration to attach an instance of HullBurstEmitter onto a given sprite name (which is the enemy ship), this script will fire 4 HullBurstSprites in the span of 2 seconds at the given sprite.
9) In the script that checks for hull reduction, add in a direct (immediate) call to Check Hull Less Than 50%
10) In this new script, ships will be checked against whether if their hull is below 50%. Once found to be so, an instance of the template script will be spawned and run immediately.
11) When an instance of the HullBurstSprite hits the enemy ship, it’ll be removed and a random explosion combined with 3-4 debris particles will be generated in its place.

Here’s a screenshot of how it looks like:

Effort required: Quite a lot of efforts required, but no codes were involved in this solution. The hardest part would be to piece the puzzle together using creativity rather than bull-runs with technology.

Effects achieved: It satisfies approximately 3/4 of the requirements. The explosions only appear randomly when the ships are shot at and is not automated. The reason for this limitation is because of a lack of an entity manager as well as the trigger point is entirely based on a collision detection reaction and not from an inspection routine.

Conclusion: In the end, the effects conjured is still satisfactory. It however demonstrated a greater need for an entity manager which must be implemented eventually.

Conclusion to this article

I guess your brain is now filled with a lot of information politely put or bluntly, confused. This is because, in the 2nd proposal, the entire solution was derived from StridesScript’s functionalities.

The whole point of this article is to demonstrate that the same problem can be resolved by many possible solutions; coding is not the only way out.

In this example, I’ve demonstrated how difficult it can be if we just jump into coding and ignore the real requirements behind the problem. This problem can easily balloon into a snowball of functionalities and changes which will eventually slow down your progress.

Since the original problem is not a big problem, such changes should be escalated slowly by other requirements and not be implemented in codes in a spur of a moment. It’s not worth investing so much time in new technology just to solve small problems like this.

Morale of the story? Always look what you already have, what you can use and recycle before considering making new assets. There’s of course a catch in this statement; that is - you’ll have to be at least 75% sure of what you already have, best if it’s 100% before deciding whether it’s better to recycle or make new ones.

Lastly, it’ll be a big mistake if one thinks that aggregating 3rd party libraries can easily resolve this small problem. Not only you add weight and performance penalties to your application, you also risk wasting a lot of time learning the new 3rd party API enough to integrate into your existing application.

Efforts vs Effects, think again.

Signing off,

Jeremy

Series Navigation

«Problem Solving : Look Near Before Looking Far