Camera System

cli Leave a comment

Finally, we started to think about the camera logic. How to move the camera relatively with the character we control in a way that the player gets the most out of it. There was not so much to find but this Gamasutra article from Itay Keren helped me a bunch. I know at least have a clue what I’m talking about. And a tweet about the camera system of qomp from Stuffed Wombat inspired me to do something similar.

Head Into

The problem I had was that the camera was always following the character which made it quite a challenge to watch and might cause motion sickness.

Camera Systems

Lerp Camera

I found on this page a good lerp implementation which I use as well. It solved almost all my jitter problems I had with my own lerp camera implementation. It’s pretty cool and worth a read.

Projected-Focus

This is a projected-focus camera that looks a bit ahead of the player while moving.

The initial camera code was very straight forward and simple

Vector2 velocity = new Vector2(player.dyn4jBody.getLinearVelocity());
camera.setLocation(new Vector3f((float) (player.location.x + velocity.x / 2),
            (float) (player.location.y + velocity.y / 2), 0));

I just used the velocity to catch up with the player and look in the direction he currently moves. This was needed because the underlying lerp-smoothing logic, will let the camera fall back on high speed like a free fall so a velocity-based look ahead seemed the best solution.

This camera always follows the player. This can be annoying if we do wall jumps where the character always moves in and out. I guess after a while people will get sick.

Camera-Window But Keep Projected-Focus

The goal was to reduce the camera movement to a minimum and focus on the direction we move. For this, I implemented a combined camera which was camera-window and projected-focus. This means inside a window the character can move while the camera does not move. As soon the player touches the edge of the virtual window the camera starts to follow and look ahead.

You can imagine that this code would be much more complicated. As well I only wanted the window for the horizontal move but not for the vertical moves (for the vertical moves I do not yet have a clear plan). After a few trials and some refactoring later it was clear that I will use a behavior tree to implement the much more advanced logic for this camera-window and project focus logic.

Sequence<CameraBlackBoard> checkStillMovingX = new Sequence<>();
checkStillMovingX.addChild(new Invert<>(new DetectPlayerMoving(Axis.X, 0.1f)));
checkStillMovingX.addChild(new SetCamFollowing(Axis.X, false));

Selector<CameraBlackBoard> shouldFollowX = new Selector<>();
shouldFollowX.addChild(new Invert<>(new DetectPlayerCamRange(Axis.X, 4)));
shouldFollowX.addChild(new DetectCamFollowing(Axis.X));

Sequence<CameraBlackBoard> followX = new Sequence<>();
followX.addChild(shouldFollowX);
followX.addChild(new SetCamFollowing(Axis.X, true));
followX.addChild(new CamFollow(Axis.X, 0.75f));

Parallel<CameraBlackBoard> control = new Parallel<>(Parallel.Policy.Sequence);
control.addChild(new AlwaysSucceed<>(followX));
control.addChild(new AlwaysSucceed<>(new CamFollow(Axis.Y, 0.5f)));
control.addChild(new AlwaysSucceed<>(checkStillMovingX));

bh = new BehaviorTree<>(control, bb);

I had to distinguish between horizontal and vertical movements as this is decoupled. I applied the window logic only for the horizontal movement (the x-axis) which was even with a behavior tree implementation a bit tricky to achieve. The vertical movement is in parallel to the horizontal movement but strictly following. The last sequence checks if the character stopped so we can stop following. We following a character if he touches the window border and keeps following until the character stops. The behavior tree forces us to break the code up into simple tasks which makes it a piece of cake to implement and test.

This reduces the movement of the camera while the character walks back and forth within a specified window. I still have to figure out and fine-tune what is the best window size. It also looks ahead in the direction we move.

There is an underlying camera that does lerp-smoothing to make it softer on direction changes and stops. The underlying camera also does have a kickback function for the camera kickbacks if we fire a weapon to give the weapon more boom. I use the kickback vertically as well for hard landings which gives it a bigger impact.

Zoom

