• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Indie Game Development Thread 3: Indie Jones and the Template of Doom

jahasaja

Member
I've only been with my current publisher for a short while, and they literally just launched my game yesterday, so I can't really give a definitive answer yet. I'm waiting to see how things play out, how much effort they put into advertising, media connections, streamers, and additional storefront opportunities, and so on.

Dealing with a publisher is a bit of a dance though: there will be times they request things that you might not agree with (like putting 16:9 support in my game when I /really/ wanted a 4:3 aesthetic), but I think having someone help with things like storefront management, dealing with community/forums, is great if you don't want to do all that yourself.

Every publisher is going to be different of course.

Just released, exciting! The reviews so far seem very positive.

Yeah, you really do not know until afterwards I guess.
 
Recently added unit tests to my engine. I'm not a proponent of testing everything or TDD, but it was helpful in walking through my logic for my custom memory allocators.

I wrote a more coupled allocator for my bullet manager (game -> shmup for those that missed earlier posts). It's still buggy (more on that in a sec), but I like the approach I came up with it so far.

- The manager is broken into three separate allocators for now - player one, player two, and enemy. I think this will be useful for keeping track of scoring/damage/etc later (or I could be talking out my ass).
- Each allocator is double stack pool allocator (not really a thing but a combination of the two). It being a pool allocator (each memory chunk is the same size) allowed me to get rid of the header normally used in stack allocators. It being double stack allows me to iterate over a tightly packed array when I go to send data to OpenGL.
- Each frame I update the bullet information (velocity, position, etc), and if it exceeds a given lifetime, it (is supposed to) get set to a specific bullet type and not get rendered out.

However, it is still rendering some of the "dead" bullets. I'm on the fence now as to whether or not to keep debugging without visualizations or to start working on debug visualizations and logging. I'm 99% certain I know what the problem is (render memory not being properly reset, essentially), but visualizations would totally help and I'll probably need to make them eventually anyways.

Anyways, he's a gif of my buggy stuff. Don't have collisions yet, was going to work on that after getting the allocator right, so who knows when I'll get to it.

NXIn0p5.gif
 

embalm

Member
I thought I would share some hype text today. Braven is going to be the center of our RPG. The goal being to make it important as any other npc. Rich with history, streets with character, and a story arc all of it's own. The below is to help paint the picture of the city as we create content for it.

Once known as the city of wonders. A place where legendary mages from across the world met to exchange arcane secrets and common people sought out miracles that could change their lives. It now stands as a monument to the era of magic and to the corruption of those who wield it.

The western outer city, known as Low Braven, is still alive with the hustle of every day life despite the dwindling population. Few honest folk or artisans will work in the dark and grimy streets, but those that do enjoy no tarrifs and few questions, making Braven a cornerstone of blackmarket trade. Most shipments can pass from docks to city gates without worry of prying eyes.

High Braven, overlooks it's western half from a cliffside, gleaming from the sunlight and casting the lower city in darkness for most of the day. This part of the city is only open to those who are invited, and invitations have grown rare over the years. High Braven is still home to some of the most gifted mages in the world, and allows those with talent to practice uninterupted.

The surrounding lands serve as a life line to support the lives of the few who remain in the city. Mostly abondoned farmlands, overgrown forests, and the rare traveler or farmer who still works the land. These remaining people are often heavily protected and well paid. Bandits are plentiful throughout the region, preying on caravans and travelers, but never the locals.

The city and surrounding lands were once ruled by a traditional monarch, but as the arcane power of the King's advisors grew, so did their political strength. The city is now ruled by a council of mages and the royal family hasn't been heard from in decades.
 

missile

Member
Recently added unit tests to my engine. I'm not a proponent of testing everything or TDD, but it was helpful in walking through my logic for my custom memory allocators.

I wrote a more coupled allocator for my bullet manager (game -> shmup for those that missed earlier posts). It's still buggy (more on that in a sec), but I like the approach I came up with it so far.

- The manager is broken into three separate allocators for now - player one, player two, and enemy. I think this will be useful for keeping track of scoring/damage/etc later (or I could be talking out my ass).
- Each allocator is double stack pool allocator (not really a thing but a combination of the two). It being a pool allocator (each memory chunk is the same size) allowed me to get rid of the header normally used in stack allocators. It being double stack allows me to iterate over a tightly packed array when I go to send data to OpenGL. ...
Reminds me of some memory allocator exercise from university. xD

