This is especially impressive if it's your first time doing a Trijam! Nice job!

Really fantastic execution of this classic simple game jam genre. Procedural squash & stretch and VFX make super simple square graphics look great, the chromatic aberration is nice but not too much, and I really love the transition between rounds, that's an awesome touch. Awesome visual package.

The fact that there's actual terrain and it changes over time puts this above most arcade arena shooters, great simple improvement.

Multiple enemies and warning of where they're spawning makes this feel more high-quality as well.

The one thing I think this needs is a reason not to spam the fire button. Like most similar games, it's optimal just to keep spamming fire, which hurts the finger and isn't fun. Ammo, an overheat mechanic, or better yet alternate fires or a charge shot would help a lot. Also consider stuff like changing the player movement speed when firing or not, give the player a choice of how to interact instead of one single optimal way to play.

And while the changing terrain is great, alternate goals besides just killing enemies would be great too to vary the gameplay loop. For example, ammo, powerups, or health packs are a simple way to vary the play experience, but I'd recommend stronger design changes like every once in a while a specific position spawning the player needs to get to or else they lose health or can't fire or slow down, etc. There are lots of different design ideas to experiment with.

This game is extremely competent and impressive. Awesome job. I look forward to seeing what else you make.

Very fun visual style and silly concept. Nice.

Good effort.

It would be good to restart the game on R, that's always a good idea in any game jam game, and usually pretty straightforward in most game engines, and same thing restarting properly with the return to the main menu.

Keep practicing to improve your work efficiency so you can include sound too. Tools like BFXR make SFX production really quick and easy, but you can just download free sounds or record silly sounds from your mic as well. Same for music, there are lots of easy free AI tools like Suno and plenty of free music tracks you can download and throw into your games with usually a single line of code.

In terms of game design, in games like this the optimal player strategy is just to keep spamming the fire button. It would be great if you can figure out reasons why the player can't do that, like limited ammo, an overheat mechanic, losing points for missed shots, or charging stronger shots, etc.

Keep making games! I hope to see you make more in the future.

Really slick visuals. Fantastic work. Very cohesive, distinct, good little procedural animation when finishing a level, the VFX, all great.

Seems endless with procedural levels, which I think is great for a Trijam.

I would like to see some other mechanics in the puzzles to make them more difficult. As of now, the gameplay is very trivial and not very engaging in terms of design, but the art and animations are so fun that it carries the whole thing.

Overall, awesome job. I hope to see more from you in the future.

Good effort, hope to see you make more in the future.

It would've been good if the train wheels stopped spinning and the background stopped animation for wind whipping past once the train stops/breaks. A little animation or explosion particle effect or something to indicate the failure would've been great too.

On a more higher level game design concept, the repeated button mashing isn't a super engaging game loop. Some other obstacles to overcome, some variation, and perhaps distinct levels with an end goal (to give the player a break), like the train arriving at its destination, would help to improve the player experience.

Keep making games!

Very cute!

Art is simple and effective, cute character design and animations, but the level design isn't very fun.

The jump in-air 'cheat' is too easy/obvious to discover accidentally and trivializes the gameplay, but playing without that is way too difficult, especially for such a short game. There isn't really a difficulty curve. The challenges could have been broken up into multiple shorter levels, and the collectible floppy discs could have used a bit more. That second level is far too long and difficult for a second level, and it's odd that it lacks the floppy discs. The third level would make more sense in its place, some re-ordering would help, but breaking up the levels and defining a more engaging difficulty curve would be best.

Overall, it's a great visual package, good theming for a Trijam game, and well-scoped. I hope to see you explore more about game design and refining the player experience with your future endeavors.

Cheers,

Nice work!

Super creative interpretation of theme!

Extremely basic in gameplay (ultimately won by just mindless button mashing), but good art, creative/unique concept, and good music that really ties this together, makes for a successful Trijam game imo

Very interesting little game, well-done overall. Very cute ending, good cohesive art. Rather unique/uncommon gameplay loop though it gets stale even in the short run-time.

This game taught me that armor is pointless and maxing out GUN solves everything, just like real life (joking)

Congratulations on making your first coding project!! I hope you continue pursuing this interest

antimatter engine is OP, awesome stuff

Great concept, well-done for Trijam

