portal os, niche legends, and u can put ur couch in the torpedo tubes

03/19/2017 -

Hey, Mugalo.

This week & last week, we worked on a user interface for the game.  Since we now have a (slightly) more concrete vision for the gameplay and game-modes, putting together a high-level UI was a manageable task. We definitely are not done w\ this, but I feel like it is good enough for a prototype. Basically there are several buttons that run along the top of the screen. These allow you to access the various game modes, check on the status of your character, and (in a meta-sense) check on the status of the simulation. Of course, these buttons will become inactive or active when those game modes are available. The design is based on the “Portal Os” — an operating system created by ancient beings which allows users to access an ancient simulation. This simulation has been running for thousands of years, and within it lies an entire galaxy of simulated lifeforms. The Portal Os allows you to control (hijack the minds) of a handful of characters living within that galaxy.  Because of all this, we thought it would be cool if the main UI was an emulation of a bizarre alien operating system. Portal, walrus, sum:  we’ve got strange symbols and an OS emulator .

~Niche Legends~
I figured I could create a hidden little area — within these posts — something that wouldn’t take up too much space — or be too distracting — just a cool little spot dedicated to niche legends. Featured this week, “Dingonek” — also known as the jungle walrus. Said to dwell in the rivers and lakes of western Africa, the Dingonek has been described as being grey or red, 3–6 m (9.8–19.7 ft) in length, with a squarish head, sometimes a long horn, saber-like canines—which has resulted in its nickname the “Jungle Walrus”—and a tail complete with a bony, dart-like appendage, which is reputed to be able to secrete a deadly poison. – Wikipedia. For those interested, there is a cave painting of dingonek.

Its pretty obvious in the title but yea, we are also trying to build a system where you can put pretty much anything in a torpedo tube and shoot it.

Finally, here are some pics & video from the UI work this week!







moving units, pathfinding algorithm, pablo cruise

03/05/2017 -

Yo-hay choy-folk! (Yo bro, it’s sunday.)

We did a bunch of work on the planet-mode this week. We are simultaneously developing a planet/asteroid editor and the ground/non-flying part of the game.  These little worlds are not necessarily planets, but may be asteroids, large cheetos, or moons — any solar system body that you could presumably land upon counts. Yup — giant cheetoh still makes the cut — because of the magnitude of the cheetoh.

So when you land on a planet, a number of odd things could happen. First you may be crashing. If that’s the case your people may be scattered across the planet with limited life support and various injuries — perhaps clinging to their tattered escape pods. If you managed to land with safety, you’re probably on a mission to gather some resources or otherwise survive until you can continue your journey toward Lilith.

Regardless, you’ll essentially be manipulating a small team of characters (six at most). This might be vaguely similar to the gameplay in the XCOM series, but it will also have heavy survival elements, resource gathering, and other general strategy mechanics. It won’t play as fast as an RTS, but it will play out in real time (as shown in the video) — and the goal of that is to generate slower and more deliberate choice-making — while still forcing the players hand with regard to the clock. This is — ofc — a permadeath game — we can’t have things move too fast!

Nerd point: The unit movement required an implementation of the A* path finding algorithm. uhh-shhhh-ok.  just sayin. maybe am a pro. maybe a pro pulls that off.

maybe pablo cruise underrated. But yeah anyway, here’s a video showing a unit moving across the planet. I’m not sure if these speeds will remain the way they are, or if the map tiles will stay the same size that they are now. That will require some play-testing and horse sense to get right. Hopefully this just gives you an idea of the general gameplay / movement mechanics:

And here are some other pictures form the week:









Corporate Announcement

02/20/2017 -

Here at Jun and Pate, we celebrate Good Eezma (corporate buzzword in 3218). Therefore, we are taking first-person flight simulation to the next level — by putting the flight-person first. Please go find a snack like nachos and enjoy this game science video demonstration:

Okay enough of the soulless corporate buzz-chat. I’m here to talk about synergy.  Pate and I have been friends for a long time, but finally, we are finding a remarkable creative synergy. Why is this? We’ve cut our costs, we’ve bolstered our revenues, and we’ve built professional relationships that can last.

Sorry for being cheesy! I only wanted your everlasting empathy-friendship!

Ok well, this week, I worked on gameplay. I’m trying to get galactic flight to feel both real, fun, and unique. It’s a real venn diagram situation, and decisions, at times, feel tricky. It takes a weird amount of trial and error to find things that are satisfying in this regard — things that lovingly please the three circles — as they say. But hopefully, we’ll be able to come through on that.

To that end, I’ve limited the amount of thrust-drift (for fun reasons), added clouds & matter to space, and have begun working on the position-hold autopilot mode. Yes fine — flight mode is coming together. I want to make these planetary approaches a bit more engaging though. To me, all these little things sort of collaborate to create what is effectively a nifty toy (a flight simulator). Landing is a big part of other flight simulators, and while that is not required in space, it would be fun to “land” on stars. This is weird, but it’s one of those things where being able to crash (burning up in a star’s heliopause) can raise the stakes and make the gameplay more captivating.

good bye sweet cherrios, good bye you grainy rings…

