Yeah, that lever to fill the anesthesia canister stumped me for a while too. It blends a bit too well with the machinery so it's easy to miss, since all the other controls are buttons on the well illuminated panel.

Otherwise everything was really fun to use.

Enjoyable quick little game. Very tense and well timed final time limit.

Small bug report: on my 16:10 1920x1200 screen the fade to black doesn't cover the entire screen leaving small slivers at the top and bottom showing the old scene through.

3 frustrations: inaccurate trajectory predictor (biggest one, especially since often you have to thread between close planets, the predictor should be rock solid and accurate!) Not having any idea where to look for &s (and they blend in with fuel since they're same colour). And the explosions linger just a little bit too long.

Post 7DRL update

I've been working on the game some more, giving it some polish and making improvements to start taking it further. I've also managed to fix the performance issues in Firefox, and the messed up graphics on some platforms, so if you haven't been able to try it out because it's Chrome only, you can now do so. The current version is at my website as usual:

http://refractivegames.com/x001/

I changed the game file in the project page to do just that now and made the project publicly visible, but I don't think it ever got added to the 7DRL submission list, even though I created the project page yesterday before the deadline by clicking on the submit button on the main jam page? At least I'm not seeing it in the list of submissions. It should be https://viila.itch.io/x001-infiltrator

You can play the game at http://refractivegames.com/7drl/

Postmortem

It was an extremely ambitious plan, like I said at the start and as can be seen from the design spec. Many of the features got axed. The one I'm most sad about was the hacking to take over other robots aspect. And also sneaking using the Transponder Spoofer. But the result is a minimal complete game and has potential for a good base for future improvements which I'm probably going to be doing after this jam.

What went right?

I'm pretty happy with the codebase. It has some ugly things (mainly how the player stuff is not encapsulated at all, input and rendering related code is all over the place, but for the most part how the robots are constructed in the code I'm quite happy with. Each entity contains a collection of modules which determine how it works. I didn't have time to make any modules beyond the absolute necessities (powerplant, chassis, brain, locomotion and weapon), but I can easily start adding more to that list now that all the code framework is in place.

Another thing that went right was the graphics. I'm very happy with how the 360 degree view looks and works for the player. I feel it's quite intuitive to use after a short adjustment period, for moving around anyway. Otherwise there is a lot of clunkyness in the interface due to time crunch...

Which leads us to...

What went wrong?

I spent way too much time on the rendering code. About 4 days was just getting the stuff on the screen, plus some more here and there. Plus because it is a free space game as opposed to strictly grid game, I had to implement collision physics which didn't take too long, but still was something that took time. Also spent time working on features that never made it to the final product, like the moving doors and destructible terrain. So effectively that time was completely wasted for this jam. (But it's there for the future now.)

But the whole carrying idea of the game is the unorthodox viewpoint, everything else follows from that. So it's kinda, yeah I had to do a lot of that work, but I could have just left it at plain walls, instead of the fancy indented walls and tiles. That would have cut the graphics engine work in about half and left me a lot more time to make a more nuanced and balanced and deeper gameplay.

So, the big failure was time management. An nothing illustrates that more than the fact that it wasn't until 30 minutes before deadline that robots shot back at you, 20 minutes before deadline that I had a lose condition and 10 minutes before deadline I had win condition. So it came literally right down to the wire whether this was a game at all and thus whether this was a success or failure.

I intentionally overspec'd the scope because I wanted to be ambitious, but I should have prioritized better. Like there is no level generation at all, the level is just each block as 33% chance of having a random tile placed on it or not. This was the bare minimum I needed for the testing and, well, never had time to make it better. (I did however come up with clever abuse of the A* pathfinding algorithm to make sure that the level is beatable so that no robot is spawned in an area that is inaccessible. Since killing all robots is the win condition.)