I won, then died with my ship drifting into a stray bullet while on the win screen, and so got the lose text overlaid on top of the win text lol

Yes you can use any part of this project however you'd like. I'd of course appreciate attribution and a link to this app from the page of whatever you make, though, please! And more importantly I'd like to see and play whatever you use it for 😁

Thank you so much! This was a quick 3-hour game made for another jam (three hour Trijam), and I submitted it here too because at the time I was being encouraged to submit games to multiple jams where applicable, especially Decade Jam (I no longer really like doing that).

I enjoyed making it, as I've always been obsessed with negative space games (I have a few more on my profile, like Doppelgate). I want to get back to making them someday, but in recent years I haven't done any online public itch games or jams because I've been busy with my first baby, and working in-industry at House of How on Minecraft and Invincible stuff, etc.

As for a level with no rings/exits where you were confused, you probably reached the end. The final level was drawn with 'You Win!' in the background using grey blocks, as I recall, and I remember a lot of people not seeing that blocky attempt at text in that level and being confused. It's a short and simple game, given it was only three hours of dev.

Thank you so much for playing and commenting! I appreciate your kind words. I'll try to return the favor when I'm back home from traveling.

Lol, thanks! Yes I'm a big western animation and musical fan

Thanks! 

Thank you!

Thank you so much!

Lol

Thanks m8

Old test game made in 3 hours for a game jam as an excuse to learn Ren'Py for the first time. I was just screwing around with the language syntax and basic capabilities mostly

High praise! Thanks, mate, I appreciate it! 

I had so much fun writing this stupid little monstrosity in an hour for the quick game jam, and so many years later, I still want to come back to it and remake it into a full-length game. Kind words such as this are definitely encouraging for me to do so! 

Thanks, gamer

You're a real one—all fax, no printer

Pog

Thank you, my friend! I'm very glad you enjoyed it! 

I wrote the script for this game in only about an hour as a stream-of-consciousness nonsense-fit making up things that made me laugh. The entire game was only made in 3 hours for a 3 hour game jam, with 2 hours being spent learning Ren'Py. I really loved making it, and always wanted to come back to the premise and make a full version, and after all the positive feedback over the years, that's been more cemented.

I work (very) full-time as a game developer at a game studio called House of How, so I don't know when I'd have time to work on Love at Fujikawa again, but I'm definitely interested in doing so.

Lol

A great effort for year 1 students, especially given only four weeks!

An impressive amount of content—a very large environment with a lot to explore, and a great amount of detail in the environment, some attempts at environmental storytelling, and just a lot of placed objects to differentiate scenes, which is more than can be said for most student Unity games! It's naturally nothing revolutionary, but for a four-week sprint by beginning student game developers, I'm very impressed.

The codebase seems perfectly solid; I'm sure bugs exist like any game, let alone student game, but I couldn't find one. Sometimes collision didn't exist between my player character and enemies, but I chalked that up less as a bug and more just a calculated dev-decision; I didn't think it a problem at all. Of all things I would want changed about the game, proper player-to-enemy collision is about the bottom of my list.

The art assets are fine and serviceable, though the environments are very samey in appearance. I was impressed by the visual level design—how the objects were used to create environments, laid into curious cots and tables and collapsed piping—but my primary fault or gripe with this game is how unilaterally gray it all is. I'd love it if more colors, negative space, lighting, and contrast was used to break up and differentiate the visuals and environments and guide the players—but that's hardly a chilling indictment of the developers' character, as overly samey-looking gray or brown environments is an extremely common problem, even in AAA games with years of development and millions of dollars of funding! So such samey environments in a quick month-long early student project is hardly a big deal.