... I'm on the fence now as to whether or not to keep debugging without visualizations or to start working on debug visualizations and logging. ...
The latter. You will make much more progress that way. IIRC GG once talked
about visual debugging and why they optimize graphics algorithms right from
the start (contrary to common sense) to aid them in visual debugging making
the round-trip much faster saving a lot of time while making progress at a much
more rapid rate. They even tried to be fast in debug mode!

Edit: See these lines from last post of mine? Sure they are cool for any
photographer to know about, but they aid me in debuging a lot. I used them
to debug the whole DoF implementation of mine. The lines are from the thin
lens equation verifying my rude physical DoF approximation! Hey! :)


I thought I would share some hype text today. Braven is going to be the center of our RPG. The goal being to make it important as any other npc. Rich with history, streets with character, and a story arc all of it's own. The below is to help paint the picture of the city as we create content for it.
Puts me in the mood. :) Some more graphics?
 

Blizzard

Banned
Reminds me of some memory allocator exercise from university. xD


The latter. You will make much more progress that way. IIRC GG once talked
about visual debugging and why they optimize graphics algorithms right from
the start (contrary to common sense) to aid them in visual debugging making
the round-trip much faster saving a lot of time while making progress at a much
more rapid rate. They even tried to be fast in debug mode!
Why would round-trip optimization make debugging faster though? If you get the same image at 20 fps vs. 120 fps, the time you spend waiting for the frame to render is on the order of milliseconds.
 

missile

Member
Why would round-trip optimization make debugging faster though? If you get the same image at 20 fps vs. 120 fps, the time you spend waiting for the frame to render is on the order of milliseconds.
Sure, if you have 20fps. What about 1 fps or slower when developing new and
advanced algorithms? Making them faster while still in debugging clearly helps
before cutting all corners to make them game-mode fast. Further, there may be
build up times to actually render a level like re-computing new sets of
lightprobes, PVS, geometry etc. whatsoever to verify some other new stuff
depending on the new sets of data. Improving such algorithms indeed improve
round-trip.

Edit:
For example, my defocus depends on some lengthy pre-computation which
needs to be slightly different for each rendering optimization I wanted to do.
So I computed a set of data ahead of time (taking minutes to get done). The
original algorithm took an hour. I optimized that algorithm and can now debug
much faster that way, whereas in-game it's just something static. And only
because I optimized said algorithm in conjunction with some rendering technique
I was able to find the right pixel constellation to support my DoF computation.
It would have taken ages to get done the other way around.
 

Blizzard

Banned
Sure, if you have 20fps. What about 1 fps or slower when developing new and
advanced algorithms? Making them faster while still in debugging clearly helps
before cutting all corners to make them game-mode fast. Further, there may be
build up times to actually render a level like re-computing new sets of
lightprobes, PVS, geometry etc. whatsoever to verify some other new stuff
depending on the new sets of data. Improving such algorithms indeed improve
round-trip.

Edit:
For example, my defocus depends on some lengthy pre-computation which
needs to be slightly different for each rendering optimization I wanted to do.
So I computed a set of data ahead of time (taking minutes to get done). The
original algorithm took an hour. I optimized that algorithm and can now debug
much faster that way, whereas in-game it's just something static. And only
because I optimized said algorithm in conjunction with some rendering technique
I was able to find the right pixel constellation to support my DoF computation.
It would have taken ages to get done the other way around.
Your use case is extremely unusual though. Do you have a link for Guerrilla Games and why they needed to optimize graphics algorithms early?
 
The latter. You will make much more progress that way.

Indeed. It's a bit of a chicken and egg problem in terms of knowing what I need to visualize versus making the actual visualization. But it's becoming increasingly apparent that it'll be more helpful sooner as opposed to later.
 
Hey there! I'd like to hear some ideas about this "block" I'm experiencing.
I have this CCG game I'm developing. At its core, it's an offline CCG game and maybe later will add Online Multiplayer.

What I don't know how to do (or rather, I don't know of different ways to do it) is storing all of the Card data. The information I'm storing is basically all text and, once loaded, is used by the engine to create the Card Objects in an OOP approach, and since the "card pool" for the match is loaded only while preparing the match, I don't need to access the "card database" during an ongoing game.
So, the idea is to create a local database which stores all card information in text form. The database then is queried before the match begins, loads all cards that will be used during the match and iterates through the ResultSet using the engine to create Card Objects, then allowing the match to begin.

