SO we are about a year into the creation of this game (just over, in fact) and I thought it might be a good opportunity to have a look at how things have progressed over that period.
It’s inherently hard to gauge these things, especially when one has literally no reference, but we… feel… that we are roughly about halfway through the process of getting this thing ACTUALLY MADE. Of course there remain a number of problems large and small, but a this juncture we have the overall shape of the game. The individual stages are connected together in a playable, albeit tenuous, manner.
The above GIF shows a nice bit of explosion. The treatment of blowing up is something that is only recently coming into play, and I reckon it’s pretty nice. The inspiration was the types of explosion ones sees in animation, particularly Anime, PARTICULARLY particularly Tezuka. There is a lot more coming on this front and others.
The following is a video comprised of a series of development clips. The clips are arranged in chronological order, beginning with the very first mechanism demo that Phill made. It’s interesting to see how things progress, and occasionally de-versioned back a few iterations due to new development not working.
An entire slew of progress has been made yet again! We are at that sort of halfway point where things are taking shape (basic playthough nearly there, game-wide systems operational). Of course that same place is also one of a vast chunk of impending hard work that one only becomes aware of once commitment is at full…
The biggest challenge for me personally has been learning how to work within the pipeline that Phill has created- as a two person team we have to wear many hats, not just the comfy hats we like, but also the bulky ones that keep falling off. However difficult it has been to adapt my pencils-and-brushes based thought process, it has been very rewarding, the above image shows some pleasing results from this week.
Another thing we did was to capture some up-to-date demo footage in lovely 1080p, which my regular machine struggles to record. Have a look at the results below:
Over the holiday period and start of the new year, SERIOUS PROGRESS has been made. One of the biggest, more fearsome and daunting obstacles that faced us was the META SCREEN.
In the META SCREEN in player should be able to see the entire solar system and be able to plot a course through the available planetoids in a meaningful way.
We already had a working model of the ALP black hole system, and Phill had previously implemented the randomly-generated planetoids actually populating the map so this was not the task at hand.
The difficulty was making this interface workable, and making it no only obvious and easy to use, but make the choices the player has available have an impact upon the game. That is still not 100% there, but it has shaped up considerably in the last month.
Here is a brief explanation of how it works:
1: MOTHERSHIP. This represents where the mothership is in the system. The small triangular arrow indicated the direction of thrust. When the player applies thrust to change the trajectory. the cost in fuel pips is demonstrated here as well (more on that later)
2: TRAJECTORY. The blue lines traces the current path through the system. This is physics-based and thus you can make it go wildly off-course, (which is something we have to control to balance things out) but also you can opt to spend some precious reserve to visit more planetoids, or avoid ones that don’t have the resources you want.
3: PLANETOID ICON. Above each targeted planetoid is a hexagonal representation of it’s class. This is not exhasutive, merely giving a rough indication of what you might expect to find upon visiting.
4: TARGET PLANETOID. Essentially the same as the regular planetoid icon, however the on-course instance is less transparent and the hexagonal ring around the actual body is thicker. This is where the player will be going next. Sometimes it could be on the other side of the overall system so it became apparent that indicating NEXT! was important.
5:RESOURCE RESERVES. The right hand bar indicates how many PIPS of energy currently held in the reserve. This is important because altering the trajectory will consume pips, and the player must be able to easily see how much energy is held in reserve in order to decide which planetoid to visit.
This control system is not finished yet, and there will be more about it soon as we scrabble to make things balance out and function in the intended way, however things grind closer and closer to ‘playable’.
Unsurprisingly, simple questions like ‘what should the fuel counter look like?’ are some of the hardest to answer. The solution needs to be un-intrusive yet visually obvious as to what is going on.
We need our fuel bar to not only indicate the remaining level of power for the pod, but also to communicate the rate of power consumption. We don’t want to take pains to point out to the player how different actions (firing thrusters, using the tractor beam etc.) have different fuel requirements. Nobody wants to read pages of text before they get to start playing.
Another element required is, for want of a better term, the mothership’s energy cargo. As a mining vessel with absorption technology the mothership can dissolve and convert them to energy. The player dumps objects into the collection hopper to achieve this.
We need the player to be able to see the current amount of energy cargo as this will influence decisions about what to harvest from the environment and how quickly it is needed.
We have settled on a system of blocks that represent discreet units of power- each ‘pip’ is a full recharge of the pod’s fuel- that the player will be using. This will carry over between levels and will be expendable to redeem various improvements in a ‘levelling up’ fashion. Below is a video showing the first working pass of these two UI elements.
Refining the “space hulk” generation process is quite a task. Here are some screenshots that show the kind of shapes and complexity we are playing with.
Above is an example of using the rib-like structures the vessels are made from to create different types of explorable spaces.
The aim is to create something that feels like it is both an ancient, collapsing spaceship and the bizarre remains of some starborn creature.
The reasons for this design direction go beyond ‘we think it’s cool’ and are in service of the back story… more on that later though.
Initiate docking procedure.
The storyline of this game required there to be a series of very large, vaguely biomechanical space hulk environments for the player to explore. There are several ways to tackle this, and initially we considered simply hand building a few different examples- you encounter these less frequently in the game than the various floating island types.
Obviously that method would be
A: not quite in the spirit of things here and
B: too easy.
Instead the decision was made to build a random-generator for these Space Leviathans (as they quickly became named) that would build interesting astrocadavers out of modular blocks of ship design pieces.
This random generation system is now up and running (albeit in an early stage) and able to create some nice skeletal shipwrecks adrift in the ALP cosmos. Here is a video of the pod flying around some and only occasionally crashing…
It has been a long time since we updated this blog, but I’m happy to report that is because we’ve been crushing it hardcore. There is still a long way to go but here is the first public preview of our game ‘After Lotus Point’…
As you can see it’s a sci-fi themed space game, and it has exploration / resource gathering / dealing with hostile forces at the centre of the gameplay.
This is all fairly early stuff and we will be posting more detail as things progress.. more soon!