Also, technically this is also what went wrong: the choice of language. I picked Javascript and HTML5 using P5.js library because I wanted to learn these techs. Some things were very painful to do and took a lot longer because of that. Plus I know there's a lot of incompatibilities due to the approach I picked at start. I can fix that, but it requires redoing a lot of code, so couldn't do that during the challenge. So right now the game is Chrome only (though some people have had good results with Firefox on Linux), and even then on some machines the graphics are broken due to them doing pixel sampling differently (because of course they do... what isn't inconsistent between browsers...) But one of my goals was to learn these techs and I did learn, a lot. So teachnically bad decision for perspective of getting the game finished, but one that I had other reasons to make.

The last day

Hoo boy was the last day hectic. I came to it with an engine and the framework code, but was completely lacking gameplay. So during the final day I implemented weapons, made weapons shoot, made droids take damage, made droids have personalized behaviours (combat droids patrol, sentries guard, messengers and service droids deliver messages and work, and roomba cleans), made the combat droids able to (mostly) intelligently hunt for the player once they see you, and of course victory and lose conditions.

If there had been even just 20 minutes more I would have added a self-repair module for the player which I always wanted to add to make sure that the player won't be permanently crippled if, say, their hover module or power source gets blown up. In other words, make the player heal. So right now you can end up in a almost certain death and almost certainly impossible to win situation where you're just stuck in place. Not good for gameplay. Alas. Didn't have those 20 minutes.

Also didn't have time to make the neutral droids (yellow) start attacking as well after you shoot at them and they turn hostile (red). They are armed, just that their brains have no behaviour defined for attacking. Only now I realized that I could have just replaced their brains with the combat brain in the event they become hostile. Oh well.

From the very limited playtesting I manged to do before deadline and testing I've done after, I do feel that there is a kernel of a good game in here, so I'm gonna keep working on this in the coming weeks. And hopefully I manage to fix my Itch.io page, so you can play it here as well, not just on my own server.

Final credits and thanks

Big thanks goes to Lauren McCarthy and the P5.js community for making the P5.js library. Brian Grinstead (with contributions from Marijn Haverbeke) for the A* pathfinding library.  And possibly most importantly to David Griswold for making P5.js work with MSVC Intellisense and typescript type hinting. Without that, I'm certain this project would have been complete failure (because it would have taken me a lot longer to code anything and keep everything consistent).

FINISHED!

Like, few minutes to deadline. Upload to Itch.io doesn't work, I'll see if I can fix that, but in the meantime you can play it at http://refractivegames.com/7drl/

Destroy all robots, try not to get killed yourself. 

But phew. This last day was... something. Had to axe a lot of stuff, but it is minimally complete game. It has victory and losing conditions, randomly generated levels, and permadeath. Refresh the browser page to play another game.

I'll do a proper devlog once I've caught my breath.

I finished with minutes to spare, but the zip I uploaded doesn't work in the Itch.io project page (gives a really weird error from the library I'm using, so I have no idea how to fix that), so all I can do is point to my own webserver where it's hosted: http://refractivegames.com/7drl/

I hope that still counts as finished and complete?

Today's big thing was turning THIS into THIS.

And furthermore THAT into THIS...

So. A lot of work getting systems up and created, and then tying it all into the user interface. In the meantime, I decided that I'm not going to worry about screen scaling, so only 1920x1080 or larger will be officially supported for now. In the interface select mode (arrow icon) works, and lets you select droids on the screen. Aiming mode (crosshairs) does nothing. Moving mode (forward icon) obviously lets you move (left click moves, right click waits in place).

Still a lot of work to be done... We'll see how much actual gameplay I can implement in the remaining 22 hours... Crunchtime... My deadline is basically the official deadline counter, since I didn't start coding until Monday. So, this is probably my last update before the release in 22 hours or so.

As usual, latest version up at http://refractivegames.com/7drl/

Previous snapshots:

http://refractivegames.com/7drl-friday/
http://refractivegames.com/7drl-thursday/
http://refractivegames.com/7drl-wednesday/
http://refractivegames.com/7drl-tuesday/
http://refractivegames.com/7drl-monday/

Not a whole lot visually different today, but a lot more different under the hood.

I have multiple entities with different brains acting independently. And they are created in data-driven manner from JSON prototypes. The roombaHover Cleaner moves randomly, while the B902 moves purposefully, navigating the map with pathfinding. For that I brought in Brian Grinstead's A* library which integrated relatively easily. 

Another biggie achieved today was collisions. The droids can collide both with the map (causing the roomba to change direction), and with each other (with larger droid pushing the smaller droid out of the way.)

So, now the droids have a mind, physicality and can navigate. Next is adding functional modules, including weapons so we can finally have some combat. And hook that stuff up to the user interface for the player's droid.

I probably won't have time to make very good gameplay, but I'm relatively confident that I can in the remaining time make something basic and functional, if not necessarily fun. To make this deep enough I would have to make a lot more complicated behaviours for the droids that the player can exploit and fool and I probably won't have time to do that. Still, got almost two days on the clock left (started the coding very late in the starting window) and I'll be making use of every last second of that.

As usual, current version is up at http://refractivegames.com/7drl/

Previous snapshots:

http://refractivegames.com/7drl-thursday/
http://refractivegames.com/7drl-wednesday/
http://refractivegames.com/7drl-tuesday/
http://refractivegames.com/7drl-monday/

I lied again. Instead of level generation I worked more on entity code and also getting entities on the screen, which is kinda important..

Not sure how I'll handle enemy facing, since I can't really make multiple sprites to cover all angles, especially in the remaining timeframe. Theoretically the enemies also have 360 degree LIDARs, so facing isn't that important for "sneaking" around, but it would have potential impact for weapon firing arcs.

