Because this is my first “post mortem” of my first “game” and because of the format of these blog posts I’ll try and keep it short and simple so that maybe some usefulness can be squeezed out of it.

What went right:

1. The idea. While in my idea brainstorming list I had “let the room be a space station”, “make the room grow”/”shrink the player”, “player has VR and so the room changes”, etc., I’m glad I ditched them for something “out of the box” (wow do I overuse quotes..), something I am quite familiar with, something that I thought many within the game dev community would be familiar with – the doom and gloom of the networking experience. Although I wish I had thought of doing something with roombas, damn is that a gold mine!
2. The aesthetic (kind of). As many here, I am the opposite of an artsy person. I can’t draw, I can’t model, I can’t even light my damn scene right! So for people in the game I went with what I could use – Unity’s primitives, namely capsules. A capsule for the body, some spheres for eyes and an animated capsule for the mouth. I really don’t think highly of the whole visual style of the game, but here’s the golden nugget – a quote from a player saying ”
   Networking … with like other blobs of meat … count me … out … It took like 5 sec of speaking before i started to look for exit. […] Nice idea but their faces they are almost real it is creepy you hit the uncanny valley.” The decision to go with the simplest thing I could accomplish lead to enhancing the actual message and feeling I was trying to convey. All said, I also recognize that the reviewers might be motivated to comment to get the extra coolness (or whatever the system is) and also tend to try and encourage other devs and leave out the harsh things. 
3. The xp. This being my first jam/compo lead to it being an amazingly rich experience. The most important thing I learned was how possible and even easy it is to experiment and do something that you can test out quickly. I don’t want to use the word prototype as to me that is linked more with the testing of mechanics/ideas that are already thought of. This, on the other hand, showed me that I can dedicate some time to just give birth to something I hadn’t even thought through. Also, having done all the voice over-recording, failing to do simple volume balancing, producing crappy looking aesthetics, writing lame dialogue that I wished I could re-record but ran out of time, I learned to appreciate the work done by people within all of the other fields even more. And even more importantly – I understood how flawed my communication with team members in other projects has been when trying to convey what I want in this part of the game or another.
4. Webgl. I know I had it easy using Unity and webgl being accessible with just one click of a button, but from the amount of reviews my shitty game is getting and also the fact that I am myself more likely to play games that are easier to launch (i.e. webgl), having a webgl build is pretty important if you want your game to be played by a wider audience.

What went wrong:

1. The preparation/execution. Alright, so I’m browsing twitter on the evening of Friday the 16th when I see someone mentioning LD37 happening this weekend. Keeping in mind people prep for it months before (not sure what they’re doing though), I gather all my might and try and learn how to produce screen shake (yes, I’m that much of a noob). Because the one thing I will definitely need in LD is screenshake. I spend about an hour on that and then go on with my life. I decide waiting until 2AM is not worth it and go to sleep. I’ll wake up at 7, be full of energy and ready to go. So I wake up at 10, find out the theme is one room, lay in bed for almost two hours trying to think of something worthwhile, then a couple of hours more until I pin point what I eventually want to do. I used to be able to go by a day, rewatch 6 episodes of californication while drinking with friends, game some baldur’s gate, pretend like i’m gonna go to lectures and spend some more time playing civ 4 and then go to sleep at the end of the next day. It’s been a long time since I have tried doing that and have been on a strict grown up regime ever since. So obviously I have a good 8-9 hours sleep after Saturday. The point is – I wasn’t ready and didn’t try hard enough.
2. Coding a dialogue system. Ok, if you read anything in this post mort, let it be this – if there exist tools for something you want to do, even if they take an hour or longer to learn, learn them. You have never encountered anything like this new thing you’re trying to do, you have absolutely no idea how you’re going to go about implementing it, therefore – use tools already available. I researched and found out about Yarn and then tried learning it and then thought “hey, i think I can code a dialogue system” after already spending 1-2 hours on finding existent tools. So I start looking for ways to do this. I find many answers which don’t do what I want, I try to tweak them, I somehow crash Unity with infinite loops a couple of times and then after about 6 hours or more wasted – I’ve got it! A hideous, inefficient solution consisting of nested coroutines within nested coroutines ad infinitum. Just learn to use the tools available to You, especially if they have been implemented in numerous semi-well-known games.
3. Building the build. It didn’t technically “go wrong” but it did waste some of the precious time by the end of the cycle. Expect things to go wrong, ESPECIALLY if you’ve never worked with the target build (e.g. webgl). For some reason “yield return new waitforendofframe” wasn’t working on the webgl build so I had to come up with a way to go around it so that input wasn’t registered more than once within a frame.

