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’.
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.
To begin with I’d like to point out that, as we have previously said, one of the issues with a two-person team is things take forever and we are focused on tasks that aren’t blogging about progress…
However a few weeks ago Phill and myself took part in the Global Games Jam event, and because that is self contained it’s easy to post up a bunch of stuff about it!
The theme for the jam was ‘what do we do now?” and we chose to take that in a dangerously route one direction and make some kind of game where the player doesn’t know for sure what the task is, or how to complete it.
The key mechanic for this, we decided, would be a ‘warmer-colder’ type feedback system. What that meant practically was a game where you get a pleasing sound rising in pitch when you do something correctly, and descending in pitch when you do something wrong. We reinforced this by having everything change colour at the same time- brighter for YES!, darker for NO!
As you can see from the above screencap, we even made a menu. Very professional.
Now as I’m sure many of you will know, the nature of a gamejam means things very quickly get strange, and this project was no exception. Before we knew it we were making some kind of hell dimension puzzle. And we were OK with that.
The main idea throughout was to keep the player guessing, and we chose a KNIGHMARE referencing aesthetic. Partially to pay a nostalgic homage to our collective childhood, partially because it looks cool.
If I explain any more it will ruin the experience (hahahahaha) so why not head over to the GGJ page and have a look.
We intend to polish it up and correct some of the more… idiosyncratic moments. In the mean time we’d love to hear your feedback.
So, it’s been a while since i posted last but stuff has been moving. I have made a serious start on the engine, I have gone for a ‘roll your own’ approach which may seem like masochism to many people but is, for me, a good deal of the joy of working on a game. It also has the additional benefit of never encountering an issue that cannot be fixed.
Features so far:
- Deferred Render Pipeline
- Normal mapping
- Per-texel material properties (Specular, Specular function, Gloss, Ambient / Emissive)
- Direct lighting with shadow mapping (buggy)
- Tile based Dynamic point lights (diffuse and specular)
- Quad tree LOD terrain
- Reverse ray-traced model paint feature (more on this below)
- more I’m sure
Reverse ray-traced model painting?
It became apparent that we could nether afford in time or money to buy or learn a fully featured 3D package, and it would not really play to Luke’s strengths as a painter. It would be far better to be able to paint the scene in photoshop and transfer the painting into texture space, I bought a simple program for this purpose (pixexix) however it was very alpha and little bit riddled with bugs. We don’t have time to wait for it to mature but the concept was sound so I implemented my own, it did not take to long, it also allows us to paint material properties, see the actual results in engine, place lights, create scenes and test shit so its a bit of a win.
So a big part of the game is going to be sleuthing and deducing, to this end you will be required to sift through paper work from various places. So we need a document system that is a little more complex than just an image or some text, we need to be able to embed metadata in the documents have them be transformed and distorted by photocopiers and fax machines.
With this in mind here is my first pass at a document editor, on the left you have a poor mans XML markup and on the right the rendered page, I’m trying to invoke the look of declassified military documents of the period.
This was my reference, the very famous and maybe a little to obvious, declassified Project MKUltra documents. I may have gone back too far on reflection as these documents were probably typed on a typewriter and in our selected period dot matrix printers we common. However they are clearly photocopied. Notice the bulldog clip, copy distortion, the dialation on the characters and smudges. These are things to attempt to recreate in future iterations.
So while Luke gets on with his business of creating concept art and the like I have been building the game, and this is not what it looks like. The following image is of the map editor, or at least the first version of it.
Obviously there is zero art in it, it is not the game engine, in fact the plan is at present that at no point will you see the contents of the map in the game! It is a tool for tuning units, creating landscapes and devising puzzles. I made the decision not to write the engine first as far as I can tell this is the biggest mistake I have made in the past when setting out to write a game because invariably I rarely get past it. So as a change I decided to write the game bit of the game first and leave the engine bit till later.
The game bit includes the story and for that I have build a story node system and editor, seen above. It allows me to craft loose narratives and dynamic story arcs using a simple scripting language I created for this purpose, I can step through and debug the story and will eventually build or generate test run throughs so we can plug holes and see issues at a high level. For the final product I can convert (Emit) the finished story as IL bytecode for maximum efficiency but having it as a scripting language allows me to analyses and modify the structure more easily. For instance the blue node diagram in the upper left portion of the image is generated by analyzing the script and not by explicitly linking nodes.