next »

[TomHunt]

gameplay:

current (minimal / pre-alpha):
- primarily arcade/action-focused two-stick shooter
- roguelike-style FOV lighting on subterranean levels
- multi-world universe
- levels, worlds, and universe are procedurally-generated
- each world is several level deep, with each level concentrically layered on top of the levels below it
- world navigation is gated through traversability of world links (undecided if this will be through some kind of items or keys or just checking to see if you've blown up all the robots) (probably the latter bc thats simpler)
- bots are all randomly generated - variation is only cosmetic r/n
- local/splitscreen multiplayer - very simple competitive deathmatch-style game mode

===
This is something I've been working on lately that is based off an earlier project. That project had stalled on figuring out a good progression mechanic and I ended up moving on to another project. The code still works, though. I just needed to figure out a way to make it fun.

I thought it would be cool to have this cube world exist within this bigger universe, and also to have subterranean levels that are kinda roguelikeish, and then have the player run around in that. On top of this, I semi-randomly decided to just implement a Robotron-ish twin-stick shooter game with robots.

And also try to add some kind of a backstory to the thing, to put everything into context: the cube-shaped worlds are efficiently-produced space hab modules with malfunctioning robots that are trying to kill you.


The original idea was to make something more along the lines of an exploration game or some kind of adventure or action-adventure game. Seeing as I don't really have 2-5 years to spend on building out such a massive game, I opted to make something more arcade-y.

I would like to keep the procedural-generation elements to make a roguelike twin-stick shooter set in this playspace of multi-layered cube-shaped worlds that are all connected to each other via portals.

Adding the bots, shooting, and screenshake has made this a pretty fun thing to play around with already.

Bugs popping up everywhere tho as I repurpose 2-3-year-old code to do things it was not designed to do before. Tracking those down, zapping them.

Also I just added some audio to the game (thanks, Nickelpunk!). Now just fixing bugs to hopefully get to something I can show either to Steam:Greenlight or just throw up on itch.io.

The AI still needs a lot of work. Multiplayer would be pretty awesome, if I (or someone) could get around to doing that. Folks playtesting the early builds have been giving me lots of great feedback, most of which is either sitting in my notebook or is in some list in the game's Trello board.

The level geometry was done by a contractor who would later tell me they are not actually that great at modular geometry (thanks for the heads up). Just fixing it will probably be cheaper in the end, but I will have to get around to doing that (which is sort of why i hired a contractor to do those in the first place ) So there's that.

That aside, the core gameplay is mostly there. I've got the player shooting robots, robots taking damage and dying, and the player dying when they get hit (nerfed for now, until other bugs are worked out). Various bugs to track down and fix before adding any more cool stuff. I'm a little hesitant to do a release just yet, or even showing a choppy GIF that does no justice to the game's framerate, but I did want to show a little something of what the game looks like right now. Maybe later I will make a proper video to show off the framerate a little better.

Judging by the reactions I've been getting just by rattling off "twin stick shooter roguelike metroidvania" in conversation, though, I think the core bits should be pretty fun on their own. Still not entirely sure how I plan to release this thing..

Anyway, I guess I'll be on here a little more often now

[TomHunt]

- fixed a couple of the rotation glitches on shots and bots
- figured out how to record animated gifs properly

[Cakeprediction]

Sick

[TomHunt]

getting everything to generate on startup did expose one small thing i had neglected to implement, which is actually generating multiple random interlinked worlds from some kind of singular event or function call.

what's more, in trying out a simple, naive implementation of this (which i figured is what would all be needed), i realized that i need to completely get rid of my SendMessage usage in my editor calls. while not a core part of the gameplay, having SendMessage usage in my procedural generation callchain, which gets called in both the editor and at runtime causes numerous non-fatal-but-scary-looking error messages to fill up the console.

the procedural generation code is editor-accessible mainly for development/debugging purposes (much faster to just click buttons and type into fields in the editor than have to fire up the game each time you want to test something). as an added bonus, it may also help to keep the procedural generation code useful even if procedural generation at runtime turns out to not be such a great idea. being able to quickly generate levels in the Unity editor to start from, in the event of having to create static levels, would be tremendously useful.

so today i've been reading up on Unity's EventSystem in order to try and covert my SendMessage usage over to the EventSystem way of doing things. the core functional programming parts of it were easy enough to wrap my head around. passing of parameters seemed a little tricky (e.g. undocumented) but that turned out to be simple enough:

So, the call

Code:

SendMessage("OnSomeEvent", someParameter);

becomes

Code:

ExecuteEvents.Execute<ISomeEventHandler>(gameObject, null, (x,y)=>x.OnSomeEvent(someParameter));

plus a definition of interface ISomeEventHandler that inherits off IEventSystemHandler, which the components responding to this message then implement alongside MonoBehaviour:

Code:

public interface ISomeEventHandler : IEventSystemHandler {
  void OnSomeEvent(SomeParameterType someParameter)
}

public class ClassThatRepsondsToSomeEvent : MonoBehaviour, ISomeEventHandler {
  ...
  public void OnSomeEvent(SomeParameterType someParameter) {
     // implementation goes here
  }
  ...
}

..and then the same event runs both at runtime and in the editor with no fuss from Unity (and also is a bit more rigorous and less error-prone than SendMessage)

pretty much just doing a whole bunch of this today/tonight/maybe tomorrow, repeated over and over, until I can generate universes in the editor without the editor spitting out a bunch of meaningless error messages that blend in with real error messages.

the actual universe generation should otherwise be relatively straightforward. generating levels and worlds is pretty much done, although could maybe do with a little bit of interface tidying. one thing i will have to implement is procedural world link generation. this might turn out to be trickier than it looks on the surface, but i think i have a solution for it in my head.

[TomHunt]

Sick

Thanks!

[TomHunt]

Working on getting the core mechanics to be as solid as possible. The graphics still look a bit shit, but people seem to really like the concept of the game and also how smooth the it is, so I'm going to focus on those things for now in order to get something minimal working quickly. Not sure yet if I want to do some kind of early release or not.

Spent much of today debugging through the side-switching/cube-flipping trigger mechanism. Since the original LDJAM game and Daedalus Cube, I've had to make this work in more general cases, and this has introduced some issues around how I calculate some of the data that before was assumed to be some constant value or some singleton somewhere. There are a lot less of those now in this version (and also LOADS more features, obv). So, things are a bit more complicated, even/especially at the inner levels where all the little mathy tricks live.

Fixed one bug. Uncovered two or three more.  #devlife

Oh well. Heading home to get some sleep and then back at this again tomorrow..

[rj]

this looks fucking rad

[Capntastic]

I want to play this using the Lawnmower Man VR chair

[TomHunt]

this looks fucking rad

thanks!

I want to play this using the Lawnmower Man VR chair

i had no idea what this is, so i googled it, and was disappointed to not find any for sale :C

[rj]

have you played dreamcast q*bert , by any chance

[blekdar]

Huh.

Well this is pretty neat.

[TomHunt]

Been a couple of weeks.. thought I'd post an update here.

The past week and a half has been spent mostly either at PAX Dev, volunteering at PAX, or recovering from the combination of both.

I have been working on splitscreen local multiplayer, which, as I've found is par for the course on multiplayer, involves a bit of separating out of things that you normally don't really think about keeping separate. So, there was like a good afternoon or so worth of just cleaning up the project directory - there's about 10k files in there! - scoping all the stuff that is actually mine into its own folder, and then focusing my Sublime Text project on just the Scripts subfolder of that.

made attempt #2 today at contacting Rewired dev to resolve issue with Unity Linux editor - Rewired.ReInput.players keeps coming back as null. It only does this on the Linux editor (which happens to be where I do most of my work), so Rewired is pretty much useless for me right now, despite all the good things I've heard about it, as well as its advertised Linux support.

i guess for now i'll just go ahead an implement a fallback solution using robotron-style controls:
player 1: WASD + FCVB
player 2: IJKL + ;./\
player 3: dir keys + numpad(8456)

Also there's one other little thing that I would really like to work in this weekend, because I told someone that I'd add it. I don't want to say/jinx it right now because I still have the splitscreen-multi refactoring to finish up. I'm going to try and get a solution for that working today, at least. I think I've got the views just about separated out enough to go ahead and add the actual viewport splitting. :fingerscrossed:

[TomHunt]

got Rewired working - between reinstalling v1.0.0.101 fresh and going back through the setup instructions in detail, things started to click. i am ok with this.

now, to get just multiplayer working...


what i have been finding is that even a modest amount of modification to the existing single player game isn't enough to "just add multiplayer" - you really have to go back to the drawing board and design the thing from the ground up to be a multiplayer game.

fortunately, i've already modularized a whole bunch of the code anyway, for various other reasons, so retooling things to work in a multiplayer context is probably a little more surmountable now than it may have been maybe a few months ago. there's still a bunch of spaghetti code to detangle, and a few new systems to design and write and also i need to fully wrap my head around Rewired and integrate that into the code.

for now, i'm just shooting for a playable prototype with multiple gamepads. no keyboard input right now. that will come later.

also i thought of using the superscript 3, as in "cubed", last night. the nature of the game keeps shifting around and evolving, but the one thing that has stayed constant is that it is all around cubes. in fact, most of the time when people ask me about the game, they refer to it as "that cube thing you're working on". so, "cubed" it is. □³ is a shortened, stylized form of that, which happens to be all in non-ascii characters. for googlability, i'll have to take extra care to also link "cubed" as a keyword / meta tag to any pages i create for it. '^3' also works, if copy/pasting □³ or entering the unicode codes (HTML: '□ ³', hex: '0x25A1 0xB3', dec: '9633 179') isn't your thing.

of course, that could all change, too. i do have a history of picking horrible names for games. but, i think it's kind of a cool name, FWIW. so, i'm making that the working title, for now.



anyway, multiplayer. so i've created a new unity scene, and am going through and grokking the Rewired docs. i want this to be a sort of "hello world" type thing that is going to be a rudimentary lobby for the players to join in the game. this will set up a DontDestroyOnLoad object hierarchy of player sessions, which store who is what, which controller they're on, what color they are, etc. this will then get fed into the main game scene, which will then see the multiple PlayerSessions and then know it needs to split the views out into however many viewports it needs, which are then arranged in a grid around the screen.

for now, i'm vaguely assuming just four controllers, but have a stretch goal of 16 controllers connected simultaneously. if i can get bluetooth gamepads working (and that many of them connected to the same machine), then this should be no problem. otherwise, i may need a USB hub or two to turn my demo machine into something resembling a squid of wired gamepads. i do not plan to do any sort of networked multiplayer right now, but wouldn't rule out LAN play at some point. internet multiplayer would require another level of code rewrite, and i don't have the budget for that right now. i might do that as like a [insert funding source here] stretch goal, or something. i think that for now, for what i would like to do with the game at this time, focusing on local/couch multiplayer is best.

i'm in jam mode for at least today, and probably tomorrow and maybe even thursday as well. i made a bunch of burritos last night (egg/bean/cheese and rice/bean/cheese), got some bread & PB & J at the store, a couple bottles of of mexican aka 'real' coke, a can of rockstar recovery lemonade, and a can of lemon-flavored guayaki iced yerba mate. i drink the rockstar and yerba mate very watered down, both to extend them and to keep myself hydrated and energized throughout the day. i've also got a small supply of snacks that i bought at a Daiso a couple weeks ago and have mostly left in the fridge since then. i took the whole bag of them out of the fridge and have them by my desk now, both to make room for the other stuff i brought in there, and to have these ready for whenever. we'll see how long this all last. hopefully long enough to get this stuff working in time for thursday.

[Eluardian]

This is just the neatest thing.

Good luck with the healthy and absolutely not in any way self destructive dev period you're forcing yourself into for the next few days. 

[TomHunt]

This is just the neatest thing.

Thanks!

Good luck with the healthy and absolutely not in any way self destructive dev period you're forcing yourself into for the next few days. 

not to worry. this is strictly temporary. otherwise certain IGDA folk around here would probably tell me the same thing, to my face, sternly, the next time i see them around at a social event around here. i know better than to crunch too much, and have felt the effects of such before and know that my body just cannot handle more than a few days of this.

right now, though, there's a hard deadline, and i need to pull up and hit the afterburners on this thing.

also there's a nice big bottle of beer waiting for me at home for when this is all done

[TomHunt]

splitscreen multiplayer is working. this took a lot longer than expected and involved a pretty substantial amount of refactoring of the code in order to support rendering the same objects from multiple camera systems that each render to a different viewport on the screen.

implemented a very simple competitive deathmatch mode on top of this. ran a playtest today at the workshop. it was kind of spur of the moment and I didn't set up any gif-capture, but I did get some pretty solid feedback on the game. also it was really cool to actually play a multiplayer game that I had made with a few people gathered around my computer.

i will likely demo/test it again tomorrow, and make sure to capture some gameplay.

[jamesprimate]

excellent concept 

[maruki]

That looks super fun!

[quantumpotato]

Looking great. How are you liking Unity camera & rotation controls?

[TomHunt]

Looking great.

excellent concept 

That looks super fun!

Thank you! I really appreciate all the positive feedback this game has been getting!

How are you liking Unity camera & rotation controls?

Not sure I if understand the context of the question.. They're pretty good, I guess?

The camera/rotation uses this funky orbital system and lots of "gyro" transforms all over the place. Knowing which way is up is a persistent technical issue that I solved years ago in the earlier incarnation of this. It does make things a bit more complicated, but I also have a bit of helper code that handles most of that complexity.

Things got even more complicated when moving to splitscreen views (one reason why that ended up taking so long to implement), since now there are multiple camera systems. Fortunately, I had already transitioned a lot of the code over to an MVC architecture, so adding the extra viewports was primarily a matter of adding extra 'V's to that, along with a manager-type class on top to provide a top-level abstraction.