Overall, according to the comments, the game made some people laugh, some think, most complain about low audio volumes, but I am fairly satisfied by what I accomplished in the amount of time I had, having only begun learning Unity (and game dev) 3-4 months ago.

I intend to do a proper remake of it in the near future and team up with people who know what they’re doing when it comes to art and sound this time. Maybe VR? Who wouldn’t love to come back home after a networking event and play engage themselves in a VR game on networking? If you’re interested follow me on my pretty much non-existent twitter @erikiene, I will definitely announce it there once it comes out.

I invite You to try my walking simulator / hearing sensitivity test out yourself and see what you think! All feedback is welcome – especially harsh, nasty things, as long as they’re honest and fair.

Also, congratulations to everyone who entered LD and almost all of the entries I tried (close to 200) have been amazing experiences in one way or another, both compo and jam wise.

Great idea! Intelligent, stylish game and the music is so pleasing. Congratulations!

THINGS THAT I LIKED:

• I managed to get all of the furniture placement rules to work properly, along with showing the player all the valid placement points.  It even removes invalid furniture whenever you pick up something that it requires.  While making this, I was so worried that I wouldn’t get it all to come out right, but it did in the end.
• This is probably some of the most mellow music I’ve written, and I really enjoyed listening to it while playing the game.  I hope others do as well.
• I made all of the sound effects myself through the microphone plus some sound editing, which I’ve done in the past.  I think I will continue to do this, since I’m starting to get pretty good at it.
• I made a level editor to help speed the process.  Without it, it would have taken me much longer to make all the levels, and I wouldn’t have had time to make the 15 that I had.

THINGS THAT I DIDN’T LIKE:

• The aforementioned level editor is very rudimentary, and always saves to the same filename (which has to be manually changed in order to be inserted into the game).  If I had more time, I would have made it more user-friendly and included it as part of the actual game.  I think including a level editor would have helped push the game up to the top.
• It’s in the code to allow furniture that is pre-placed and can’t be moved, which could allow for interesting puzzles.  I didn’t have time to actually make any puzzles using the mechanic though; I was lucky enough to get the current 15 levels done in time for the compo to end.
• I keep feeling like I made level 14 too hard.  People have beaten it though, so maybe I’m just being paranoid.
• The way to tell the attributes of furniture is to hover over it or check on the slight color tint.  I think having actual different graphics would probably be preferable, but I didn’t have time for that.  It worked out, but it does add to the confusion.
• I really wanted the sofas and chairs to auto-rotate to face properly, but I just didn’t have the time to implement it.
• I also had a TV planned that had to be against a wall facing a sofa, but I cut it out after I realized that checking facing was going to be very difficult to accomplish with the way I had everything set up.

THINGS FOR THE FUTURE?:

• This could make for a good completed game, maybe for mobile devices.  It just needs a facelift and a slew of additional puzzles and furniture types, and also some more furniture attributes.  I would definitely want to have the aforementioned TV put in.
• Someone suggested to me that it might be possible to have levels procedurally generated.  I agree that it’s possible, and I might look into it if I decide to take this anywhere.
• If I continue with this, finishing up the level editor is a must.  I’d really like people to be able to make their own puzzles and share them.

DarkLight was my first game for LD, and if to be honestly this was my first game that was practically ready. In same time I recived some comments about shortcomings and unclear parts of the game. Main comments was that is nice idea and atmosphere but they didn’t understand what should do.

So I decided to “finish” it and correct this things, or better to say “update” this prototype to something what may be called the game.

Meet the latest version!

You can download it for Windows PostCompo, for Web the is some problems.

Play and Rate

In this update I include more changes of the room and now it is 10, so I think you need at least 5 minutes to pass it to the end. Also I included subtitles and voices that should help you during the journey

But still I don’t have enough knowledge to show the end of the game. So if you are interesting on how it should end please contact with me

I know it is not a lot, but I think you’ll like it, Merry Christmas and happy New Year!