I added a simple “Zoom” property and extended my cameras with a setProperties to set any kind of property and every camera implementation can get whatever property it understands and apply it. The zoom is simply the distance to the character as I decided to use a perspective camera instead of an orthogonal camera. The game also looks a bit more interesting with a perspective camera.

Camera Switch

I implemented as well a simple camera switch logic. With tilded I have an object group where I define the camera area, the name of the camera type, and the camera properties like “Zoom”.

        cameraContainer.stream()
                .filter(cam -> !cam.entered)
                .filter(cam -> isPlayerInCam(cam))
                .findFirst()
                .ifPresent(cam -> {
                    cam.entered = true;
                    myCamera = (MyCamera) feather.instance(cam.type);
                    myCamera.setProperties(cam.properties);
                });
        
        cameraContainer.stream()
                .filter(cam -> cam.entered)
                .filter(cam -> !isPlayerInCam(cam))
                .findFirst()
                .ifPresent(cam -> {
                    cam.entered = false;
                });

That’s it so far. I enjoyed the journey 🙂

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Lens #17: The Lens of the Toy

cli Leave a comment

The lens #17, the lens of the toy from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

This lens is about my little character which can pick up weapons, ammo, and other stuff, which can walk, jump and shoot.

I have to answer the following questions

  • If the game had not goal, would it be fun at all? If not, how can I change that?
  • When people see my game, do they want to start interacting with it, even before they know what to do? If not, how can I change that?

It’s fun for me to walk around and shoot enemies. It is simple enough to “get it” and interact with it. Due to the COVID-19, there are no gameshows where I could test if people would like to interact with my game. But the bar should be pretty low to give it a try. But the game world is not interactive enough to just enjoy walking around and explore the levels without any goal.

The game world needs more things we can interact with. Like flying paper in an office space or dust and little debris when walking around. Also shooting should have more impact on the game world.

The outcome of this chapter will lead to a couple more topics for Lens #16: The Lens of Risk Mitigation as I have to try them out quickly which means more prototyping. Prototyping is a fun thing to do actually and with ESC (see also my articles about ESC) it is a piece of cake.

A selection of ideas

  • Destructible stuff
  • Attacking dash
  • Water which includes swimming and diving
  • Whirling paper when rushing through an office space
  • Whirling dust and debris along the way when we shoot
  • A sleeping animation if just standing around
I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Add more Details to Death Animation

cli Leave a comment

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I tried quickly if more details for death animation would give the game more depth.

And it does. Need some more fine-tuning and random but the idea is there and looks good and funny. But I need to add some random explosion if I kill a mass of soldiers. The blood fragments have to be more random in the depth axis so the helmet is not all behind the blood fragments. But this is fine-tuning for a prototype this is enough.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Primary and Secondary Weapon Switch

cli Leave a comment

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

The next idea I tried quickly to pitch was having a primary and a secondary weapon for more advanced levels. But I needed first the implementation, was only an hour to implement this and define the primary and secondary weapons, so cheap enough. I tested with an M4 and a semi-automatic handgun (Glock).

If I use a gamepad, I will have to separate the switch button from the shoot button, so that I can shoot and independently switch the weapon. Feels good. But at the moment the handgun doesn’t give any advantage over the rifle for melee attacks or in any other situation than running out of ammo with the rifle. This isn’t too exciting. I have to extend this test and see if it is a good idea to make a rifle not operatable in very close range so that the player just has to switch to a melee weapon which is the main purpose of a secondary weapon. I made as well the handgun ineffective for long-distance, the bullets lose their power over time.

One thing I observe is if my rifles are not working in melee it is not visible or clear it just does not shoot. I need some feedback. Could drop some curses from the player. This leads to another test besides just implementing the weapon switch between rifle and melee weapon. I will test this idea shortly and see if I like it. I tried ejecting some skulls and bones when he curses.

