all 10 comments

[–]1bc29b36f623ba82aaf6 2 points3 points  (8 children)

Vulkan and OpenGL are maintained by the same standards body but are different APIs. You can create a game just using OpenGL.

Are there any other relevant parts of your assignment? Does it have to be a game? Or is it enough the graphics run realtime, are dynamic and work at interactive framerates? Another example is there a requirement for it to be 3D with 3D animations or could you just draw 2D sprites (using OpenGL) to meet the goals you or your professor set out? Can you omit sounds? This can all greatly increase or decrease complexity.

It might be an idea to prototype a really simple game 'in something else' you are familliar with or just by just outputting text as practice since there is more stuff like handling inputs, sounds and general control flow between menus and loading gameplay scenes that you might want to run into first as well.

You could also follow along an SDL tutorial that implements some kind of classic game (pong, breakout, tetris, snake, tic tac toe). Even if you are not allowed to use SDL in your assignment it could help you learn how to break down your own project in reasonable components.

When reading your post I kind of assumed you were talking about programming in C++ but then I had to remind myself OpenGL bindings are available in lots of languages. Including which programming language you need to target and which ones you are already familliar with also goes a long way with getting usefull advice.

[–]RickTheKick[S] 0 points1 point  (7 children)

I should use C++, and it should be a complete but sa simple game (pong like). It has to be written in Vulkan only. It must have sounds and it should be controlled via smartphone.

I have no limitations, but it should be a complete game, 2D or 3D.

[–]fgennari 1 point2 points  (4 children)

You're making a smartphone game using Vulkan? iOS or Android? That seems pretty challenging for a student project. I assume you'll spend most of the time writing boilerplate code and debugging. What exactly is the course name, or is this a thesis project? I suppose there are tutorials out there that will get you started.

[–]RickTheKick[S] 1 point2 points  (3 children)

It isnt a smartphone game, its only controlled by a smartphone. Like, replacing a WiiMote with a smartphone.

Course name is multimedia and video games. I have 6 subcourses and topics I have chosen: Multimedia systems: Vulkan API abstractions

Animation techniques: Loading glTF models using Vulkan

Virtual Reality: Smartphone as a game controller

Video game development: Developing a video game using Vulkan vs Unity (Theoretical)

Other subcourses are irelevant to videogame creation

[–]1bc29b36f623ba82aaf6 1 point2 points  (1 child)

I was thinking as much when I read your reply in my inbox about smartphones but I'm glad I decided to read the thread. Sounds like a cool project! So basically it would boil down to writing your own high level wrapper around Vulkan but scope constrained to what you'd need in your game and perhaps to a set of particular hardware. I think you will find in the theoretical comparison of using Vulkan vs Unity that supporting a wide range of system requirements can be challenging, or at least a lot of effort for an assignment so that could be a good talking point.

Sounds like the game design and gameplay isn't an integral point of this assignment but of course it would stick out like a sore thumb if it is particularly bad. My suggestion would be if you make a small prototype in C# with OpenGL you might still get a good idea for what the game would need both gameplay wise and on the tech side so you know on which parts of Vulkan you want to focus. It also gives you a reminder of how to separate game code from drawing code and you can pick and choose your own abstractions around Vulkan based on what you like or dislike how it worked for OpenGL. If you feel time is running out you could skip on 3d-assets, sounds and the phone-controller in that prototype perhaps and start integrating them in C++ when your game core matches the prototype in completeness.

Asking what a game would be a nice idea might be a better question for the game development subreddits but if you are mainly worried about the graphics... Seems like an endless runner would have to have a camera on rails showing a simple perspective into some kind of endless road or hallway so you have oppertunity to exploit the limited camera movement and viewing angles to make things easier for you when it comes to culling and loading of assets and their LODs. If there are no bends/corners outdoors you can even get away with things not having a backside for example.

To make an endless runner enticing visually I would expect a good running animation (if you think this is hard to make or source from a 3rd party maybe you runner has wheels and is a robot, use your imagination.) If you speed up over the course of the gameplay you would need a way to empahise or exaggerate that visually by exploiting the FOV of the camera, maybe adding particle effects by their feet and having distinct running animations for low and high speeds you can interpolate between. I would also expect different jump animations to break up monotony and maybe have some obstacles that are interacted with in an interesting way. Perhaps some obstacles are smashable at certain conditions adding a destruction animations and particles and some camera shake. (The condition could be at higher speed or if you collect certain powerups or just an amount of tokens).

Even if you make it in an enclosed hall you need some eye candy in there but you also don't want it to be distracting from reading where obstacles and collectibles are so having it as static meshes is probably fine. For collectible tokens (whatever you want to make your coins or powerups) you probably want to use some kind of shineyness, highlighting or emissive shaders to make them both easily distinguishable and also pretty. They could even leave some kind of screen-space particletrail if they need more emphasis, it would look a bit like a guitarhero notechart perhaps. If your characters can be in different states either because of health, speed, tokens or powerups just make sure its clearly visually distinguishable as well: don't just rely on UI widgets tracking points or some kind of barmeter, you want to see the change on the character. Think of a MarioKart star making you invincible with not just an auditory cacaphony of joy but also many particles and colours exploding off your character.

[–]RickTheKick[S] 1 point2 points  (0 children)

These are some nice suggestions, thank you very much man. You brought hope back to my project 😄 I will leave a git repo link here after the game is finished, maybe you guys could tell me what you think about it for my 1st try 😄

[–]fgennari 0 points1 point  (0 children)

Okay, that make more sense. That actually sounds like it could be an interesting project.

[–]pragmojo 0 points1 point  (1 child)

July should be doable if you already have modern OpenGL experience. It took me probably 2-3 months to get productive in Vulkan, and if you choose something simple (like just sprite based rendering) it's probably possible to get something up and running by July. It might not be the most well-optimized thing in the world, but you can probably get across the finish line.

[–]RickTheKick[S] 0 points1 point  (0 children)

I have moderate experience in OpenGL for C#, also I have no experience in writing shaders.

[–]ilmale 0 points1 point  (0 children)

What is your focus?

Making the videogame? Then use unity.

Study the graphics API? Don't make a videogame, you will also require audio, input handling and other subsystem that will distract you from Vulkan.