We love developers, we love Ludum dare, and we love your games. We’re on our bean bags and fur rugs excitedly playing them. Join us  on twitch here https://www.twitch.tv/onlyslightly and send your games our way!

Hey, all! We here at Tech Valley Game Space (TVGS) started posting our live-stream recordings on our own Youtube account! You can check them out on this always-up-to-date playlist below:

All the Saturday stream videos are:

• Flight Attend-A-Thon: Video, Game
• emily VS everything: Video, Game
• levelone: Video, Game
• Storage: Video, Game
• Don’t Help Me: Video, Game
• Liberty Room: Video, Game
• One Room Hotel: Video, Game
• Super Crash Box: Video, Game
• Tree House Quest: Video, Game
• INF: Video, Game

I finished making the game about 30 mins before the Jam ended. Check it over here : http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=110057

This is my 2nd Ludum Dare and I’m more satisfied with this entry compared to the last one.

Forgive me if the art is horrible, but I tried my best.

I finished making the game about 30 mins before the Jam ended. Check it over here : http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=110057

This is my 2nd Ludum Dare and I’m more satisfied with this entry compared to the last one.

Forgive me if the art is horrible, but I tried my best.

I finished making the game about 30 mins before the Jam ended. Check it over here : http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=110057

This is my 2nd Ludum Dare and I’m more satisfied with this entry compared to the last one.

Forgive me if the art is horrible, but I tried my best.

I finished making the game about 30 mins before the Jam ended. Check it over here : http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=110057

This is my 2nd Ludum Dare and I’m more satisfied with this entry compared to the last one.

Forgive me if the art is horrible, but I tried my best.

Darkness, sound, thrill and only one room is lit! If you haven’t seen Engine Room yet, give it a try! Play through the short story of an engineer on a cargo ship. Trying to repair the engine, you have to fight against pirates who are hijacking the ship!

The game was something new for me, because I didn’t develop any kind of shooter yet. But it worked out! PLAY HERE

Added a boss character to my Third Person Shooter GhostGun.

I think he kind of rocks (if only for being my first Capital B Boss).

see if you think he rocks, and let me know.

 Click here to Boss !

The soundtrack to Shadow Fencer Theatre is now up on SoundCloud.  Take a listen!

GOOOOO!!!

Tags: 2D, BUTERATOS, game, jam, Ludum Dare, music

Play Roomba Fight Club here

A lot can change in a year. Just about one year ago I participated in my very first game jam, Ludum Dare 34. You can read about it HERE. I found the whole experience incredibly difficult, yet rewarding. Just a couple of weeks ago I decided to try it again with Ludum Dare 37. I wanted to see if the grueling game jam would treat me any differently now that I’ve had another year of game development practice under my belt. Did it? Well read on and see (or just skip to the end if you’re lazy).LD

The Game

The theme for this past Ludum Dare was “One room”. I decided to make a video game version of the Roomba knife fights videos from YouTube called “Roomba Fight Club”.  The premise to the game is very simple. You have a Roomba with a knife strapped to the front and three balloons strapped to the back. The goal of the game is to protect your balloons while popping all of your opponent’s balloons. This task is compounded by the intentionally difficult tank controls and scattered furniture around the room.

The Development

Development for this idea started really rough. Like incredibly rough.  I could not think of an idea for the “One Room” prompt. I lost about 2 hours of development time just pacing back and forth in my room trying to think of a game that would only take place in one room. I had learned last year that you can’t go too outside the box with the theme ideas. I had a couple of commenters let me know that they dinged me points for “Safe or Sorry” because while the meta game was played with only two buttons, the actual game was not.  I wanted to avoid that if at all possible and let the player know that I had indeed stayed on theme.

My first idea was to do some sort of multi-dimension thing ah la “Rick and Morty”. Something where there were a huge number of identical rooms in parallel universes, but that would require a bunch of ideas for each universe and time to implement them all. This was a no go for a game jam idea. I then came up with a bunch of plays on  the word “room” such as “The elephant in the room” or “Wiggle room”, but game mechanics weren’t apparent in either idea. I finally settled on Room-ba based room combat in a living room.  Hopefully the theme didn’t get lost on people this time.