I'm thinking of using a local database because it is easy to maintain, to query and to modify for quick prototyping/testing new cards and effects, but I wonder if there is some other way I'm not thinking about, or a better approach instead of using a database, especially since shipping a database with the game doesn't seem like a good approach.

JSON/XML is my second option.
 
Hey there! I'd like to hear some ideas about this "block" I'm experiencing.
I have this CCG game I'm developing. At its core, it's an offline CCG game and maybe later will add Online Multiplayer.

What I don't know how to do (or rather, I don't know of different ways to do it) is storing all of the Card data. The information I'm storing is basically all text and, once loaded, is used by the engine to create the Card Objects in an OOP approach, and since the "card pool" for the match is loaded only while preparing the match, I don't need to access the "card database" during an ongoing game.
So, the idea is to create a local database which stores all card information in text form. The database then is queried before the match begins, loads all cards that will be used during the match and iterates through the ResultSet using the engine to create Card Objects, then allowing the match to begin.

I'm thinking of using a local database because it is easy to maintain, to query and to modify for quick prototyping/testing new cards and effects, but I wonder if there is some other way I'm not thinking about, or a better approach instead of using a database, especially since shipping a database with the game doesn't seem like a good approach.

JSON/XML is my second option.
I'd worry less about performance at runtime for now and do it the way that is easiest for you to create the data. What sort of data should be contained in the cards? Just some strings and ints? Or something more exotic?

I'd be tempted to just use a spreadsheet and tab/comma separated values.
 

missile

Member
Your use case is extremely unusual though. Do you have a link for Guerrilla Games and why they needed to optimize graphics algorithms early?
It was in a video, not 100% sure it was GG (could also be Corrinne Yu talking
about her engine) but iirc it was in one of those videos where Hermen Hulst
was talking about their engine and why they made such a progress. I remember
him (or her) saying that progress could be made much faster because they
optimized algorithms right from the beginning to get faster debug iteration.
 

Blizzard

Banned
It was in a video, not 100% sure it was GG (could also be Corrinne Yu talking
about her engine) but iirc it was in one of those videos where Hermen Hulst
was talking about their engine and why they made such a progress. I remember
him (or her) saying that progress could be made much faster because they
optimized algorithms right from the beginning to get faster debug iteration.
That's why I'm curious, because if they developed much faster because of doing visual debugging earlier, or spending more time on debug development, that would totally make sense. Or if they spent a bunch of time debugging an early renderer, and then a bunch of time debugging a completely different renderer, instead of just debugging once.

Let us know if you find it!
 
I'd worry less about performance at runtime for now and do it the way that is easiest for you to create the data. What sort of data should be contained in the cards? Just some strings and ints? Or something more exotic?

I'd be tempted to just use a spreadsheet and tab/comma separated values.

Yeah, it's just text. Every effect and so is built reading that and using the engine to make it easier to just insert a new card text and generating a new card. That is also why I'm considering a local database, as I think it's easier to just prepare he query and read the resulting contents.
 
I'm thinking of using a local database because it is easy to maintain, to query and to modify for quick prototyping/testing new cards and effects, but I wonder if there is some other way I'm not thinking about, or a better approach instead of using a database, especially since shipping a database with the game doesn't seem like a good approach.

JSON/XML is my second option.

I'm using this as a base in Deep Sky Derelicts. We have a lot of card data, so I wrote some extra bits around the "database" and made an editor in Unity to manage the cards. The XML and Lua card scripts are stored in an asset bundle that is loaded at runtime; performance isn't an issue unless you have an astronomical number of cards (card graphics and effects are a much bigger resource sink than a bunch of text).

Now we're trying to get the early access build done and I'm heavily questioning my life choices. >_<
 
Hello! Bomber Crew is out now & it's sitting fairly high on the Steam charts at the moment :)

