It took me a while but I finally made a Postmortem of the recent short project I took part in.
Go read it HERE
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 got some cool feedback and managed to implement some quick fixes today.
Here is the result:
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:
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.
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:
After gathering first feedback I’ve decided to make certain design changes:
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:
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.
Here is the list of major issues that I managed to identify with testers at various stages of development:
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.
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.
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.
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”