This year I focused way more on “planning before execution” than i had the previous year. Before I started coding anything I had a basic idea for how the game would play. I had a basic idea of the shape of the room and the aesthetic for the game. I even picked out a color palette to stick with using http://www.colourlovers.com/ before I ever even started coding. This is in stark contrast to last year where I just started coding right out of the gate. I think what changed this year is that I was at least a little familiar with the process.  I wasn’t so scared that I would run out of time that I felt that every moment needed to be put toward creating a tangible asset. Once I had my basic plans laid out I still didn’t just jump right into code. First I grey boxed everything.

I laid out the basic perimeter of the room and cordoned off the areas where props such as the couch and TV would go. This took a few tries to get right. I didn’t want the room comically large, but I also wanted it big enough to move around in.

Once that was done I moved into the pawn setup for the Roombas. I played with making them all physics driven, but that turned into a nightmare quickly. It was too easy to get flipped over or to create really weird physics issues. I eventually just had them inherit from the default Unreal Character class, but in doing so I wound up getting the default capsule collider which caused a few problems of its own. I even had the balloons on strings originally with forces constantly pulling them upwards. It was cool, but it made them impossible to stab with the little knife, and extremely unpredictable.

Once I got movement down I built out a really simple AI for your Roomba opponent. It’s a behavior tree with three nodes.

1. Turn towards player
2. Dash forward a random distance
3. Wait a random amount of time.

By making some of the parameters random the AI feels a little less predictable, but all in all it took me the least amount of time in this project. I played around with making the AI smarter, and making it use Unreal’s path-finding, but I found out quickly that the game was way more fun when the AI just smashed its way through the environment like some 90’s kool-aid man.

Next came round after round of polish. By designing first, then coding, and leaving aesthetics till last, I ensured that I could take all the time I needed doing the art. I didn’t have a lot of code left hanging over my head.  My asset creation pipeline looked a little something like this:

1. Create BSP volume in Unreal the approximate size of the asset I wanted.
2. Export BSP as static mesh to use as a size reference
3. Model basic mesh in Zbrush using Zmodeler and dynamic subdivision.
4. Kick back to Blender to clean up, UV and Assigning materials.

That was about it. I skipped texturing which saved me a ton of time. Other than the wallpaper which I generated using a tile generator, every material is just a single color. Last year I used Substance designer to create my textures, but the amount of time I lost didn’t seem worth it for the final outcome.

The music for Roomba fight club was generated in Bosca Ceoil. The same as it was last year. Sound effects were created by a combination of recording noises on my cell phone and using www.bfxr.net .

What Went Well

• Boxing out the room first
  • Boxing out the room first meant that I didn’t have to make zero hour design choices and updates. I played around with everything while it was ugly, so that once it looked nice I could just leave it alone.
• Using a Pre-Determined Color Palette and Skipping Textures
  • By deciding I wasn’t going to waste my time this year with textures I freed up a lot of time to send on other aspects of the game. Because I stuck with a pre-determined color palette the game still looked pretty nice even as flat colors.
• Multiplayer
  • Multiplayer wasn’t one of my original design choices. It got added to the game on the Sunday morning before turning it in. I had to call a buddy to bring over a Gamepad just to test to see if it even worked. This turned out to be an easy win due to how UE4 is set up. I just had to spin up a second player controller and that was about it. Most of the work the engine does right out of the box.
• Destruction
  • Like multiplayer this feature was added late in the game but made a huge improvement. Originally couches were unmovable and the furniture was just something have to work around but I kept getting stuck on it. It was trying to figure out a solution to that problem that lead me to make the whole room alter-able. The effect was easy to implement and it made the game way more fun.
• Juice
  • I tried adding a little Juice to this project. I added some time dilation and screen shake on balloon pops. I also added a confetti style particle effect. None of that was very hard to implement, but I think it makes it feel better when you score a hit.

What Did Not Go Well

• Lighting
  • It turns out I had a lot to learn about lighting. I probably still do. Every other game I’ve worked on has either been outside, so the lighting was pretty much handled by the Sun (directional light) or has been intentionally dark. I found it really difficult to get the indoor light to look natural. I wound up just using a post process that added tons of ambient light, but I doubt that’s the right way to do it.
• Unfinished features
  • There was a lot I wanted to implement that I did not get a chance to implement. I wanted to make the balloons semi transparent on the player’s Roomba so the player could still see it. I had intended there to be a choice of 3 weapons to extend the games play-ability. I also wanted there to be more than two Roombas in a game. Maybe I’ll come back to this game one day and implement these features but for LD37 I just ran out of time
