DOCUMENTATION + USER GUIDE
FINAL DOCUMENTATION
Hello and welcome back everyone!
Today there's a lot to go over as this whole devlog will cover documentation on just about everything to do with DON'T DO IT that I've completed over the semester along with a guide on how to play the game and how the project is set up. Lets first start with how the concept grew over time into whatever this is.
~~~ Differences ~~~
The original concept of DON'T DO IT revolved around fast paced minigame style game modes much like you'd see in mobile games with a bit of confusion mixed in due to Kyle, all in a laboratory kind of setting going for a 'you're a lab rat' kind of feel. I can say for certain that I have stuck with the core concept pretty well throughout the duration of its development but had to drop quite a few of the original ideas as I progressed and realised that I didn't have the time or it just wouldn't work out with what I had planned.
Gameplay - The gameplay is exactly the style I was thinking of when first concepting for the game. It involves the fast, endless, random ramping-difficulty feel I was so keen on getting. Elements implemented further down the track such as the addition of a timer and red vignette effect as time runs out really help create that sense of rush as you play. The random level selection style gameplay was actually very easy to implement and left for a lot of creative freedom while making the game feel endless and shake up content so it feels different each run. The list of minigame type modes I had during development didn't really compare to the small handful now in this build of the game as there just wasn't enough time to implement them. This was mainly due to the fact that they were simply the most time consuming aspect of the game to create with their unique gameplay loops and conditions that I had to implement. And just to top off the arcade, endless feel of course I added scores and highscores to the game for fun and bragging rights as was intended from the start.
Setting stuff - This ended up being surprisingly more fleshed out than I'd anticipated, originally being a simple static text prompt or two that would imply "Kyle bad" with a few quips from Kyle if you'd die turned into the conversation system I used for back and forth conversations between both Kyle and a scientist that helped bring out the setting and added to the tricky-ness of trusting what you hear that I wanted as part of the game. Kyle still kept his identity as a chronic liar and will still get you killed but there is also a scientist that adds tot he confusion while wasting your precious time figuring out what's going on. These definitely changed for the better and really enhanced the game in my opinion.
Explosions - Explosions were supposed to be a fairly core part of the game as, well... you explode at the end of every run... plus explosions are cool! They were originally planned to be permanent stains against the walls of the laboratory reminding the player of that one highscore they were so close to reaching while Kyle laughs at them for dying. While this was a cool idea, it didn't really work with the way I was planning out the creation of the game. I'm sure if I'd planned it well enough, it wouldn't have been a super hard task to leave markings on the lab in places the player had died but I had a time limit so there was only so much planning I could do. While they don't stick around like intended, things sure do explode! I put a decent amount of effort into this one effect and I'm very proud of how it turned out although there's always room for improvement.
Smaller updates - gameplay doesn't switch up that drastically from the normal platform to X but could definitely happen in the future
~~~ Feedback ~~~
The feedback I had received from the testing session was interesting. At that point I had tried to implement too much at once and ended up breaking a decent amount of things in doing so but despite that, I still tried to get as much as I could out of it.
That was the first build that I uploaded showcasing the new conversation system in a fairly complete form even with custom art and the feedback on "how well does the system convey instructions to the player" and ratings on whether people liked it or not came back very positive. There were pretty much zero complaints about the system which made me think that I was definitely on the right track with this and decided it could be used better as an informative tool than just for fun and world building.
The main constructive criticism I got was about my player movement and level design which to be fair I did kind fo put on the back burner at the time in order to push new content but was definitely true as my levels were bad (at the time it was only a few that I strung together for testing my tilemap) and the player movement was really floaty and didn't feel right to me (and apparently everyone else too).
With the feedback I received, I made a lot of minor tweaks to the player movement in between working on other parts of the game to improve the overall feel of control over the player and aimed to improve the quality of levels that I would later build causing me to put a lot more time into them and thoroughly test them (which I believe I have).
1. Player Movement
Many people found the movement a little awkward (this wasn't in the form but comments from people while playing the game)
Mainly described as 'too floaty' causing me to tinker with the gravity of the player
2. Conversation system
People liked the dialogue system and felt like it gave them a clear enough idea of both the setting of the game and the objective they thought they had to complete.
"provided me with a feel for the game"
"I think the objectives are clear, but I don't know who to trust" (perfect)
"It's pretty clear what's supposed to happen"
3. Animation
Animations were rated quite high for being clear and representative of the players actions
4. general feedback
Comments on general QoL stuff and some on level design (which I mentioned above). I ended up tending to most of these and they mainly came about due to the broken state of the test build.
~~~ Assest ~~~
A look inside the spaghetti which is my project and the assets I use to string the game together.
*** Just a disclaimer cause I haven't mentioned it before but all sprite assets are of my own creation (using PAINT.NET) ***
First a few basic ones to get out of the way:
Sprites folder - A folder that includes all my sprite assets (which are somewhat sorted) and for some reason the tiles for my lab tile set (along with a stray material for blood particles)
Animations folder - The couple of animations I have for the player and lasers
Shaders folder - Contains my player shader and a failed attempt at an outline shader for highlighting selectable objects
Sounds folder - For my few sound effects I hurriedly slapped in there for some reason (randomly generated using SFXR)
Scripts folder - Contains all my scripts (that I wrote myself with the help of unity documentation)
Fonts folder - The one font: fff forward (which is free for commercial use and can be downloaded here https://www.1001fonts.com/fff-forward-font.html)
Tiles folder - Where the tile set was supposed to be
Now for the more complicated stuff... Prefabs folder -
- _GameManager: This is a singleton that only exists on the menu page and persists throughout the game that deals with the current state of the game. It contains UI for the end game screen as it handles the game over logic itself. This contains functionality such as:
- killing the player and causing a game over (also handles the game over screen)
- restarting the game (resetting player and score etc.)
- loading the next room
- adding score and keeping track of the highscore
- controlling the position of the player (for spawn points
- Player: Handles the players point of view, visuals and movement control (its just the player object). Contains a virtual camera as to not cause errors when the player object is removed from the scene between games. This allows the camera to simply stop moving when the player is out of scene instead of having no visuals at all or swapping cameras.
- Bloodsplat: A sprite of a blood splat that contains a bunch of particle emitter objects that are launched in random directions (this is the explosion object created when the player dies)
- Laser: A simple laser sprite with a trigger collider that causes the game manager to end the current run when the player collides with them
- ButtonObjective: An object that handles the logic of button pressing (which one is good/bad) )as well as controls aspects of the timer on the level. Also contains the buttons themselves as to not create unneeded errors with corresponding slots for what ones are correct/incorrect
- Timer/surviveTimer: I'm putting this here cause they probably should be their own game objects as they handle their own logic. Counts down from the specified time and calls game over/task completed on hitting 0. Also has a text component at the top of the screen and contain the logic for the vignette effect as time gets shorter.
- ConversationGO: This is a basic setup for the conversation system with the UI images and text objects perfectly lined up so all that has to be done is type out the conversation within the conversation script that will play out on level start.
DON'T DO IT
Experiments and explosions.
More posts
- Devlog 6 - Finishing Touches (for now)May 28, 2023
- Devlog 5 - Game LoopMay 21, 2023
- Devlog 4 - Preparing for GameplayMay 14, 2023
- Devlog 3 - Tileset + Player VarietyMay 07, 2023
- Devlog 2 - Basic Rooms + Animation UpdateApr 30, 2023
- Devlog 1 - Player MovementApr 23, 2023
- DON'T DO IT - Concept DevlogApr 14, 2023
Leave a comment
Log in with itch.io to leave a comment.