Recent community posts
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!
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.
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.
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.
- 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.
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!
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!
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.
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!
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...
Thank you so much! This was just a really dumb old project for me in a 3 hour game jam, made as an excuse to learn Ren'Py. I wrote the silly moronic script in just an hour, stream-of-consciousness in a rush for the deadline. Pretty much my dumbest creation ever, just a troll piece mainly, but it always held a place in my heart.
People have actually been requesting a full version of this, which I'm not opposed to. I'd love to return to this dumb game concept and make it into a full Steam game with some 50K words, multiple full routes, etc., but I work a full-time job as a Game Designer on serious games haha... So finding time for indiedev is tough.
Anyways, thanks again for playing!
Thank you for playing and your kind attention. If you would like to play an actual jam game of mine instead of an incomplete art and sound demo, then I would recommend Doppelgate:
Or Inverse Pair:
Both were made in only a few hours and share a common design theme, but they're complete and playable microgames.
Yes, it's a visual novel, as tagged and labeled. Visual novels are novels (or shorter fiction) presented as software with visuals, usually anime-style artwork, that typically feature minor interactivity through choose-your-own-adventure-style branching narrative choices or dialogue trees, with varying complexity. Visual novels are considered a subgenre of video games, along with other interactive fiction that lack visuals, but they lack real-time interactive gameplay.
This game was a dumb microgame project made in under three hours for a game jam (as an excuse to learn Ren'Py), with the script written in under one hour (the other two hours were spent learning Ren'Py).
Popular visual novels include Doki Doki Literature Club, Ace Attorney, Monster Prom, Daganronpa, and your mom.
Lol. Surprised anyone saw this on upload; this is (obviously) a super simple and unimportant upload—mainly just uploaded to fulfill a 2022 weekly goals quota—but it's a product I often found myself wanting, with occasional use for.
This is actually a redux of one of the first pieces of software I ever made as a teenager—back then, I got a lot of interest (or at least a lot more interest) in math and cryptography, so the first few .exes I made of my own volition were Caesar / Atbash cipher applications, and this Factor Finder
This was such a quick silly project... years ago now (eesh)... but it always stuck out as one of my favorites when I was doing quick weekly projects.
One of those projects that I always tell myself I'll get back to and expand in the future... but I know realistically I most likely won't. If anything, I'd recreate an improved version from scratch rather than dig back into this old code haha...
Regardless, thank you for commenting! Nice comments on old projects are always appreciated haha 😄
Let me know if there's anything I can do for you in the future! (e.g., playing your game, giving feedback, fixing a bug that bothers you in one of my games, etc.)
The game didn't work for me the first time, glitched out at the enemy screen and wouldn't let me move or do anything, but thankfully it worked the second time on a reload.
Absolutely fantastic art and music! So cute and thematic, really loved it. Awesome job, all!