It took me a while but I finally made a Postmortem of the recent short project I took part in.
Go read it HERE
private blog of Cobble Games CEO
Category: DevLogs (Page 1 of 2)
We’re approaching the inevitable deadline. Time is running out, TO-DO list is pretty long, so I don’t want to waste too much time.
Current stage of project is as follows:
I’m still adding core features and tweaking the ones that already exist. TLDR: I NEED MOAR JUICE!
Hopefully I’ll manage to achieve something of a better quality.
I haven’t posted that often with the progress as you must be aware that I am in the middle of changing jobs. Can’t say much as I still need to sort out some legal stuff with my previous employer. Things got pretty unpleasent, they still owe me some money. However, things are good already. I have found another GameDev Team and I am starting to work with them full time in August. Moreover I will no longer be bound with non compete agreement and I will be able to cooperate with other teams as a supporting C# developer.
So… yeah… that change has not been planned but it appears that it will be for the better.
I managed to implement cooperative feature known from SWIV: Player 2 can now join in the game anytime to control a Land Jeep. It will cost Player 1 a single life but it may be worth to ask your buddy to give you a helping friend… specially if you happen to fight a big bad boss monster (which is not implemented yet but expect it to happen soon)
Get prepared for regular updates. At least until the time my job situation becomes clear you may see the updates on daily basis.
I got some feedback from the first movie which I managed to implement. Here’s the list:
- Spaceship is smaller, so player can see more
- Added some optimalization features
- Voxel particles for explosion
- Tweaks in ship controls
- Added some basic sounds
After the theme has been chosen (Destruction UP) I have started coding some basic foundation. Still a lot to do (especially with the optimization) but for now I have the core movement and shooting mechanics implemented. I’ll post next update probably on Sunday. Since I am between jobs at the moment I have a lot of spare time to code 🙂
Let me know what you think. I’ll try to implement as much as I can until 31st of July.
Last weekend I took part in a live meet up with my fellow indie developers from internet community called Kurki Collective. Kurki Collective initiative evolved from a small, yet quite productive group of developers from all around the Poland. Most of them are less known in the main stream gamedev but that’s the whole beauty of it: We stick together, make games, have fun and live our busy lives without an urge of being in the center of everybody’s attention.
That was a second live meet up, last year we met in the Orla Cafe where I showed my first game Unholy Showdown in it’s early stages of development. This year I showed the early version of base building game I am currently making after hours of my day job gamedev. I have to admit that I had to crunch slightly to deliver the core features I wanted to show but I can only say it was worth it. Folks gave me some really useful pieces of advice. Live feedback was so interesting that I have decided to immediately code some of the changes.
TLDR:
This is a version from Friday:
This is a version from Today:
In the first movie I got some basic Dune2-like building system, where you first had to lay some floor-tiles to place certain building. Now, as you can see, you will have to place a Light Totem first as buildings can only be placed within it’s light radius (sort of like Starcraft Protos pylons).
Generally I had been encouraged to play more with the light mechanic. This would be integral with the core story of the game. The plot is still very blurry and lacks precision but I shall stick to a concept of bringing back the light to formerly lively domain, which is now exploited by evil creatures who feast on it’s light. Very simple, maybe not too deep at the moment but time will show.
As soon as I get the building system going I want to include some progression system and basic quests to be able to explain Player the plot without cutscenes. Not sure how they will look like but I want them to be meaningful – if a player reaches a level that allows them to learn a skill = find a teacher. Need access to new part of the map? Please the gatekeeper. Etc. As I mentioned before – this is more of a learning experience for me.
So to sum up the planned changes:
- Build system:
- Structures can be placed within light radius only.
- If the totem is gone they will slowly decay (to be implemented).
- Structures need light sparks to be build.
- Some buildings (like defense towers) will require upkeeping cost.
- Progression system:I want player avatar to be able to gain experience points to unlock special abilities. Nothing too complex, maybe just some linear skill tree. Just to make the game slightly more interesting and focus it more around the main protagonist.
- Quests: Yet again. Nothing too complex. Kill 5 monsters. Bring a package… or maybe I shall come up with something more interesting. I dunno at this point.
- Visuals:
- I will have to learn Blender this time to create some basic 3D models. Right now what you see are just a placeholders. I chose this art style for a reason – this whole bloom and glow is perfect to cover my low modelling skills 🙂
- Work on camera – I havent decided if I want to make it static or give more control to the player. Time will show.
- Since the game will strongly be based on light on / light off mechanic I will need to work on some textures and light system. Right now there are no shadows. Just a lot of glow. This will have to change at some point.
After gathering first feedback I’ve decided to make certain design changes:
- Game will no longer be about Samurai on Ice.
Now Samurai will need to run away from Zombies, slashing through anything in his way. - Kill Zombies while performing combos for extra points
- Game will have endless procedural generated levels
To do:
- Add a wall blocker certain level distance. The wall will need to be destroyed by bashing through.
- Add bonuses and pick ups
- Change rapid break into “launch a super charger” which can be activated after killing certain amount of zombies.
If you with to join open alpha tests then click on THIS LINK
I’ve decided to redo some of the old game jam games with better gameplay.
For the first round my choice is the Game which I made together with my Fiancee during HUUUGE Game Jam in December 2016.
More about the original game jam project in the postmortem HERE
My choice was to make it an mobile arcade game based on wacky physics, lot of screen shake nad explosions.
You swipe on screen to “throw” the Samurai and give him momentum and tap to make him stop. The challenge here is that since the stop is kind of radical it overheats your player sandals. You cannot stop again if the sandals are not cold enough. If samurai is moving he is automatically attacking the zombies. Zombies can only hurt the player if he is not moving. Zombies also leave a poison toxic pond after their death which deals a small damage if player touches it.
So far it looks like this:
Preface
Colleague of mine who works with me in my current workplace as a Lead Designer noticed one thing missing in my Postmortem of Unholy Showdown – I need more analytical approach to design issues.
I’ll try to cover this topic in following post.
Issues Identified:
Here is the list of major issues that I managed to identify with testers at various stages of development:
Unclear gameplay
Most of the testers played the game as a single player even though my primary design decision was to base the game on local multiplayer. This caused confusion and unclear feedback the game gave to players on many stages. The solution was either to redesign the game to single player only or implement an online turn based multiplayer. The problem here again was with getting the feedback too late. I consider this as the worst design “sin” of mine.
No time pressure
Paper / Rock / Scissors is based on time pressure and simultaneous players decisions. This game is turned based but each player can take as long as they want to make the choice and then pass the phone to another player. This made the gameplay simply boring. Again, it was too late to make a change with the resources and time I had to finish the project.
Solution?
- add a timer to each player rounds
- redesign the game so players must make up their mind in the same time
No random or “Cheat” factor
The beauty of Paper / Rock / Scissors game is the art of bluff. The game was not giving that psychological super power of allowing players to “fake” their moves. This could give interesting results combined with the time pressure factor.
Solution?
- hide buttons during time pressured rounds while players make choices in the same time.
Conclusion
This was a great learning experience. I leveled up my technical skill but I must focus more on the design aspects during my next game making process and get feedback sooner. At some point I ventured into sort of a dead end, call it “the point of no return”. I strongly encourage anyone with gamedev aspiration to do such a task as well. The next project will be definitely better and more solid design-wise.
[EDIT Comment by Michał Rudziński]
“I would point out some other problems, from a pure design standpoint. I didn’t mentioned it before, because you said that Gameplay isn’t subject to change, and to be honest rock paper scissors in it’s simplest form (contrary to systems used in some RTS games where units follow rps philosophy) is deeply flawed even in it’s real time version, even so called psychological meta game is only a illusion built on randomness without any real choice or strategy”
© 2021 On the road of GameDev
Theme by Anders Noren — Up ↑