The other main fault with the game is the game design and UI/UX—which is exactly as expected. Even if more time was given and the developers were more senior at the time, game design and good user experience is deceptively hard and tricky to pull off. Even among senior game designers, most of the good design quality of their games comes from avid playtesting and iteration, not talent or even skill. Knowing how a fresh-faced user will interact with a game takes years and decades of design and playtest experience to really understand, and even then, few to none really claim to be masters of it. Even great game designers have bad UI/UX in their prototypes, only ironed out with that repeated playtesting. This is exceedingly common for beginning designers, students, and games made in a game jam or other rush. If I was asked to list desired changes to this game, it would all start with that UI/UX and game design—pause menu with controls and settings on escape, tutorialization for all controls instead of the side screen, some controls and mechanics like the time slow being either cut or better integrated into the game, changes to the gunplay, timing, reload speeds, rebalancing the guns, allowing the player more counterplay beyond taking cover while reloading to avoid enemy damage instead of just tanking while shooting, more direction, better indication of where the player has already been, etc.—but these issues are exactly what I'd expect from a beginning team's Unity game, especially a student game made in such little time. I don't fault the game much for it, and even still, I don't wish all games to have that perfectly polished UI and good game design, because there's a genuine charm to simple student games like this with their blocky Unity menus and lack of tutorialization. I'm always glad games just like this exist, as they're fun in their own way as an occasional experience. It's a novelty if nothing else.

And judging by how the keycode scribbled on the wall in the screenshot is different than the one I saw in my run, I presume that number is randomly generated? If so, that's a brilliant touch! That seems like a no-duh move, but I can't remember a single other 3D game I've played that's ever done that before, where the password / pin number, etc. you find in the environment to open a door / chest is random each playthrough so it can't be cheated. I can think of so many big-standard AAA games—even some of my favorites like Dishonored and The Last of Us—and they don't do that touch, even though it would be so easy, especially because in those games the passwords/passcodes are just communicated as text in reading handouts, instead of environment textures. That's honestly given me something to think about, and I'm going to stow that lesson away as a neat trick. It's very rare that a game gives me a trick or idea like that to really take away from it permanently; that's really awesome. Escape Marchana earns good marks in my book for that alone.

Nice work! Very snazzy; I always love little melodic sound effects like this (on the die's roll).

Super funny! Great simple micro-game. Love the art-style

I love this! Super cute, solid simple concept, very well-executed.

Where is the music from? Did you make it?

lol

Forming Teams

Here are my tips for forming your game jam teams! I've participated in dozens of game jams—I've run a dozen or two myself—and I've witnessed hundreds of game jam teams form, with many successes and just-as-many failures as teams crash-and-burn. I want you to have a fun, positive, and educational jam experience where you can make something you're proud of, and forming your team (or lack thereof) is the first step!

You may elect to ignore some of this advice if you're a more experienced jammer, especially if you have a preset team of experienced devs, however for beginners I stress my advice and warnings below.

In short:

• Be clear and honest about yourself and your jam goals
• Make a small team of 1 to 3 people—5 at the most
• Work with people of a similar skill level with different skills

When making games with a team, teamwork is the most important skill—not art, design, or coding! And good teamwork is often harder than it seems; if you don't think you're ready to juggle being a great team member alongside everything else that goes into a game, making a solo game or working with only 1 other person is perfectly fine, and perhaps better for your situation.

Self-Presentation

If you're looking to join up with new people (which is great!) consider how you present yourself.

• What are your strengths and weaknesses? What skills do you offer? What tasks do you want to do on this jam?
• What role do you want to fill on a team? Do you want to take the lead on a project or relax in a more supportive role?
• What kind of game do you want to make? 2D or 3D? What game engine do you intend to use? How tied to that game idea are you?

I'd recommend creating a simple profile here on itch.io (if you don't have one already) even if you don't have any previously published games here. Showcase your previous work (all your previous work—even the bad/buggy/unfinished/embarrassing stuff) and communicate a bit about your personality and gamedev-interests. While I don't think it's any kind of gold standard, here's my own itch profile to get a taste of what I mean. If you've made something other than games, such as artwork, comics, videos, music, or even fanfiction hosted elsewhere, then link to that!

I'd recommend posting both here on the Greenlight Jam itch forums and within the Greenlight Discord to look for your potential teammates.

Like anywhere else, it's all about managing expectations! People can only be disappointed by a game or any product, or by a teammate or coworker, etc. if they expected something different. If expectations align with reality, then no one is ever disappointed and everyone gets along really well. You know yourself better than anyone, so tell us all why we'd love to have you on our teams!

Team Size

While anyone can be a good teammate with good communication and teamwork, remember that both communication and teamwork are skills within themselves, and quite difficult to master, especially during a tight time-crunch such as a game jam or when learning new skills. If someone is already stressed out with the difficulty inherent to making a game in a jam, then remember that their communication skills will understandably be impacted!

