June 24, 2014 in Dev Blog
June 23, 2014 in Dev Blog
So aside from Armagon’s brilliant work on the outposts. We managed to get lots of other bits and pieces done today too.
Forests parallax was improved, which is something I’ve been meaning to do for a while:
A little hard to see here, but there are new mountains, new grass and the parallax is at a better height to always be on screen.
The AI window was expanded and given more features:
Work has begun on the UI for selling to merchants. And a great deal more UI elements were fixed and cleaned up.
A bunch of things went on in regards to combat and swords too, but I’ll let Omni post about those.
June 23, 2014 in Dev Blog
Hi guys! I continued work on the Outpost today. I’m afraid I don’t have a huge amount to announce, as I’m continuing at my usual pace (including my tendency to obsess over small details). As I’m currently focusing on creating a large number of rooms for the outpost to draw on, I dedicated today to loading the dungeon with numerous lobbies for the game to choose (while carefully incorporating rules to prevent very specific combinations from being used). Since these are going to be the first rooms players pass through in most outposts, I felt it important that they give off a welcoming vibe.
Tomorrow I’ll be continuing in this fashion. I’ve still got security, storage, dorms, and dining areas to tackle. After all the small rooms are done, then it’ll be on to the layouts, which should result in some much greater variety than you’re currently seeing in the nightly builds.
Until next time!
June 21, 2014 in Dev Blog
After dusting off the wiring system and fixing those old bugs yesterday, I decided to keep the momentum going and properly implement some more long overdue features. Kyren fixed the setLightColor Lua binding, and I’ve now scripted all of the tiered lights to be properly switchable:
These lights can be turned on or off directly through interaction or by using wires, so I also configured all of the tiered switches to work properly:
June 20, 2014 in Dev Blog
Omni has demanded that I also post an update so we can get the rare 3x complete dev collection post combo.
Lately I’ve been working on mostly the AI interface. I’ve been working on mostly technical things behind the scenes to hook up different bits of functionality to the AI like repairing your ship, but also one kind of neat feature: giving the AI interface a different speech scheme. Now, when the AI has something to say, it will say it within individual screens, and each screen will have its own “emotion” attached to it. For example, the AI might start by talking at its normal rate, and then when you hit next, it might get very agitated and the text and animation might speed up, as well as showing an animation for a different emotion. Think Phoenix Wright.
I’ve done a couple of other odds and ends, like helping metadept fix the wiring bug, as well as adding some capabilities to do custom object collisions. I’ve also fixed several rendering bugs in our CanvasWidget (fixes glitches with the nav ui) and our text renderer.
Also we have decided because of the positive feedback about the glitch AI that we should make every ship AI a different animal, all with boobs.
June 20, 2014 in Dev Blog
Recently, I’ve been occupying myself with little odds and ends and helping other people.
Yesterday, I did a few Lua enhancements. Now you can access the aimPosition of your owner if you’re an item. And everything that has access to root callbacks now can query the image metadata database, which contains information on image sizing and tile placements.
I’ve been working on Parrying (with two handed weapons), but so far it’s still incomplete. So I used today instead to fix some one off issues with the Text Painter and the Wire Renderer. The Wire Renderer still needs some major restructuring, but I’ve started the process. The issue used to be that some wires wouldn’t show up unless the inbound node was within 64 blocks of the screen. Which is hacky and ick.
I removed the 64 block extra area. And made it so it will render also if the outbound node is on screen. This exposes another problem though, which is if the wire merely crosses through the screen, but neither node is within. To fix this, will take a bit more work, (storing the wires themselves, rather than the nodes and connections,) and present an interesting challenge (efficiently querying the world for lines that pass through a particular rect, rather than points), and as such that will need to be solved on another day.
As far as the text painting bugs, I simplified the rendering result to merely return a Rectangle where the text was rendered, rather than a width, height and number of lines, (which doesn’t actually give us information about *where* the text was rendered.) This fixed a few flickering text bugs in the AI’s scrolling text. Slowly but surely we’re dragging our frontend code into something respectable.
June 20, 2014 in Dev Blog
Today I took a (short) break from working on monsters to fix some longstanding wiring bugs. This is stuff that’s been bothering me since I started modding in December so fixing it has been super satisfying. First, I fixed the selection code so that wires can be properly connected and disconnected to and from nodes that are packed closely together:
After that, I fixed a bug that prevented wires from being disconnected at all in the current nightly, fixed some world wrap issues with node selection, and a couple of other minor things. Finally, I think I managed to solve the ages-old bug that caused some wire connections to be broken during world loading! Hopefully some of you testing the nightly builds can help confirm that this no longer happens (after it’s updated tonight).
All in all, these fixes should make the wire system much more usable. Now I’m off to spend the weekend messing around with new ideas for wired objects… see you all next week!
June 18, 2014 in Dev Blog
As you may have been able to infer from previous posts I’ve made, I tend to juggle my duties a lot. While I wait on the sound on projectile functionality, I’ve spent the past couple of days getting the outpost dungeon file working with its key. There’s still a couple of items I’m waiting on from George, but it’s complete enough that I can commence work putting together the outpost, so that’s what I spent my day doing.
I typically go through a process of mapping out in my head how a dungeon is going to function before I start actually placing blocks in-game. The first thing I decide is whether this dungeon is going to be predominantly an above ground structure or a sprawling underground one. It sounds like a minor thing, but it changes my design process in some fundamental ways.
First, ensuring the dungeon has a nice unpredictable layout is a good deal easier when it is below ground, as typically I don’t need to worry about whether the structural support makes sense or not, giving me far more leeway to make pieces as big or small as I want. Most underground dungeons can sprawl freely and connect to just about any piece so long as they are not blocked by another existing piece. This also helps to make the layouts less predictable, provided a dungeon has a good number of pieces (see the Avian Temple for example).
There are distinct downsides to this approach however. Because of the sprawling and highly unpredictable nature of the pieces placed in an underground dungeon, it’s not so uncommon for pieces to be placed in such a way that they turn back on themselves, resulting in abrupt ends where it won’t even place a proper wall. These necessitate me creating what I’ve taken to calling “end caps”, that are in essence very small pieces that are used to close off a hallway or room where there is no room for any other pieces. Even though these pieces are small, making sure they connect and look smooth everywhere can become pretty involved, especially if you want decent variety in them.
Designing a dungeon to be an above ground complex comes with its own set of pros and cons. It demands you put more thought into the overall structure and layout of your dungeon, which results in a more consistent design at the expense of randomization. Typically my approach to the above ground kind of dungeon is to either design a series of separate structures with randomized elements within them (see the Human Prison), or one grandiose structure with a lot of areas that can be randomized (see the Glitch Castle). Using the latter approach, multiple layouts are critical to increasing variety and reducing repetitive elements (particularly when players encounter the same dungeon type repeatedly). The more layouts I’m able to make, the better the end result will be.
Which brings me to the Outpost.
This is just the barebones structure right now, hence the lack of decoration indoors. The main focus has been laying down my foundation, working out precisely how large the rooms are going to be, how much will be randomly picked and how much will be clearly defined.
The outpost will be a relatively small scale dungeon, and I’m structuring it in a fashion similar to the Glitch castle with multiple layouts planned to mix things up. Making multiple layouts for the castle was fairly long-winded due to the sheer scale and my determination to ensure each layout was decorated differently. The outpost being smaller in scale means I’ll be able to produce more layouts far more rapidly, but my initial goal will be getting all the smaller rooms finished first.
In this map of the first outpost layout, the large grey areas within the structure are where the game can place randomly selected rooms. The more rooms and layouts I create, the more variety players will get.
I hope this gives you guys a bit more insight to my design process and the various ways the dungeon system can be used. I’m looking forward to sharing a more full-featured version of the outpost soon!