Hey lovely people!
Hope you're all having fun with our game :P
We spotted a couple of minor cosmetic bugs in our jam build, and promptly rolling out a patch.
We will be upload the patch on Itch.io once the Epic Megajam voting period is over.
Meanwhile, feel free download a patched build from the following link (Google Drive)! https://drive.google.com/open?id=1-xVNgEdeOIp4JvXf9kPKuvpzgDImHpBL
Recent community posts
Hey lovely people!
Heyo lovely people, hope you're all having fun with our game :P
We spotted a couple of minor cosmetic bugs in our jam build, and promptly rolling out a patch.
Feel free download a patched build from the link below (GDrive)!
We will be upload the patch on Itch.io once the Epic Megajam voting period is over.
I have played the game a few times so far, both with other people at first, to have the "talk with another person reading the manual" experience, and later by myself to have a better understanding of how this feels as a whole.
I do like the basic concept of having to cooperate with another person in real life to solve puzzles, it reminds me of "Keep Talking and Nobody Explodes", but your interpretation is a very original take on that.
Plus on the implementation side, the system has a huge variety, so it always gives the player a fresh experience, and there is no risk a player might just memorise how to beat a scenario by memory.
Now on the flip side though, as I mentioned I played this game with other people at first, and none of the people I played with, myself included, could understand what the manual was trying to convey.
Now this is a common issue with board games, manuals are almost never clear to new players, and usually you must have one person who already knows the game to explain it, and only refer to the manual to look up specific rule cases.
So do not worry too much about this, but for the future keep in mind you might want to make it more clear how the info you are conveying translates to what happens in game, such as placing the door numbers in the game, or having simple drawings in the manual visually explaining the process of checking the doors in the right order against the conditions, for example.
Another critic I have towards the game as I played it, is that it seems to lack focus.
Between one door choice and the other there are small mazes, however those mazes are far too simple to be an actual challenge, there is no way you would get lost, so it more of a chore to keep walking until you are through, they add nothing to the gameplay, and they kinda take away from theme and setting since it makes no sense for a delivery guy to go through a maze out of the blue.
My suggestion would be to drop having both the door choice and the maze, and just focus on the doors but variate how that is presented through use of the theme, for example: "you are on a street with 5 buildings, you gotta figure out which building to go in through the manual, you reach an elevator and you gotta figure out which floor to go to with the manual, finally you gotta again check the manual to figure the room number at which to deliver the order".
+ really dig the talk to person IRL idea
+ multiple door puzzles look solid
- manual could be more straight forward
- mazes feel unnecessary filler
So, to me this game feels a bit of a mixed bag.
On one hand, you have a lot of good stuff:
- lots of good mechanics which work very well together (standard 2D platforming, dimension switching, floating chasing enemies affected by the switching, etc.), and seem overall robust in the way they are built
- level based progression, with narrative to keep player hooked
- a good and consistent art style
On the other hand, the design seems all over the place:
- the choice of providing no default gamepad support is very odd for a platforming game
- the difficulty ramps up very quickly, the lack of checkpoints mixed with the amount of "moments" or "platforming challenges" you encounter in each level can make it quite frustrating in my opinion
- the game camera also creates issues with that, as it feels way too close to the character compared to the level layout, most often you cannot see what is ahead of you, meaning you will be more likely to fail a given part of the level, unless you played already through it and died to know that to expect
To summarise, I do believe that this game is very strong when it comes to visuals and amount of content, however I feel it suffers from a few flaws in some design choices that were made.
Ahah, thanks :D
I'd have wanted to be multiplayer too, sadly I was doing the gamejam on my own, it can be very difficult make a properly balanced multiplayer game without regular playtesting.
I might work implement multiplayer support in the future, hoping I get some free time lol
A couple of points of feedback I would like to share though:
- Currently if you jump off to your death after landing on the last platform, you still fail the level and have to start again. Since there is already a "level cleared" message this felt confusing to me, as I would assume that dying after seeing the message would result in me ending up in the following level, not in me having to replay the level I have just beaten
- Currently if you hold the jump button, you will keep jumping each time you make contact with a platform. I am unsure if this was intentional, and I could see why as later in the game there are vertical platforms and such. However I am the kind of player used to hold the jump button in platforming game after jumping, and therefore would sometimes accidentally jump off a platform I just landed on accidentally.
I dig this game quite a bit.
The gameplay is quite focused and tight.
Level design is quite clever, challenges are a mix of platforming and puzzling, and the "messages" are quite an ingenious way to hook me to the game.
Art is minimalist and it looks very nice, especially in combination with the music.
Overall, awesome work!
That AI bug I am painfully aware about xD
I dedicated the last official hour and an half of the jam, plus the entire "itchio servers grace period", to try solving that bug to no success :'(
Thank you very much to all the amazing people who found the time to check out and rate my entry :D
Also hanks also very much for the great feedback some of you were able to provide, if I will find the time to go back to work on this project, I will make sure to take your points on board
Here's my game: a local multiplayer wrestling battle royale game, where you play as Xmas presents!
Itch.io page: https://gmilh.itch.io/cursemas-battle-royale
Thank you SOOOO much for this!
I really thought I had the deadline under control, then I added some last minute VFX which got me 4260 shaders to compile rip
Alrighty, the Jam is over, time to take a look back and see how things went, but first, since my game is HTC Vive only and therefore not many people will be able to check it out, here's a trailer and a gameplay video, just to give some context about what this postmortem is about
What Went Well
- Concept - although as I stated at the start of this worklog this concept was not entirely my own creation, but more of an adaptation of an already existing concept to the medium which is Virtual Reality, I am still very proud of it, creating and played this rough prototype did nothing but confirm my initial hypothesis about how such a concept would well work in this medium and offer an enjoyable experience to the player
- Scope - my hope was to be able to create a first basic prototype of the game to build onto, unfortunately trying to build it in an engine I never used before resulted in a longer development time that I had wished for, however by being farsighted and scoping properly at the start of the project, I was able to still deliver a product containing the core experience
- HTC Vive - I was very pleased with how easily I was able to work with the HTC Vive, granted I had been working in Amazon Lumberyard and CryEngine, and both engines had native HTC Vive support (really out-of-the-box for Lumberyard, in CryEngine it was slightly trickier getting it to work properly), if I had to actually write code myself to add HTC Vive support to my game that would have been a very different scenario, but as a technical designer I only aim to gain enough knowledge to be able to prototype my own games without a programmer holding my hand, and now I achieved just that for the Vive
- Flow Graph - working with CryEngine I realised, while Blueprints in Unreal were created to offer a developer all he needed to create a full game experience, Flow Graph in CryEngine is simply aimed to allow you to make quick interactible elements and gameplay events, with the intention that bigger features such as main game mechanics should be written in C++, which I can understand as it is know visual scripting is very inefficient performance wise, however for this jam I wanted to create something quickly, so I avoided getting into C++ programming, and despite encountering several issues I had to find hacky solutions to, I achieved my goal of developing the experience I intended, entirely using Flow Graph
What Went Wrong
- Amazon Lumberyard - let me get this straight, I do not mean to say that Lumberyard is a bad engine, actually Lumberyard seems very promising, they have a lot of cool features, and Amazon has shown an incredible amount of effort into this engine, I do not want by any means, try to demolish all their effort just because I had a bad experience with what is just a beta release of the engine they are putting so much heart into, however this postmortem would be incomplete if I did not talk about this experience, so here we go, when I started Amazon Lumberyard looked VERY promising, much more than CryEngine would when I started working on the latter 4 days later, Amazon Lumberyard had straightforward, out-of-the-box support for HTC Vive, and even came with a working project sample for it! And to top it all, there were tons of video tutorials, it was basically heaven, unfortunately tho, the latest version of the engine at the time (it was 1.9, currently the latest release is 1.10 already) had dropped their visual scripting tool, a.k.a. Flow Graph, in favour of the oncoming Script Canvas... which as I write has not been release yet, yes technically flow graph was still supported in the engine as a legacy element, however every time I tried to open the flow graph editor the engine crashed, yes I could have got an older version of the engine were flow graph worked properly, but if the whole point was learning a new engine, what good would do learning an already outdated scripting method? Meaning the only way you could script gameplay was in Lua, problem is, all the video tutorials I just mentioned were for Flow Graph, and in three days I was not able to find any documentation nor tutorials for Lua scripting in Lumberyard, I had two weeks to make a game, and now idea how to learn how to create this game, to put the cherry on top, when I looked into how to make a build of my game I could submit at the of this jam, I found the process to be a little bit too complicated for my taste, and even after trying it out a few times, I was never successful, I had to give up on that horse that is Lumberyard, but I will give it a new shot once it's out of beta
- UI - as I replied to Jaxcap earlier in this thread, UI is very important in my concept, much of the anxiety and therefore fear in my game is conveyed by having the player be careful with his ammunition, my initial fancy idea was to have the Vive controller in-game model shine depending on the amount of ammo left, as that would have been what I would have done if I were making this game in Unreal, I was aware that I might not have been able to recreate something I knew how to do in Unreal in a new engine such as CryEngine, but I thought worst case scenario I could resort to use some floating text to achieve the same result... last of the project, I knew I could not do the dynamic flowing, since I had major issues importing materials into Cryengine, and it was a miracle I was even able to have the default material for the controller shine in the dark, it was very likely the game would have ended up with the controller being virtually invisible, but when I started looking into doing stardard UI in Cryengine, used to Unity and Unreal I assumed it also had a nice UI tool like them, I was so wrong, it turns out to do UI in CryEngine, I needed to create in, and import it from, Adobe Flash... Adobe. Flash. I had like 15 hours left and I was supposed to learn a software I never opened before in my life, just to add a bullet counter... no need to say, the final game does not have a bullet counter (I also tried using the debug show message to print the number on screen, but it was not optimised for VR Rendering, so I removed it)
- Flow Graph & Schematycs - what are these exactly? They are visual scripting languages/systems/whatever you call them, having started as a Java programmer and then then Unity technical designer, I was once very reluctant to use visual scripting, but after one year of developing with Blueprints in Unreal, I just cannot go back- okay I can, like it was not that big of an issue typing code in Lua for the first three days when I was using Lumberyard, but overall I just find Blueprinting more organised and straightforward, granted that is not nearly as efficient, but for making prototypes I find visual scripting the better option, now from what I understand, I did not actually do any research into this, so it is just an assumption, Flow Graph was one of the first visual scripting languages to be made, later came Epic with their Blueprinting system, however unlike Crytek, Epic was more open to iterate on their visual scripting language according to users' feedback, and now Blueprinting stands high as the pinnacle of visual scripting, nowhere as precise and smooth as C++ coding, but providing everything needed to allow even the less tech savvy designer out there, to bring their concept to (digital) life... unfortunately Blueprinting also creates an expectation in what visual scripting should allow you to do, but while Blueprinting was made with the idea that you can make a full game out of it, CryEngine is less of jack of all trades, and more focused to games with big open spaces, and a mission based system, as a result Flow Graph is aimed at allowing you to create scripted gameplay events (think like "if you kill the 5 guys, the door will open" or "if you step into the room, the light will turn off"), and it just felt lacking when I tried to use it to create basic game features like shooting, however Crytek seemed to have been paying attention to what Epic has been doing, at least judging from what Schematycs look like, now I am not saying that Schematycs is gonna replace Flow Graph and is just a copy of blueprints, I actually have no idea what is going to happen, but for what I saw, Schematycs seems to be complementing Flow Graph: as I said Flow Graph is only about scripted events, basically the equivalent of the level blueprint in Unreal, except you can have more than one and- actually forget that, comparing it to Unreal would just confuse you more, but that's it, Flow Graph is just logic which can be triggered and in return affect stuff, in a relatively limited manner, for more complex interactions you will need some C++ programming, Blueprints on the other hand allows you to create game objects from scratches and give them components like meshes, physics, and so on, in CryEngine to do create a new game object you can use in your game you'd have needed to either write it in C++ or Lua, however Crytek decided to switch to a more user friendly approach, and here it comes Schematycs, a visual scripting tool which allows you to create new game objects, and give them components such as a meshes and physics, in a visual environment, it looked very promising, but as beta feature it was still sometimes buggy and could not really take advantage of it, in the end I felt however that even by using these two visual scripting tools together, they were still designed differently than Unreal Blueprints, they say you should pick an engine depending on the game you want to build, and while Unity and Unreal both try to give you the buildings blocks to create virtually any kind of game, Cryengine was my first experience were I really felt like I had been giving tools which I could use to build something, but did not really fit with what I was trying to build
- Quick Art - another goal for this Jam was for me to getting started with tools such as MagicaVoxel and Asset Forget, I did try out the former, however due to how long I spent figuring out how to solve technical problems, I just did not have the time to do anything art wise for my project, in the end I added some basic blockout shapes to the immediate area surrounding the player, as to give the player a better feeling of "this is a real place", and I justify this as I am mainly interested in improving as technical designer than as a art person, but I do wish I could have done more in this area
What I Learnt for the Future
- CryEngine V - my knowledge in CryEngine V increased drastically, 2 weeks ago I would have been lost and scared if I were presented with the interface of the CryEngine Sandbox, now I can navigate it relatively comfortably, I also learnt how to make a shareable build of the game in CryEngine
- Scripting in CryEngine - I also know how to make basic and advanced scripted events through flow graph, even using game tokens, and I can detect collision (I still can't believe I only figured out how after working in the engine for 10 days straight), and I can used debug tools, I also took a look at the oncoming Schematycs system
- Importing assets in CryEngine - I can import meshes (but not materials, so far I got corrupted ones every time I tried), I can also import audio and play it using the standard SDLMixer (although probably I can still only do basic things with it, and everyone online seems to be suggesting switching to using WWise), seems promising, but as a beta it was still too buggy to use it properly for my project
- Approaching new game engines - so far I only had worked in Unity and Unreal, both "jack of all trades" engines where you are given the tools to create virtually any game you want, with Lumberyard first and CryEngine later, I discovered how that does not apply to every engine as I expected, CryEngine for example really gave me the vibe to be an engine targeted to games with big open linear levels, and dynamic scripted events, now I know that is best to look for an engine suiting your game idea, instead of trying to build an idea in an engine which does not properly support your intended gameplay, I also learnt more of the effort that goes into learning an engine, and in the future I will be able to make better estimates, as well as understanding more about why in the industry technical designers sometimes create prototypes in Unity or Unreal for games which will be then realised in more performant proprietary engines
Overall I think this was a good experience, I am slightly regretting my choice of learning a new engine, because I really like this concept and I think the final prototype does not show its full potential due to the development issues I had, however I can still go back to it in the future and realise a better prototype for it in an engine I am more comfortable in, so for now I am just happy I was able to pull of the challenge of developing was is both my first CryEngine, and my first HTC Vive game, in just two weeks, some moments were quite frustrating, but in the end I was able to show my determination, and feel quite happy about myself.
Day 10 - Status Update
So, it is Day 10, according to the updated road map for this jam I should be done with Art Research, unfortunately things did not proceed as smoothly as expected, let's have a status update.
In the last 7 days I researched and practiced in Cryengine, I only ventured in the two visual scripting tools provided, Flow Graph and Schematycs, purposely avoiding text based scripting in either C++ or C#, my reasoning for this is that theoretically Visual Scripting tools are made to allow designers to make quick prototypes, for a game jam they should be perfectly sufficient.
I must say I am dissatisfied, Flow Graph I understand predates Unreal Blueprinting, so it is logical that is way more limited, Schematycs on the other hand aims to complement Flow Graph, and it seems to be heavily inspired by Blueprinting, althogh it has differences which might make it even better if properly used, however it is still a beta tool, and to me it also felt limited, and sometimes very buggy, the fact that spawning a Schematyc in runtime breaks many function forced me to alterate the design of my game slightly, as a design solution turned out to be the only solution to a technical problem.
I do understand that Flow Graph is old and Schematycs still a beta, but unlike Unreal Bluprints, the systems provided in Cryengine just are not as complete, not even for a simple prototype.
Shooting: I am able to spawn bullet like object, propel them forward either using or not physics, I am able to detect a collision (although only by having box triggers around the colliding objects), and trigger a response (I practiced turning off a blue light), however while these thing work individually, there are some bugs when I try to make them work together, to prevent issues I now plan to have bullets be always present in the scene, and switching between an active and passive state, they would stay passive in the player's hand, once triggered they would be shot forward, and once hit their target (or after a maximum movement period), they would deactivate and teleport back in the player's hand
Enemy AI: I still have to look into AI, however I am already able to move entities and detect when they are hit by a bullet, the only uncertainty is them being spawned and destroyed, since spawning Schematycs break systems, and I was not able to figure out how to destroy entites, the common solution might be just teleport them away, similarly to what happens with bullets
Shooting - Resource System: I have not looked into it, but as far as I have noticed, I should be able to be able to build it easily
Lighting System: again I have not tried this yet, but I am familiar with all components necessary to create it
Pipeline: I am having some issues dealing with placeholders, so far I only dragged some assets from some of the sample projects provided by Crytek on the marketplace, however they all had issues in loading their materials and textures, which I did not look into since they were just placeholders anyways, but I now I will have to, as the engine is giving me literally thousand of warnings about that
Enemies: I would still like to build this in MagicaVoxel, however I am postponing this task for the 3rd of August
Bullets: I will probably reuse a particle effect from one of the CryEngine sample projects as the bullet
Hand(s): I will probably be using the official Vive Controller model to represent them in-game
Environment: I am not sure yet what I will be doing for the environment, considering I am running out of time with the core mechanics
Day 3 (End) - I am migrating to CryEngine
So it is the end of day 3, and with it the end of my research period regarding the engine Amazon Lumberyard, my intention was to spend this time learning how to use the engine, and then tomorrow get down to build a first playable prototype of my game.
Research - Results
After 3 days of research and practice, all I was able to do was take one of the levels of the existing VR sample project, and add some code to spawn a ball by pressing a trigger on the controller, which will then be pushed in a certain direction.
Out of the 4 core features I planned to have in my prototype, I was only able to build 29% of the first one
And to make things even worse, after looking into it for a while, and making a few failed attempts, I came to the conclusion that, even if I were able to come to understand how to create the rest of the game, it is very possible I might not be able to create a distributable build for it to actually submit
Research - Reflection
I believe the main reason why I had such poor result, is that Lumberyard is an engine currently still in developed and released as a simple beta, there is very small amount of learning material for it, and since the engine is constantly receiving major changes, material realised even only two months ago is already outdated and was useless to me.
Research - Reaction
My intention was to use this opportunity to learn Lumberyard, as it was advertised to me as a more user friendly incarnation of the CryEngine, in order to later have an easier time learning Cryengine itself later on.
Even tho with 10 days left I might still manage to complete the game in Lumberyard, the scarce amount of learning material, together with my inability to create a distributable build of the game, creates too big of a risk for the project, I therefore plan to abandon this engine, and to migrate my project to Cryengine, which I also never used before, but that unlike Lumberyard is an officially release engine (instead of a beta), and therefore should have enough documentation and learning material to allow me to actually create a prototype in the time given, my planning as been updated to account for this.
FUN FACT: at some in the last three days I actually ended up looking up the documentation for Cryengine 3, the version of Cryengine on which Lumberyard is based, as some of that documentation is compatible with Lumberyard, I was told to referee to it since no equivalent for Lumberyard exists as of yet, I guess it ironic I ended up migrating to Cryengine completely
I think those information, health and ammo, definitely have to be available to the player, as they are essential to allow the player to make an informed decision about "pressing the trigger".
Ideally, I would like to have diegetic spatial UI conveying those information, I would like the Vive controllers to be rappresented in game as glowing hands, with the glowing dimming as your amount of bullets diminishes, while for the health, I believe a possible narrative for the game is that you are in a dream world, and the attackers are nightmares, therefore I could have a simple block environment, which gets corrupted as you lose health (textures get a tint of red, smoke particle appear and increase in size).
UPDATE: at first I wanted to develop this game in Lumberyard, when I realised it could no be done I changed engine and the title, I am stating this to avoid creating confusion in the reader when reading the first entries
Hello everyone, I am James, and as the title says I am using this Jam as an opportunity to learn a brand new engine to add to the list of engines I am very proficient now, currently featuring both Unity 3D and Unreal Engine.
Now, when learning a new engine it is good to start by trying to create something simple and small, just taking small steps while you get acquainted with how to do something you already know how to, but in a brand new engine, therefore I am building something simple and small... except I am building it in VR
The game is essentially a simple survival horror:
- As the player, you are standing in a small area in complete darkness
- Enemies will spawn and move towards you from your surroundings
- You can use the Vive controller(s) to aim torchlight(s)
- The torchlight(s) will emit a light, allowing you to look at your surroundings, and spot approaching enemies
- The torchlight(s) will dim over time until turning off completely, the player can restore the light to full brightness by shooting
- Shooting will also produce a ball of light, which will act as a bullet, and destroy enemies on hit
- Shooting will be a limited resource, which can be replenished by killing enemies
- You will lose health whenever an enemy reaches you
- Losing too much health will result in a game over
- The goal of the game is to survive for as long as possible
My game concept is heavily inspired by Past Your Deadtime, a fellow gamejam game I've found here on Itch.io
This how I plan to approach developing a prototype for this project over two weeks time:
- On saturday I setup the project by flashing out a design, breaking it into features I can build individually, creating this planning, and getting started on technical research.
- Up until Monday I plan to be researching how to work in Amazon Lumberyard, and make small prototypes to ensure that all the features I planned can actually be built in this engine
- On tuesday I plan to create a complete First Playable Prototype, a working prototype containing all the core mechanics which are part of the experience I intend to create
- Up until the following friday I will be playtesting, tweaking, and iterating on my prototype, aiming to get it to deliver a good and engaging player experience
- Next weekend I will get started on researching and practicing with MagicaVoxel, a tool I never used before, which will allow me to create Voxel based art (think Minecraft), which I intend to use to create models for my enemies, I might also decide to research and practice how to use Asset Forge, since I could use it to create a good environment, however consider much of the game is set in darkness, environments are not a big priority, and therefore I might decide not to learn that tool as well, if I am running out of time
- The following monday I will get started on polishing, which means completing and start implementing my MagicaVoxel creations into the game (and possibly Asset Forge creations), I will also take care of visual (particles), sound, and haptic (rumbling) effects.
- By the end of Tuesday I plan to have every character model (and environment if any was made) implemented in the current build
- I plan to have polishing completed by thursday
- Finally, I reserve the last day to take care of any last minute problem, as well as to ensure the project is properly submitted
1. Hi there! What's your name? Want to introduce yourself?
Hi, I am James, I am a game design student at NHTV (Netherlands)
2. Did you participate in the last jam we held? If so, what do you plan on doing better this time? If not, what's your reason for joining?
No I did not, I am joining this time around mainly to have something to keep me busy during the summer, and of course to try out some new tools (more about this on answer to question #6)
3. What games are your favorites? Did any of them inspire you, or made you want to make your own?
Spyro the Dragon, Sly Raccoon, Kingdom Hearts, Assassin's Creed, and The Elder Scrolls
4. Do you have experience with game development? What did you do/with what engine?
I have been making games for roughly three years now, in my first year I went from trying to build 2D games in GameSalad to trying 3D games in Unity, I made nothing playable back then, but I was still getting the basics of how to build a game back then
Two years ago I joined NHTV, I have since worked on 8 different proper game projects made in Unity 3D, and became very proficient with that engine
I switched to Unreal Engine at the beginning of this year, and worked on 3 projects with it so far, and it is now currently my engine of choice.
5. Tell us about something you're passionate about!
I like videogames (duh)
I like computers and built my own and even made a mini cabinet with a raspberry pi.
I like TV series especially scifi and fantasy, and I am a proud Whovian
I also enjoy doing video editing, I used to do it a lot in high school, less since I started university, but I started again lately doing trailers for my games
I always wished I could draw, the thing is when it comes to programming it's about logic, the moment I get how something works I go from having no idea what I am doing to be able to do something perfectly, drawing well would take me insane amount of practice, and I am not patient enough
I sing sometimes, everybody who ever heard me knows I am terrible at it, but I still try to practice once a week
6. What are your goals for this game jam?
As hinted in answer to question #2, I come into this jam with the goal of learning new tools.
My main goal is to learn a new engine, and I am thinking of either either Amazon Lumberyard or CryEngine
I would also like to use this occasion to try out Magica Voxel and Asset Forge, for what I understood from reading the rules of the Jam, using the latter should be permitted
Finally, I would like to create something for HTC Vive, I have been postponing doing so for a long time now
7. Any advice to new jammers (if you're a veteran)?
Planning in my opinion can be very important even in a jam, the desire to go straight into building the game is strong, but I believe it is best to make a list of things you need to build and do to create your game, estimate how long they will take, plan when to do what, and give yourself deadlines all throughout the jam, this includes the initial brainstorming, do not spend too long waiting for the perfect idea, just spend enough time sorting out a good idea which you can actually start working on
Even tho we have two weeks, I would suggest trying to avoid big concepts, keep it small, and think about what the core experience of your game will be, to discover this you must take your concept, whatever it might be, and start removing elements from it, until all that's left are a few mechanics that are essential to your game, this core gameplay is what needs to work for the player to be engaged, you can add elements back to it later you will have time, but game development start with getting those few mechanics right
Finally, once you have these contained core mechanics figured out, I advise making quick prototypes for them in your engine of choice, it is very important figuring out early on that you can actually build your game idea, you might encounter a technical issue and have to scrap a mechanic and possibly the entire concept, better figure that out sooner than later.
I saw this game during Mark Brown's playtest stream and I had to look it up and play it.
I find this a genius concept for a puzzle game, and I am impressed with the quality of the level design it has for a game jam game.
As for some constructive feedback, when playing I felt the controls felt a bit awkward, the character would move and jump too much, and I often felt like the slightest movement could result in me accidentally falling off, this mixed with the lack of a crosshair to know where I was shooting, and the permadeath, made the experience for me being more about not falling off accidentally, than about creating a path for myself by shooting cubes.
This feels very nice, it's an endless runner, but it offers depth by giving the player a few sets of mechanics, all controlled by the same button, and when playing I really felt engaged.
If I had to point out some flaws in the build I played:
- there was a typo in the menu (Recommended is spelled with a single C),
- there was no real way to quit the game other than force quitting with Alt + F4,
- and I feel the Onboarding level was a bit too fast paced for a beginner...
But then again in my own entry for the GameJam this game was made for I did not even had Onboarding at all so, who am I to judge.
How does your submission match the theme?
The game concept was created for the Game Maker Toolkit's Game, it interprets the theme of "Dual Purpose Design", by offering the player a contained amount of mechanics (Dashing, Jumping, Smashing), which are triggered by a common Action Button, and can be deployed for either offense or defense purposes, as well as to just facilitate movement.
Please read the README!!!
It's in the downloadable archive, but for your convenience I am pasting the Controls section here as well
|WASD Keys||Left Analog Stick||Move Marble in a specific direction|
|Mouse||Right Analog Stick||Rotate camera* left/right|
|Space Bar||A Button||Marble not being moved by player||Marble performs a Dash towards the opponent|
|Marble being moved by player||Marble performs a Dash in the direction the player is moving it towards|
|Marble grounded||Marble performs a Jump|
|Marble airborne||Marble performs a Smash to the ground, the impact producing a shockwake|
|R Key||Y Button||Reload Level|
|Escape Key||Start Button||Quit Game|
*when in proximity to the opponent, the camera will automatically lock towards it
- Dash is a very fast movement, which can be used to either dodge an attack, or hit the opponent to stun and possibly push it out of bounds
- Jump results in your Marble being launched upwards, which can be used to either dodge an attack, move around the opponent to blindside him, or even prepare for a Smash
- Smash finally launches your Marble downwards, it can be used to avoid attacks in mid air, but it's main effect is the shockwake it creates on impact, which stuns and pushes away the opponent if hit, and the higher your Marble is when you Smash, the stronger the shockwake will be