Also remember that the more people you have in a group, the more people you have to wrangle and communicate with, which makes good communication exponentially more difficult the more of you there are. In short, more people is not always better! Oftentimes smaller teams can be more focused and actually produce better games than disorganized larger teams that tend towards confusion.

If this is your first time making a game (or even your second, third, fifth, etc. time making a game), consider having a smaller team you can communicate better between. For beginners, I recommend a team size of 1 to 3 people. I strongly recommend you keep your time size no larger than 5 people!

Teammate Selection

Similar to considering how many teammates to take on, consider who you might work best with. The best teams are balanced! It's best to supplement for your weaknesses to let you play to your strengths!

If you're a programmer, then consider partnering with an artist or sound designer! It may seem obvious, but plenty of people are understandably inclined to work with their known friends, even when their friends all have the same skillset as them! You don't want to have a team of all artists or all engineers, as that will generally result in everyone tripping over everyone else without anyone supporting the knowledge gaps.

Working with your friends can be beneficial as you already know each others' personalities and general skills and preferences, however I recommend trying to team with people of a similar skill level to you as a priority. If a beginner and an expert at different stages of their gamedev journeys try to work together, it can occasionally result in conflict, unhealthy power dynamics, uneven games, or a mismatch in possible scope. Unless you're a more experienced developer specifically trying to team up with a less experienced developer for the sole purpose of helping them grow via mentoring, in the hundreds of game jam teams I've witnessed, those with the most uniform skill level amongst its membership tend to succeed the most with the happiest team dynamics.

Ultimately, just keep in mind the overall amicability and togetherness of the group. Everyone should be on the same wavelength and ready to have fun together first-and-foremost. A small happy team that gets along and has fun always wins out over the big more competitive and "stacked" team of "powerhouse" devs with competing egos, regardless of the supposed skill levels. Be kind, honest, empathic, and have fun!

Ah, I see. Well the short answer is however you want. Just as you can deliver a game in whatever package you want (Windows .exe, HTML5 package, Android .apk, Mac .app, etc.) for whatever platforms you want to prioritize, even though HTML or Windows are recommended to hit the most players, you can naturally publish concept materials in whatever format is best for your game.

This is genuinely just whatever files you'd make for yourself and your team to brainstorm your game concept to yourselves; all you're doing is exposing your process.

If you're an art-driven team, maybe you just make several pieces of concept art and upload those to an itch page as screenshots, or if you're used to presenting games in a pitch document-like format, maybe you upload a PowerPoint file that goes through the overall plan for the game. If you're a hands-on person who likes writing pen-and-paper notes or making a dream board of sticky notes to brainstorm, take a picture of that!

However, on average I'd expect most people to write their concepts in a Google Document (especially with a team), perhaps with some reference material images or links embedded, or concept art embedded within the document. Then you could simply link to that Google Document, and/or upload it as a Word or PDF.

Anything is fine. As long as it's a file(s) other people can open and examine, it can be in whatever format. However, if you want it to be easily seen by as many people as possible to share your process, I'd recommend Google Docs and/or Google Slides.

Howdy mate!

On the main Greenlight Jam page, each of the four sprints (Ideation, Prototype, Production, and Polish & Release) have a link to a different itch.io jam page where the result from each sprint should be submitted one-by-one each week during the jam.

Use this link to submit your game concept for the first Ideation sprint. This will be a rough pre-production plan, including any ideas, concept art, storyboards, design docs or design pillars, mood boards, perhaps a plan of how the available time will be utilized in each subsequent sprint, a description of the tools you'll use, etc.

This first sprint phase will be a good opportunity to assemble teammates by pitching your concept to each other, with a comfy full-week to do it!

However, we will be launching a Discord server for this jam soon, which will serve as the ideal location for team formation, allowing for faster, more informal file and image sharing and easy informal pitching. I'll repost that server link when it goes live here!

Thank you so much! That's very kind of you to say, especially on this game of all my games haha... 

I appreciate it!

Lol. Thanks for having a good attitude about it. I've always felt bad about the clicking part; I thought it was a really obvious troll from the start, especially after the text about how time was running out for the game jam, but a lot of people over the years have seemed to fall for it completely and get mad that nothing else happens haha... 

Lol

Thanks, bud

Thank you! Glad you enjoyed it,