Current State of BossConstructor Part 2/2

First of all, I am very sorry for taking so long to write the second part. Unfortunately, I have been a little busy lately. Also, since this part is about aspects with which I am having a little trouble at the moment, I was sort or procrastinating a little. So, I guess, I am writing this post both for your enjoyment as well as for me to get back on track… 🙂

Sound and Music
Even though I am not much of an audiophile myself, I realise that sound and music are essential parts of a good gaming experience. I have already selected some sound effects and I am currently working on the sound engine within the game. At the moment there are still some buffering issues but I am confident that I can resolve these relatively soon. Another issue will be the engine sounds which should follow the respective ships around.
As far as music is concerned, I will probably license some royalty free tracks. So far I am using (unlicensed) music from “R-Type Final” as a place holder. Great soundtrack by the way!

Collision Handling System
One source of constant ‘wtf’ in the current build is the collision detection and handling system. The collision of arbitrarily shaped polygons – as which the ships in BossConstructor are modelled at the moment – is a surprisingly difficult and tedious task. What makes it difficult is a) that two polygons can collide/intersect in more than one place at the same time and b) that a resolved collision can itself lead to more collisions. While the current algorithm works fine in about 95% of the collision cases, the remaining 5% might get you stuck in a wall or can lead to weird chain collisions and explosions.

So, in effect, a complete rework of the collision system is probably the best way to go about this. This topic is definitely next on my todo-list.

Mission Design
The problem which I perceive as the hardest one at the moment is the mission design. There are three main possibilities of how the missions will look like and I am not yet sure which way to go.

1) Arena-style survival missions have the advantage of being very easy to implement for me and offering a long time of potential fun and replayability for the player. The disadvantage of this type of mission is that they might incentivise players to build one ‘ultimate ship’ and use it all the time, making the core feature of the BossConstructor sort of pointless.

2) Specific missions (mining missions, transport missions, escort missions etc.) force the player to adapt his ship to each mission, which is nice. However, these missions are harder to implement and may offer less replayability once you have played through them.

3) Finally, a nice idea might be to provide an open ended world map which offers exploration and lots of things to do for the player. The player could decide himself if he is in the mood to mine an asteroid field, engage some hostile pirates or deliver and trade some important goods. This mode is probably the hardest to implement and balance – however, it might also be the most fun and engaging one in the long run.

I think for now I will stick to specific missions (2) with maybe offering one or two survival missions (1) to see how it all works out. If you have any thoughts on this subject, please let me know!

Conclusion
As you can see, there is still a lot of stuff to do until the next version of the BossConstructor is done. My intermediate goal is to finish a new alpha version of the game which includes about 5 missions for you to play and enjoy as soon as possible.

Advertisements

5 thoughts on “Current State of BossConstructor Part 2/2

  1. An open-world mode would be awesome but I guess that should be just one of your long-time goals.

    If you implement the survival mode it would be a great advantage if the player is able to configure the mission itself.
    It would be great to choose which hostile and friendly spaceships are in battle.
    The ability to fight self-designed spaceships would raise replayebility a lot.

    So far so good.

    • The current ship designs are ‘handmade’ and only the AI parameters are evolved.
      I agree with the advantages you name. The game already has a shape evolution algorithm
      and I intend to make a lot of use of it in the future. The problem here is that this
      requires a massive amount of computation power.
      Someone started a discussion on this topic on the Greenlight page; I will post some more
      details there.

  2. Was playing around with your evolver tonight and noticed that the physical shape evolution was already partially in place, and seemed to be working as intended. I was running it along with AI evolution on a population of 100 ships without very much of a hit to my computer, so it’s not too bad for me at least. This was a 3-core AMD machine with 12Gb of RAM and Windows 7 64-bit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s