• Controls
  • I had intended for the controls to be a little clumsy. I had wanted the controls to be a little clumsy, like an old school tank controls type game. Unfortunately I don’t think I implemented them well. Turning isn’t great, and the camera is locked to the Roomba’s rotation, so turning always feels a little jarring. To make matters worse enemy AI Roomba turns instantly and accurately. It’s hindered b the distance it can travel, but it’s got pin point accuracy making it very frustrating in single player mode.

Conclusion

There’s an inspirational quote floating around on the internet that goes something like “It doesn’t get easier, you just get stronger.”  I feel like that really applies here. I feel like my entry for this Ludum Dare is heads and tails above what I turned in last time, but I don’t feel like it was any easier to create. If anything I feel like it was harder. There are a lot of systems in play for this game that did not exist in the simple survival horror game I made last time, but I don’t think I would have attempted something this ambitious had I not already done the game for LD34. So to answer the question “did this game jam treat you any differently?”, yes. I feel like this Ludum Dare treated me different. Not better. Just different.

www.undeaddev.com   @JimmothySanchez

Tags: lds7, postmortem

When the Ludum Dare compo ends, the judging begins, and it is an overwhelming task. There are SOOOO many games to play, which is thrilling! Players will dip in and sample lots of games along the way… but you want more than that. You want folks to get in, stay engaged, and see all the cool stuff you have to offer. I have had some success in doing exactly that, and I want to share my techniques with you.

Tell Them What’s Coming

Almost all my LD entries have been wave based, and each of those waves introduces players to a new concept. New power, new enemy, some new gameplay piece. I want players to know this, so the wave entry text talks about it right at the get go.

I didn’t invent this concept, it’s a trick as old as Joust:

I do my best to use this concept in all my games. 1111, while it doesn’t have a wave introduction, makes very clear that as you rank up, enemies do too, and each rank introduces a new number to do battle against. When you finally clear the angelic 9s, you win the game.

Wave based gameplay often means that samey enemies just pile up faster and stronger until you die. Players will catch on to that, and the gameplay break between waves is often a point when players will say “Ok I’ve seen enough” and drop out. But if you remind them that there’s more and newer adventure right around the corner, they’ll stick around.

Let Them Party As Hard As They Want

The best way to sum this up is Don’t Kill Them, Or Make It Hard To Die. Game Over is the perfect time for a player to say (again), “Ok I’ve seen enough” and there’s a possibility that they miss out on fun content.

1111 Has a generous life bar, and when it runs out you simply drop a rank. It’s very difficult to lose permanently.

Demon Truck, Cave Harrier and Gridshape Get are all timed and discrete experiences. You can’t Game Over, but you do take hits and your score is affected by your performance.

Blue Helmet Beatdown and We Must Protect Lich House do have Game Over conditions, but it is exceptionally unlikely that the average player will stumble into them in the early game. Even truly hapless players are almost guaranteed to see a good chunk of gameplay.

Game makers may balk at this advice, after all, games that are too easy don’t grasp the player in the long run. However, in Ludum Dare your goal isn’t the long run, it’s making sure they give your game enough time to experience it fully. That may mean five minutes, it might mean ten, it might mean three. You want to remove barriers to completion, but still challenge them to do their best.

Use The Game To Make Your Levels

This may be a tough one if you aren’t used to procedural generation. If your game is wave based, you want the waves to be based on what players do, and not necessarily where they do it. If you have to hand-build environments for each level, that drastically limits how much you can do, *and* chews up time you could using making your game more fun.

Now if you’re making a puzzle game or something that requires specific events to transpire at specific locations, maybe this advice isn’t for you. I still think it’s a worthwhile effort to train up on procedural generation before your next LD.

1111, Lich House, Demon Truck, and Gridshape Get are all set in open environments that don’t change. What *does* change is the gameplay elements created by the monsters and player powers.

Cave Harrier is also in an open environment, however each zone had unique art. That was a must to try and match the Space Harrier feel.

Wreckbeard was a Shinobi/Rolling Thunder clone, which meant multiple heights of platforms were a must. So I created platforms and blocks, then placed them procedurally when the level was formed. Simple rules for height and collision meant the level was playable.

Reward Them With Your Best Gameplay