I will almost certainly cheat for wheeled robots and allow them to turn in place at the very least, if not ignore the movement direction restriction, at least when they're under AI control. The AIs may cheat otherwise as well, purely because I have only couple days left to implement all of their behaviours and combat and I haven't even thought about the robot hacking...

Again it's late and I'm in no condition to code anymore today, so I've been drawing some more enemy sprites. Leaving those as surprise for now. As for robot stats... data organization is always a big problem, but will have to just do something and forge ahead with whatever works well enough.

For combat, I'm thinking each part of the robot has individual hit points. So the chassis has HPs and if that is destroyed the robot is destroyed. But for B902 there legs would have HPs (and if they get destroyed mobility is hampered), weapon mounts would have HPs, the weapons themselves would have HP, power supply has HP, and sundry systems (IFF module, transponder reader etc.) each have HPs. When you shoot at the robot and hit him, your damage gets dealt to a random system. Either purely randomly, or weighted according to their HP amounts. So large, high HP systems are more likely to get hit.

And same will apply to your own robot. So, more modules you have mounted, the more resilient to damage you become. But if any module gets destroyed then you lose that functionality. I think your own robot will have built-in self-repair capability, so destroyed locomotion or destroyed sensors will not mean immediate game over, you'll just be stuck in place for a while and blind for awhile. (Though in such a situation you are very vulnerable.)

Tomorrow's agenda:

• Moving enemy entities
• Pathfinding (I found a nice looking A* lib, so probably will use that.)
• Data driven entity creation
• Modules and functionality
• User interface work

As usual, today's live test at http://refractivegames.com/7drl/ (Chrome recommended, Firefox may be too slow, though some people on Linux reported acceptable performance.)

Previous snapshots:

http://refractivegames.com/7drl-wednesday/

http://refractivegames.com/7drl-tuesday/

http://refractivegames.com/7drl-monday/

Added a whole bunch of different tiles yesterday after I was too tired to code anything. So now there will be a variety of decorations and machines to make the levels look more interesting. But while testing I also discovered that on one of my laptops the game graphics break badly... I know why, but I have no idea how to fix it. For whatever reason Chrome on that machine is doing pixel sampling differently using interpolation. So if you test and the graphics look dark and distorted, I'm sorry, I probably won't have time to fix that within the 7DRL.

Regardless, here's how it should look.

I used a subtle colour palette since the droid you're controlling technically can't see colours, so in the image they're standing in for the different ways the surfaces reflect your LIDAR back, giving your droid some idea of the surface features. A few items are coloured more strongly, because they will be functional elements. Doors also open and close, which is cool. (Constantly for now for the test.)

You can see the test for the tiles at http://refractivegames.com/7drl-tiles/

Next up, level generation.

Forget the agenda. Instead I went down rendering code rabbithole some more. Improved the algorithm so the results are mathematically exact (as exact as floats can be), which also made it work faster. Then nullified all the speed increase by implementing more complicated terrain. Turns out the approach I used really sucks in Firefox, so for now the game is Chrome only. I don't know if I have time to fix the performance problems on Firefox. Getting some actual gameplay next is higher priority.

Also... all of this allowed...

Destructibe terrain!

In addition to boom boom, this will allow me to have functioning doors in the levels. If I have time to implement such.

Control of your droid is by pressing mouse in the viewport window, the cursor changes into an 'ahead' arrow. Your droid will move towards the exact direction you're clicking towards. This is basically how the "hover" and "omniwheels" locomotion types will work. Will have to figure out how to implement turning for the directional modes of locomotion. There are extra 45 degrees duplicated on each edge of the viewport to make it easier to visualize what's directly south, since otherwise there's a discontinuity in the view.

Also, gave some thought about victory conditions. I think each level will have a specific objective for you to accomplish:

• Destroy all Power Cores
• Eliminate specific droid
• Hack 4 computers
• etc.

After you have accomplished your objective you can head to the next level using an elevator. Not sure if there will be an ultimate goal, might just make it that you have to get through 10 levels. Or something like that.

Ok, tomorrow's agenda is whatever I said yesterday...

• Finish making the entity code
• Start making proper map generation
• User interface work
• Add enemy entities even just placeholders

Latest version again up at http://refractivegames.com/7drl/  (Chrome only)

Previous snapshots:
http://refractivegames.com/7drl-monday/
http://refractivegames.com/7drl-tuesday/

This is all looking really great. Is it possible to extend the rules for multiple players? (I realize that would mean adding balancing options, so probably not within the 7DRL, but could that work in principle?)