It gives now an indication that something bogs this little man when he tries to shoot at something too close. Looks cute in a way so I will go with that.
And last but not least a mini level where a weapon swtich makes sense.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Bloodstain for Bullet Exit Wounds

cli Leave a comment

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

In this blog article I tested bloodstain for exit wounds, this makes it much crueler and in a weird way, satisfying to shoot those dummies. I took the damage into account to generate the amount of bloodstain when an enemy gets hit. But this is not just limited to the enemies but also the hero.

Looks quite satisfying but might be that it becomes a bit too violent. I apply to every character, robot, and object its own hit animation, so even when I shoot at a computer I can make some fitting nice animation for getting hit. I think this looks more interesting than just color the object flat white for one frame when get hit by bullets.

The test leads to a better-organized code and easier to add new hit and destroy animations for certain objects and characters.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test More Random for Shell Ejection

cli Leave a comment

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I will play with the random factor for shell ejection, they currently look a bit like a waterfall as I only have random for the vertical component of the ejection force. So I tried to add as well random for the horizontal force. I will have to do this comparison for all my weapons that I want to use in the game.

For me, B looks a bit more vivid and a bit more out of control, actually exactly what I want to achieve. Anyway, I made a tweet but this time no feedback. I guess it doesn’t make a big difference. I go with a tiny bit more random and that’s it, looks more vivid.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Bigger Muzzles

cli Leave a comment

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I will try different sizes of muzzles and add a bit more random to it to see if that could make a difference. As well as experiment with different sizes for every gun. As well add some random to make it more vivid.

For fast prototyping, I need a simple way to switch between the weapons. There are a couple of ways. I can make a pickup command and exchange the gun with the previous gun and just put all guns in a row. Or add them programmatically and make a switch weapon button for this test.

I made a four-panel gif image with https://www.kapwing.com labeled with A: Constant muzzle with a flashlight, B: Random muzzle with a flashlight, C: Constant muzzle no light, and D: Random muzzle no light.

And made a tweet to get some feedback which is the best variant.

I also asked friends and family members. The outcome is that a bit more of the votes like B the best as it looks more vivid. The second large group preferred A because the muzzle leaks through the floor if I use a random muzzle size, which is simple to fix. Many said a tiny less random would be beneficial. There was one vote for C as the gradient muzzle would not fit the art style.

Furthermore, that way I could engage many more people on my tweet, much more than I expected.

So thanks a lot for helping me out to find the best muzzle style which is important for my game as it lives from the weapon, shell ejection, recoil, and muzzle. I will have at least 3 different sizes of muzzles, one for nine-millimeter weapons I have, one for the soldier rifles like M1 or M4, and one for the bigger guns. I will probably have to fine-tune this further.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Lens #16: The Lens of Risk Mitigation

cli Leave a comment

The lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links int this article I will get a small commission for that.

First of all, this lens is about figuring out the worst-case scenarios, what could go wrong, or what could hold my game back from being great. This is to stop thinking positively about my game. Tim Ferriss also has this in his book The 4 Hour Workweek, to overcome the fear he suggest to write down the biggest nightmare you can imagine could happen if you, for example, quit your job and start an own business and from there mitigate those risks and find solutions. And it is also about testing your ideas with prototypes. There are similarities in these books. One is game design the other is about automating your company. About 80:20. Fascinating.

  • What could keep this game from being great?
  • How can I stop that from happening?

My levels might be boring to play. So I started a series of mini levels. My first mini levels are all about the double-barrel shotgun. I keep them minimalistic to test if the levels are fun or boring to play. they are super minimalistic and super quickly done. Perfect for prototyping. It’s already clear that this might be fun, as I can motivate people for speed runs. It’s fun because you can pick up the gun and ammo and while you jump up to the platform with enemies your gun is ready and loaded. This leads to a possible smooth speedrun through a level.

I don’t have enough surprises and interactive things. One of the problems is you can leave a room without killing anything in it. Not sure if I want that. To hinder that I could have doors that open after I killed all enemies. But is this fun? I will quickly implement a “reached goal system” to find out if this is the right way. The goal system can be triggered by enemies linked to it or a simple switch. The goal system simply opens the door to the next level.