Thanks to everyone on this forum (in particular this thread, where I've read & posted some a few times during development- even all the way back when we were still just doing BC in our free evenings & weekends)! Hope you're all well!
 

embalm

Member
At missle's request here are some more concept sprites. Missle, I did relay your advice to the artist and I do have the non-compressed 64x64 images. I will have to post those later though.

Our art style has shifted slightly to a leaner, more gothic look. This is a result of the story, art, and mechanics starting to fit together. I am pretty sure this is going to be our style going forward.

The beggar assassin.
KXKW1q0.jpg

Gunslinger
TL4Dzuf.jpg

Crusader
MNZmSSf.jpg

Barbarian of Urtor Clan
gM9nrMT.jpg

Priestess of Savas
SpTFTSE.jpg

The broken knight
sC8H7qC.jpg
 

oxrock

Gravity is a myth, the Earth SUCKS!
Hello! Bomber Crew is out now & it's sitting fairly high on the Steam charts at the moment :)

Thanks to everyone on this forum (in particular this thread, where I've read & posted some a few times during development- even all the way back when we were still just doing BC in our free evenings & weekends)! Hope you're all well!

I was watching Draegast play that on youtube last night, it looks like a fun game! Congratulations on getting it out the door and good luck :)
 

Fox1304

Member
Phew, it's been a while since I read this thread. It's great to see the progress you guys are making!

On our latest news, we're nearing the launch of our latest game, which is a puzzle game with 100+ hand-made levels, centered on chain reactions and making the correct assumptions and choices with a partly hidden game board. Some GIFs to illustrate :


You can check the launch trailer here : https://www.youtube.com/watch?v=FKn6uw3Q2g8


We made some GIF/WIP/Rough for ze socialz networkz, so I'll put it here too :

 

embalm

Member
Hey there! I'd like to hear some ideas about this "block" I'm experiencing.
I have this CCG game I'm developing. At its core, it's an offline CCG game and maybe later will add Online Multiplayer.

What I don't know how to do (or rather, I don't know of different ways to do it) is storing all of the Card data. The information I'm storing is basically all text and, once loaded, is used by the engine to create the Card Objects in an OOP approach, and since the "card pool" for the match is loaded only while preparing the match, I don't need to access the "card database" during an ongoing game.
So, the idea is to create a local database which stores all card information in text form. The database then is queried before the match begins, loads all cards that will be used during the match and iterates through the ResultSet using the engine to create Card Objects, then allowing the match to begin.

I'm thinking of using a local database because it is easy to maintain, to query and to modify for quick prototyping/testing new cards and effects, but I wonder if there is some other way I'm not thinking about, or a better approach instead of using a database, especially since shipping a database with the game doesn't seem like a good approach.

JSON/XML is my second option.
XML or Json are perfect for this task.
I personally recommend Json. It naturally translates to objects and is really easy to query and create as a programmer.

The first thing I developed for my current project was Json driven dialog. It handles branching dialog and checking saved values based on enums. I map the file to an object and use linq to query what I need, when I need it. It's been lightning fast and we have about 100 dialogs with 10,000 lines of text.

If you want I can sample some of my data files and query code here to help you get started. My project is in Unity and it uses their translator, but I imagine any engine will have a very similar json parser.
 
Here's another little update of my graphic adventure. It's just a new environment I'm working on. In this case, in order to achieve animation, it has to be a looping video. The video lags a little bit in Unity each time it reaches the loop point. But hopefully it's not too noticeable.

BoldThirstyCentipede-size_restricted.gif

I know this is kinda late, but the screen resonated with me a lot! Always been a fan of horror atmospheres and this seems like my cup of tea. Can't pinpoint exactly what it reminds me of, but by the looks of it I would probably enjoy paying it.

Still working on the layout of my break out game while physic problems are hopfully being solved.

SuperSquashoidConcept02.jpg


I know it's a big fucking mess :p It's busy like a shibuya street! The ui at least, and that's what i'm going for. I studied a lot to find something that was as colorful and busy as it could, like 90's japanese arcade, fighters.. So it's super colorful and bold, with pixel grids and color shades inspired from Street Fighter Alpha. Not perfect yet but i'm getting where i want.

Of course the central part with the actual gameplay is really clear.
But the idea is that it's going to be a spark fest! With lots of voices ala fighting game to.

The idea is really to have a break out game that has the depth and drama of a fighter for versus play. So i have to invent the weird child of a loud 90's fighter and arkanoid visually, with the sweet and cute setting of games like magical drop (characters are stock holder from magical drop for now).

The 90's inspiration is very clear and personally I love it.

My thanks to everyone that submitted videos of your game for Raster Stadium in 2MD! They worked out beautifully.
Here’s a couple shots, but obviously it’s much more impressive in motion.