autopilot, flight controls, game science, and navballs

02/06/2017 -

Chay ho! Let’s talk some game-science. Hehe, ok — backstory about that phrase — I actually discovered a game development studio who had the courage to call themselves a “Game Science” Studio. So. I don’t want to make it sound like we don’t do scientific research (um. we go on wikipedia) (and try to stay within the bounds of “realism”), but making this game is very disconnected from things which could be considered “doing science”.

This week I built various things that thicken the flight-simulator aspect of the game. There are gauges, flight controls, autopilot modes, and a realistic physics system driving the whole thing. This is excites me, but visually — is not so much to stare at. Buuut, the whole flight-simulation is now realistic enough to cruise between stars, and that’s enough to start doing some goof-play world building — yes — pete is working on these first planets which will seed our galaxy. He is also doing some music (potentially) for next week.

Yeah. This UI is complicated, but hopefully more realistic and interesting. Fortunately, the ship computer makes flight quite simple — and after a bit of practice its pretty fun to play with. Of course, if things go south (ship computer breaks), you will have to worry about retrograde burns, momentum, and attitude stabilization – holy space forks. You also have to worry about Solar Power, and Space Dust Resistance — which is an all-the-time job — so, better have redundant ship computers. Or be the hottest stick in the galaxy.

Ok… I’m going to try to explain the major Flight UI components now… sorry.

This is the radar. For now it shows where solar power and space dust resistance are (relative to the ship), but in the future it will show many more volumetric-like effects: dark matter, electric storms, and other made-up space weather. Navigation is intended to be important, and this is only a small tactical radar map. More serious navigation \ planning modes will probably take up the whole screen.


Velocity & Acceleration vectors. These vectors help you control your velocity. Ships in space build momentum, so you need to know where you are drifting, where you are burning, and where you want to go. Blue is the desired velocity (controlled by pointing ship and choosing a speed — see below). The red is your current velocity. And the green is the way the ship computer is going to burn the engines, such that the red and blue become the same. Effectively, this means that the ship computer will help you go where you point!


This red button enables that velocity autopilot. When enabled, the green vector is used for burns. When off, you just burn in the direction you are facing (not great when it comes to erasing any momentum you may have). The throttle controls the engine’s burn rate, and the velocity controls your desired velocity. The autopilot sometimes takes control of these. They are important for slowing down so that you can safely enter solar systems.


These are various attitude indicators (pitch-roll-yaw scales, the navigation ball, and the mouse fly controls). When in mouse-fly mode, you use the mouse to control the ship’s attitude. You can enable stabilization to stabilize your attitude. This is important for flying to specific points. The navball is basically a 3d compass which allows you to fly various headings in space. My Kerbal space friends will find this very familiar.


Finally, here’s a video showing it all running at once. I highly suggest clicking the little gear and enabling 1080p High-Def mode.




wild pythons playing together (a.k.a. UI design)

01/22/2017 -

Chay ho (hello), moon dwellers. Bonsino (I love your hair). Here are some updates regarding week 10 of our game-science adventure.

Pate sent me these beautiful space-country audio trax — which is a genre that I’m new to — like most people — but if you’re still resisting — make a U-turn baby. You probably won’t get upset. Unfortunately, these are scratchy audio songs that are works in progress, so they are not ready to be heard. But NEXT WEEK, we will post some audio. I swear this on the grave of Rue. Not a lot of people know this, but after the hunger games ends, you know — the child battle stadium (CBS Arena) is still there. And ha – well — it’s pretty much abandoned — so there’s a ton of loitering there — kids just doing nothing. Just.  Doing nothing, totally disrespecting the historical significance —  drinking their soda beers — they’re doing nothing — playing beyblades.

I built widgets. These are various UI components that will be used for flying \ piloting your ship. But don’t jump out of your computer chair. First of all, the current plan is to have six different operating systems in the game — three versions of Jundows and three versions of Pateintosh. So although you see one style of the widgets here, there are probably going to be more versions of the same basic flight components in each of the operating systems. There is alot more to do.

The other thing is that although we have much visual progress here, there is still a ton of work to do when it comes to organizing these code files. I’ve been coding like a whimsical forest ant — stuffing apples into dirt holes — without keeping track of anything.  I have three major systems of code to integrate right now, and the longer I wait, the worse this task (might) get. There’s the engineering models (how ships are designed \ fail \ degrade), the flight models (which deal with physics, flight planning, and flight controls), and the user interface (which requires multiple levels of abstraction so that players can tweak their version of Pateintosh to their liking).

Anyway, it all feels like a crazy endeavor. So much is still disjointed — there are many shifting components — but each week, a few things seem to fall together — which is nice and well. Sometime in the mildly-distant-future, I imagine the code will begin to solidify like cream of wheat.  From there — it will be all about content & more isolated features. I’m excited to get here — to have a foundation. There are definitely parts of the code that are maturing and calming down. But most of it still seems like wild pythons playing together. It’s truly anti-jun to continue working in this winding mess of growing code. So next week may just be pictures of elegant code, haha.

Anyway, here’s a video, and some cool pics.



a_serious_screen_shot charging_bats hdg_tape  uiwork