The graphical appearance is probably my main problem. I will experiment with different styles of simple blocks. And make the battle engaging the player with massive effects. Keep an eye on small details like papers that whirl up in the air will you pass. Make the ejected shells more vivid by adding a bit more random.

So there are a couple of things I would like to test:

The levels have to be addictive and be playable in many different ways. This is not just the look but also the feel of it. The player needs a reward for every accomplished goal.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

M163 Vulcan from Sketch to Model

cli Leave a comment

I modeled my M163 Vulcan tank with blender 3D for my game. The plan is that a soldier can control that tank alone, which of curse in reality it needs more people at least a gunner and a driver. And because one soldier can control this tank the player can take out that soldier and take over the tank. The next step is to bring the tank into my game and do some shooting prototyping to see if it looks cool. The real old M163 Vulcan does eject the shells visibly which fits in my concept so well.

Lens #15: The Lens of the Eight Filters

cli 2 Comments

for the feedback.The lens #15, the lens of the eight filters from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy this book through this link I will get a small commission for that.

This lens is one of those which I have to evolve as not everything is already here to answer the questions. Some of them I can answer right now, others I can not yet and I have to do this later in the process. This is one thing I learned about these filters, they can not just be applied in a specific order, this is more an iterative process and I have to apply certain filters over and over again. I don’t know yet how I will do that. Probably I have to write follow-up articles for this.

My design has to pass eight filters

  • Does the game feel right?
  • Will the target audience like this game enough?
  • Is this a well-designed game?
  • Is this game novel enough?
  • Will this game sell?
  • Is it technically possible to build this game?
  • Does this game meet our social and community goals?
  • Doe the playtesters enjoy this game enough?

I did a lot of testing to get it fluid enough and test all the functionality and I didn’t get bored to play it through. Just jumping, shooting around is satisfying and fun to do.

I think I missed to write a game for a specific demographic audience, I didn’t think of that, but I still can change or figure out what this target audience could be. Is it more for retro gamers? It is a single-player game so far, that might limit the audience. At the game show, the previous prototype was played more by young people the age between 12 – 16 years old. But the violent content could make this a problem. I might have to make dying less bloody. Even though I do just eject red cubes it does look like the soldier exploded into meat chunks. But as it is not too violent it might be playable from the age of 14. The cuteness factor I plan to build in should also make this game playable for girls not only boys.

I need to think about make co-op an option in this game so that you can play it with a friend. But that would be challenging on many levels and I don’t have any idea how to balance the levels for co-op mode. It might even be much more challenging to play it in coop mode, as bullets are lethal for everybody.

Throughout the process, the game starts to be well designed and I have a very good understanding of where I want to go and how it has to look. I like the ideas of bosses that catapult me to the next room or level or world (see Lens #13).

I think the weapons I use for this shoot’em’up platform game is novel, most often you just have a gun and can shoot endless, no need to pick up ammo for that, no reloading, and often fantasy weapons. My weapons mimic real weapons and the shell ejection is different from weapon to weapon. And you have to pick up ammo as this is a limited resource. So I think this is kind of novel.

If this game will sell I don’t know. It is my first game I will sell at all. So I kinda can not answer this question properly or I don’t know how to figure out if it will sell or not.

It is technically possible to build this game. All the main features are already there including saving the game state, die and get reborn at the last entry point with a properly reset player state, and as well AI-driven entities. I don’t see hurdles on a technical level.

There is currently no community and I have to think about this aspect as well. I don’t know yet how to do that, but it needs probably a forum where the community can exchange ideas and expectations with me but as well with each other.

And last but not least the most important questions, do playtesters enjoy the game enough. I’m currently working hard on playable very rough levels without any eye candies as I want to do this later. I need to find playtesters that would like to just play the test levels through. I will write an article to organize that. And prepare a checklist for the feedback as well.

I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.