HQvmuQC.jpg

bwfTpz3.jpg


From the top,
There Came an Echo
Horizon Vanguard
Honey Rose

Really cool.
 

-COOLIO-

The Everyman
I think publishers usually take 50%. I've no experience though so I could be wrong

i've heard 10-30 but I guess it's totally dependent on what you're getting in return. If the game is already done I would shoot for 10-20 tops and they better be offering a lot of marketing/pr magic if your game is top notch.
 

missile

Member
Hello! Bomber Crew is out now & it's sitting fairly high on the Steam charts at the moment :)

Thanks to everyone on this forum (in particular this thread, where I've read & posted some a few times during development- even all the way back when we were still just doing BC in our free evenings & weekends)! Hope you're all well!
Congrats and good job! :)


At missle's request here are some more concept sprites. Missle, I did relay your advice to the artist and I do have the non-compressed 64x64 images. I will have to post those later though. ...
Yeah nice.

... Our art style has shifted slightly to a leaner, more gothic look. This is a result of the story, art, and mechanics starting to fit together. I am pretty sure this is going to be our style going forward.

The beggar assassin.
KXKW1q0.jpg

Gunslinger
TL4Dzuf.jpg

Crusader
MNZmSSf.jpg

Barbarian of Urtor Clan
gM9nrMT.jpg

Priestess of Savas
SpTFTSE.jpg

The broken knight
sC8H7qC.jpg
I like the style, but the shading is way off, way too much. They look uneasy
from over here. Perhaps it looks better when seen in context of the game. But
for the moment I love the old ones much more (cleaner, fewer shades).
 
I'm using this as a base in Deep Sky Derelicts. We have a lot of card data, so I wrote some extra bits around the "database" and made an editor in Unity to manage the cards. The XML and Lua card scripts are stored in an asset bundle that is loaded at runtime; performance isn't an issue unless you have an astronomical number of cards (card graphics and effects are a much bigger resource sink than a bunch of text).

Now we're trying to get the early access build done and I'm heavily questioning my life choices. >_<

I see. I'll check it out. Sounds interesting and very similar to what I intend to do.

XML or Json are perfect for this task.
I personally recommend Json. It naturally translates to objects and is really easy to query and create as a programmer.

The first thing I developed for my current project was Json driven dialog. It handles branching dialog and checking saved values based on enums. I map the file to an object and use linq to query what I need, when I need it. It's been lightning fast and we have about 100 dialogs with 10,000 lines of text.

If you want I can sample some of my data files and query code here to help you get started. My project is in Unity and it uses their translator, but I imagine any engine will have a very similar json parser.

I'm also using Unity, so I'd really appreciate to be able to see an example, just to get started on how to work with it.
 

embalm

Member
I like the style, but the shading is way off, way too much. They look uneasy from over here. Perhaps it looks better when seen in context of the game. But for the moment I love the old ones much more (cleaner, fewer shades).
The sprites are a lot busier and I think lighting was playing second fiddle to that. I think what you're saying about the shading being way off, is that we have pillow shading. I want to make sure I give the right feedback to my artist, so let me know if that's not the only thing you mean.

The style is a big departure from the first ones. We wanted smaller heads and thinner frames to fit a more gothic style. As the story and setting was feeling dark in tone we shifted the art style to fit that.

Thanks for the feedback on this, it really is appreciated.
 

Pehesse

Member
Forgive the huge gif, but I'm too excited not to share:

TerribleFamiliarFlyinglemur-max-14mb.gif


Why does stuff wait until friday night at 10PM to finally click, though? :v