That's a pretty cool idea. It's like every sound you make you advance one note in a song. The tempo would be totally dependent on how much is going on on the screen, so it would be adaptive to the mood as well. Moving frantically when lots is going on and slowly when you're sneaking and not causing sounds or standing still and thinking, etc.

WHY MUST LAYING OUT ANYTHING IN CSS BE SO %&¤"#¤" DIFFICULT...

ahem

I mean,  worked some more behind the scenes, laying the foundations for the entity classes and stat displays and whatnot. Refactored the drawing so that the map and viewport are separate HTML5 Canvas objects and started prototyping the interface (not much, but I have a dynamically updating HP indicator. It's random, but dynamic!). Ignore the colours, they're just to show the sizes of the <div>s and such.

The viewport also now resizes itself to fit the window on page load. I'll try to accommodate windows of different sizes if possible, but no guarantees that anything but 1920x1080 will be usable.

Dragging on the map moves the viewpoint around, revealing the map according to the scanner view. (Yes, I know the corners leak, that'll be fixed if I have time.) The generated map is faintly visible as debug aid for now.

Latest version again up at http://refractivegames.com/7drl/

Tomorrow's agenda:

• Finish making the entity code
• Start making proper map generation
• User interface work
• Add enemy entities even just placeholders

Previous snapshot of the game's state from Monday: http://refractivegames.com/7drl-monday/

Worked on some quick and dirty testing for the raycasting algorithm while getting a handle on my programming environment (P5.js). The algorithm is braindead, but it'll do for now for testing. I'll make it smarter if I have time. Next making some entities for player and other droids.

You can test drive the raycasting prototype code at http://refractivegames.com/7drl/

Play the 7DRL or updated current version of the game: http://refractivegames.com/x001/

------------------------------------------

A very ambitious plan, we'll see how much I can manage to implement of this. The main idea is the unusual viewpoint the game will be played from, a 360 degree raycasted view.

You're playing an infiltration droid trying to fulfill an objective (take over a ship/base, destroy everything, etc.)

The catch is: you're a robot. That means your sensors are limited to what your infiltration unit or the robot you're controller has.

The basic sensor is a 1D LIDAR, which means your view of the world is 360 degrees, but limited to just distance to object information. More advanced sensors allow you a more nuanced view of the world, including modules that augment the display.

The game is realtime, but time doesn't advance unless you're performing an action (movement, shooting, etc.) This simulates the fact that as a robot you can think extremely fast.

Advancement would be by adding modules to your robot, or taking over more advanced robots. For instance, a battle droid might have an IFF module that adds tag information to your LIDAR view identifying whether the obstruction is inert, friendly or hostile. (Colour coded display)
A mapper module enables you to see a top down map of your surroundings that your LIDAR has mapped.
RADAR allows you to see through obstructions, including walls.

And different droid chassises would have different modes of locomotion and different weapons. Some might require you to turn your entire droid to face the target, others have slewable "turrets". Locomotion includes hover/omniwheels (any direction), legs (faster forward, allows sidestepping), wheels (forward/back only) and tank tracks (allows turning in place)

Your droid is equipped with short ranged hacking capabilities that will allow you to take over other robots' chassis, giving you access to their (hopefully) improved sensors and armaments. Have to decide how this plart of the gameplay works still.

Right: Main viewport 1D LIDAR

Left: Mapper module map of the same situation (droid is in a north-east-south intersection with an enemy up ahead north)

Sensors:

• ultrasonic (short range, extremely low resolution)
• 1D LIDAR (moderate range, shows only distance to obstruction at each point)
• 2D LIDAR (longer range, shows an actual 2D image)
• RADAR (longest range, backscatter mode sees through walls)
• Some robots don't have full 360 degree FOV, they show only a smaller cone view

Interface modules:

• Mapping module
  • Draws map based on the scan from the main sensors

•  IFF module

  
  

  • identifies whether the items are inert, friendly or hostile (colours them in the view)

•  Transponder Reader 

  
  

  •  Class 1 shows robot designations on HUD
  •  Class 2 allows recording a robots complete electronic signature

• Transponder Spoofer

  
  

  • Allows spoofing own transponder with transponders recorded with the Class 2 reader
  • The dumber a robot is the easier it is to be fooled by a transponder
  • Using a wrong type of transponder is suspicious (civilian in military area, non-maintenance types in maintenance areas, etc.)
• Other modules

Locomotion:

• Hover (robot can move in any direction, turn in place)
• Omniwheels (same, but slower, turn in place)
• Legs (Can move in any direction, turn in place, but much faster forward)
• Wheels (forward/back, has turn radius)
• Tracked (forward/back, can turn in place)

Armament Mounts:

• Fixed mount (requires turning the entire droid)
• Slewable turret (independent aiming)
• Handheld (very fast turret with limited slew angles)