This advice might raise massive alarm bells, especially for developers who’ve worked on larger indie or AAA projects. A Golden Rule is that you put your best and most polished gameplay first because that’s what all your players are going to see, only the hardcore stick around until the end. For an experience that lasts hours and hours, I completely agree. But the LD games are short, and if you are using wave based gameplay, each wave builds upon the last until you finally emerge into an environment where the player is at full potential and the challenges are out in force. The journey is short (again, three minutes? Five?) so the reward is in reach, and if you…

Tell them what they’ll get

Allow them to play unhindered and

Have a variety of procedural content,

Many more players than you expect will see that reward. If you’d like to see these concepts in action, [blatant shill]check out my LD37 entry, We Must Protect Lich House![/blatant shill]

Thank you and good luck!

Hey guys, this LD, I’m trying out recording all my playthroughs of games for rating. I’m not like, a famous youtuber or anything, but I’ve gone through a bunch of games here.

https://youtu.be/GvnbFVF6-m4

I planning to go through another bunch when I get the time, I’m trying to play through the games of people that rate and comment on my game, so feel free to play and rate Cozy Taxi!

Thanks for your time!

I don’t usually do postmortems for my Ludum Dare games. Usually because I don’t have anything interesting to say.

“I’m happy with this, I’m unhappy with that.” Done.

But not this time. This time a have a short story.

I went into this LD with high hopes. I had a cool idea, although I wasn’t quite sure what I’d do with it (heck, I’m still not). I had a cool aesthetic that I felt the need to show off:

I even felt good about audio, although the end result there wound up a rushed hour’s worth of work.

At the end on of the jam, I was happy. Aside from the audio, I’d accomplished what I set out to do, and the end result felt polished and fun.

Then I had my girlfriend play it the next day.

She couldn’t hit anything.

I’d made too few hit frames, and not accounted for the space between the frames of the very fast-moving attack.

And I’d done all the testing myself. I knew the attack frames. I could land a hit with ease. It never occurred to me that my play style was built around non-obvious, broken controls.

Disappointed in myself, I set about fixing the control scheme post-jam, a process that only took me about 30 minutes and made the game MUCH more fun. But it was too late for the jam.

I already knew this lesson, but this drove it home hard: play test your jam games. It can be the difference between a broken mess and a fun game.

Hey guys, now we have short videos to show our game!

Basic Gameplay

More gameplay (exploding with traps)

Interfaces and upgrade system

If you are interested, play the game here

My game for this Ludum Dare was The Shifting Theatre, a game about an actor in a play about a millenary treasure in a dungeon:

I started by thinking about the idea, which took about an hour… The idea is not really good but I believe it fits the theme 😉

The idea is that every time you reach the exit door the scenary gets changed, this can be noticed with the closed courtains (Which are quite hard to see as curtains as they are red squares, but they are)

Well, I started programming the tilemap renderer, got it working in 2 hours with the same perfomance regardless of how many tiles are there on the levels. I made it load .png files instead of any custom tile format, this limits a little bit what you can do in levels, but is overall enough for the project.

After that was done I implemented the player controller and fixed some perfomance issues with the tilemap renderer.

That was it for the first day.

On the second day I started making some music (Which was not used at all) and continued working on code. Added basic enemies and made a bunch of levels. Expent a lot of time working on a horrible platform system which I ended up rewriting later on.

On the third day I rewrote the platform system from scratch, implemented physics for platforms in the player and made all the levels. I also created the menu, the music that is now in the game and a few more enemies. Packaged the game and uploaded it! (for windows).

I’m working right now in the Linux build, got a decent workflow and compiled it, but for some reason my virtual machine is not working with OpenGL, so will have to do it on a real machine!

Good stuff:

• I managed to write an engine and a game in the time limit. I’m quite satisfied with that
• The graphics and sounds feel nice
• The tilemap renderer can be used for any future project
• You can use any image editor to make levels, place enemies, platforms, etc…
• The code is relatively organized. Though there are some big files (>1k lines)
• Finally made a project in C++

Bad stuff:

• The “physics engine” is buggy as hell, especially with moving entities.
• Enemies knock you in a very weird way.
• Some features are confusing, such as slower walking while in platforms
• The game is very short (But fairly difficult)
• The Visual Studio solution is bugged so you have to recompile the whole thing after every little change.
• Didn’t use all the time I could have used…

Thank you for reading! Feel free to play the game!