(There's a LOT left to do and a LOT of placeholders and the gif quality is terrible and everything, but you get the idea and this isn't concept anymore it's the actual real game wooo)
 

missile

Member
The sprites are a lot busier and I think lighting was playing second fiddle to that. I think what you're saying about the shading being way off, is that we have pillow shading. I want to make sure I give the right feedback to my artist, so let me know if that's not the only thing you mean.

The style is a big departure from the first ones. We wanted smaller heads and thinner frames to fit a more gothic style. As the story and setting was feeling dark in tone we shifted the art style to fit that.

Thanks for the feedback on this, it really is appreciated.
Ahh ... pillow shading it's called. Interesting. No, I think pillow is ok, no
problem, what I mean is that the figures use so many shades at such a
low resolution, it's difficult to make out features. But perhaps this goes
up in smoke seeing them fully animated and in-game. Hmm.


Forgive the huge gif, but I'm too excited not to share:

TerribleFamiliarFlyinglemur-max-14mb.gif


Why does stuff wait until friday night at 10PM to finally click, though? :v

(There's a LOT left to do and a LOT of placeholders and the gif quality is terrible and everything, but you get the idea and this isn't concept anymore it's the actual real game wooo)
You screwed it up! Change the color temp of the sun when setting and you
are set! :) Looks like a lightning ball falling down. xD Anyhow. Nice to see
things in perspective now. Really curious where this all ends.
 

Pehesse

Member
You screwed it up! Change the color temp of the sun when setting and you
are set! :) Looks like a lightning ball falling down. xD Anyhow. Nice to see
things in perspective now. Really curious where this all ends.

Ahaha I was waiting for that one :-D Yeah, the sun isn't affected yet, as are a few other things - I recorded out of elation when I got the thing first working, now I need to get to everything else... after some sleep :-D
 

missile

Member
^ Yeah sure!


Btw; for those working at night, I've found out that the new color scheme
Macular Pigment from f.lux is stunning when working at night. It's somehow
less stressing for me than the reddish ones. Anyone?
 

Minamu

Member
^ Yeah sure!


Btw; for those working at night, I've found out that the new color scheme
Macular Pigment from f.lux is stunning when working at night. It's somehow
less stressing for me than the reddish ones. Anyone?
Good idea, could use that on my laptop at work.
 

jahasaja

Member
The sprites are a lot busier and I think lighting was playing second fiddle to that. I think what you're saying about the shading being way off, is that we have pillow shading. I want to make sure I give the right feedback to my artist, so let me know if that's not the only thing you mean.

The style is a big departure from the first ones. We wanted smaller heads and thinner frames to fit a more gothic style. As the story and setting was feeling dark in tone we shifted the art style to fit that.

Thanks for the feedback on this, it really is appreciated.

If you are going for pixelart you just need to bring the colour count way down. If you look at the examples in the link you provided you see that every sprite have much fewer colours between probably 10-15. It Makes the sprites much cleaner..
 

missile

Member
If you are going for pixelart you just need to bring the colour count way down. If you look at the examples in the link you provided you see that every sprite have much fewer colours between probably 10-15. It Makes the sprites much cleaner..
That's what I meant with the shades. However, in motion (when being animated)
it may work the way it is. But if they are going for pixel art, then I also
think they need to cut down on the many shades. They don't add much for the
characters, currently.
 

khaaan

Member
Dumb question but I've been learning Unity and messing around with 2D stuff.

I have a player object and then a weapon object nested in it. During animation I'm adjusting the weapons position on each keyframe to correspond with natural hand movement of the player sprite. It looks like the translation is happening over time rather than an instant render in the new specified location. Is there a place I can specify how long I want the transition to be? In this case, zero? I feel like there's a field or something somewhere. I don't see anything on the animator component on the player object :(

Edit: Got it. In case some poor soul is looking for the same solution, highlight all the keyframes, right-click and set both tangents "constant". I tried messing around with this menu before but I was doing individual keyframes instead of all of them which may have been the issue.
 
Been a while since I posted last in here, just been busy, but I wanted to share some stuff.

First off, back at the end of September, a part of the team working on the game went off to GDEX, a game expo over in Columbus Ohio. We showed off the game, handed out some keys and stickers, and worked to get more of name out there. It was a pretty great experience. Watching people play and enjoy the game was really invigorating morale wise, especially when we got a lot of comments on the art style, and that's something I've been working hard on for a good year now. Still got a lot of work to do before the game is done, but it's a bit easier knowing there are a few out there that really enjoy the game. Glad we ended up going.

Also, we got interviewed by some guys who just started a YouTube channel / streaming. That was pretty neat, so I thought I'd share it for kicks.

Some images;

Our booth;
bqAyhqe.jpg


People playing at the booth;
d4twoCe.jpg

Also, just to add the most recent stuff I've been working on for screenshot Saturday, boss variants. It's been a challenge, since we're trying to reskin what we already have, but they've turned out pretty well. Been cool working out new mechanics where we can too.

 
Well, it's always possible for people to connect through other means. discord, steam, other forums. if there was a site for people to meet up we can pretty much try to continue from there.
 
Top Bottom