Jump to content
  • Advertisement

TMII

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

-1 Poor

About TMII

  • Rank
    Member

Personal Information

  • Role
    Animator
    Artificial Intelligence
    Artist
    Character Artist
    Composer
    DevOps
    Environment Artist
    Game Designer
    Game Trailers
    Level Artist
    Level Designer
    Pixel Artist
    Producer
    Programmer
    Technical Director
    UI/UX Designer
    Visual Effects Artist
  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. TMII

    What do you imagine here?

    Honestly, I thought it would going to be a skeleton but this is probably due to a rather popular 2d lightning tutorial, where a girl turns into a skeleton in the dark... My second guess was credits. The balloons fly too slow and are too well arranged for me to expect anything exciting or gameplay relevant.
  2. That is amazing input, thank you. I would tone it down a bit, since the ships are moving anyway if the "timer runs out". It is just a matter of if you want to turn, or if you do nothing and keep flying straight. I also had the idea, that the player is able to plan a movement path ahead of time. However, I can very well see where you are going with, with your argumentation. very true. Never thought about that. Yeah. However I also had never planed to add anything to the map in that regard I guess I can remove Idea #2 from the list. With Idea#3 I could allow ships to fall into fixed "speed" steps. So the ships move every 10, 20, 30, 40, 50, 60... seconds. That could give a nice feeling of "speed", without looking at the numbers, straight.
  3. There is supposed to be a map view with all ship's location relative to one another, where the player can plan the ships movement. In all 4 axis aligned directions. I don't see a problem giving them a small angle of freedom, though. I guess Weapons Engineer. It is crucial where and how many weapons you place on each side, as well as the positioning of your critical systems: Ammunition storages can explode, a defunct cooling system makes your other subsystems not work anymore, generators keep your ship powered. A ship is lost, when its core gets destroyed. Every single tile and subsystem of the ship can be damaged, destroyed and repaired during battle. No, not planned at all. Thanks for your input. I am not disagreeing with what you are saying, but my biggest fear with idea #3 is that the player might lose overview and control of the situation fast, when not looking constantly on the map if there are multiple ships involved. Contrary to what I could imagine with Idea #1: If you know that all ships move every 30 seconds, you can manage your ship for 30 seconds, then return to map view and see how everything unfolds. Might be boring and repetitive, who knows. What do you think about that? I really like the idea. Gets more tactical options on the map. Maybe some kind of moving "storm" that damages and/or drags your ship with it. I don't understand.
  4. I need input from other people! I am in the middle of developing a game right now and I am losing my mind currently about where to go from here. I start to have troubles defining "what is fun?". I have literally no feeling for that, anymore. I have some ideas where to go from here but I would love to hear your thoughts about designing a fun battle movement system. Thank you very much. Let me introduce to you what I already have implemented, first. Which is, to be precise, a crude battle system: - The player can build his own spaceship, hire crew and battle another spaceship that is spawned on any side of the ship. The crew and ship works and organizes itself completly on its own without any player interaction. Here is the problem: The spaceship is actually static! As is the enemy ship! They don't actually move and you can't just scroll from one spaceship to another. Bullets are despawning outside of one ships "world" and respawn in the enemy ships "world". This is due to technical limitations. Similar to the game Faster Then Light. So I need to come up with a clever, fun and strategic movement system during the battle phases. I got some crude ideas, all of which happen on a "map": All spaceships move on a grid. Every ~30 seconds, all spaceships either move forward one space or turn left or right but stay on the same tile. - Thoughts: Tidy, strategic and simple to understand and overview Idea #1 but every ship can move multiple tiles in one turn, depending on the "speed" of every individual ship. - Thoughts: Might compromise strategic thinking. Idea #1 but every ship can move in different individual time intervals, depending on the speed of every ship. - Thoughts: Might compromise overview of the situation. All spaceships move freely on the map, in realtime. - Thoughts: Boring? Maybe you have another idea? Would love to hear your input.
  5. I ask you kindly to refrain from such statements in the future. I understand this discussion got a bit heated with C#/C++ already. I am ending this discussion from my side now with a last statement that such a trivial thing is not even nearly comparable switching between any other two languages, especially from or to C++.
  6. Since C# was and still is a plain Java copy from Microsoft and since both have developed in parallel nearly in the same direction during the last ten years, I wonder what you are speaking about. Syntax, functionality and philosophy wise they are basically the same with a different naming scheme. It takes a few minutes and a bit Stackoverflow to switch between both languages for a skilled programmer. Not so easy with C++ because it has a totally different design philosophy. It's not enough to simply know a syntax, you have to think in a language. It is increadibly difficult to switch between C++ and C# mind-wise. People switching from one language to another often complain about random things in the first days because they are still stuck in another mindset, not being able to find the same solutions for the same problems. For their own worst case scenario they dismiss it completly. Luckily it keeps being their own problem.
  7. No, it has not replaced C++, neither in game development nor in any other programming league. Choosing any tool over any other for everything is fundamentally a mistake. C# does not even come close to the most demanded languages in industry, which is by far JavaScript, Java and C++ in basically all technological fields. Also of note here is Google's Go and Python in engineering and scientific fields. It is a trending programming language but so is Rust (-> C++) and Kotlin (-> Java) and I highly doubt it is going to beat those on the long run. Choose the right tool for your task, switch if nescessary. Don't hesitate. Don't be afraid.
  8. C# is not "the most friendly" but I would consider C# and Java to be languages that have a very good "what you can do with it" vs "difficulty to learn" ratio. Also your choice has a big impact on which further projects you can work on, because C# might not be the most popular choice outside of game development (Unity) but you can easily jump on other high level languages like Kotlin or Java if you start considering a programming career in broader jobs. C++ on the other is pretty bare metal, difficult to learn and in my experience people have a hard time grasping the concepts of high level languages later on. Although, C++ is the most powerful language to rule them all. You picked C#, great choice, I advice you should definitly go for Unity to boost your projects then. Game development is extremly difficult because you have to understand so many different concepts and combine them. Unity takes a lot of that from your shoulders. Trust me, I did it the hard way, when Unity was not a thing - I've learned a lot on the way but I also lost an extreme amount of time. Just my two cents: Learn C# first, get the basics, before you jump head first into game development. And don't go for Youtube videos. They often lack quality, knowledge and are probably the worst medium to learn programming of. And no, I don't think any paid service is worth it. I wish you all the best on your further way Cheers
  9. Yes, that's clear. Iterables with lambda support. I was speaking about practical application of your library. I.e. I don't see a word in your docs that trainings can be saved. So one would need to train the library at every start and then the question comes up where to take the training sets from. I was kind of thinking out loud, that one could take the language files already packed with every program. Or you would have to pack some training texts but would probably run into the problem, that these random texts might not give good training results but you would have no idea because you don't speak that particular language. In your example, to generate Viking names, this is no problem of course. I wonder if it would work with Chinese characters as well. Oh btw. is it intentionally that it says "single-s e x dataset" in your docs (without the spaces)?
  10. Nice, I will try it out for my project. May take a while for feedback, though, as I am not in a stage where I would need it currently but this could get handy for a future build. I am trying to wrap my head around how this text stream would look like. Do I just feed it with my language files? This is definitly not overkill in the "Plug-and-Play" Java world but rather normality, not to say "expected" in the Java community. Gosh, this is why I love this language so much. In C++ you get some project files and an outdated manual for how to compile that bullsh** for some random Linux distro.
  11. TMII

    Upon the Stars

    Have you ever wished to burn your fingers on your smartphone? Are you tired of your smartphone always charging, when plugged to its power cable, instead of uncharging for once? Then this is the right project for you: TMII's multithreading monster Upon the Stars - A Technical Proof-of-Concept Game: In the middle of development, this game currently consists of the ship editor seen in the video above and may never be finished as a game, but as a proof of concept for the multithreading technology it was built together with/upon. This game is a real time and turn-based strategy mix, where the players command their ships in realtime but steer them over a turn based map at the same time during combat. Multithreading: 8 cores, one GPU. Driven by the Active Context-based Threading (ACT), this project is the first very first to be built upon this in-house developed framework. Bottom left in the video you can see the computations per seconds per core on an Samsung Galaxy S5 Neo, 8 core. Rendering happens on a dedicated thread at 60 FPS capped. It's remarkable how ACT makes heavy and noticable calculations - like raytracing, matrix calculations and the in-house AI - nearly disappear in the profiler on a weak device like the Galaxy S5, by splitting a workload over all available cores. The multithreading overhead is even negated to the additional caches made available. Artificial Intelligence: An artificial hive mind is used for decision making and navigation for all crew members on board each ship.This library is developed in-house, as well, and based on the work of Dr. Alexander Repenning's "Collaborative diffusion: programming antiobjects" - it has matured a lot, since though. It scales very good with number of agents and complexity of surroundings, with little to no overhead. It is an excellent alternative technology for A*. Rendering: OpenGL ES 3.1 Rendering is a big problem on such small devices. Every little draw call has an impact and needs to be avoided! This is often a major problem for 2D games, especially when they are based on tile-rendered terrains. Upon the Stars uses a buffered rendering technique to render nearly unlimited* tiled worlds in high complexity without impacting the overall FPS. Rendering is done on one dedicated thread and runs between 30 and 60 (capped) FPS so far. Besides communicating with GPU, no additional calculations are done on this thread. *very very very large
  12. Thank you. I am going to avoid uniforms then. It's the same with glBufferSubData it seems. I read that a lot of times and I was wondering about that because it reads like it has "disadvantages" using instancing for small meshes but as far as I can tell, drawing one quad vs drawing a thousand quads instanced does not make much of a difference. The point sprite version might be a tad faster (probably important for a AAA title but a waste of time for me at the moment) but has the disadvantage that they disappear at the edge of the screen quite visibly.
  13. Thanks for the answers, I was taking the hint to use a profiler and I found it stalling nearly a second mostly here (~600ms) glUniform3f(location, value0, value1, value2); and here (~300ms) glUniformMatrix4fv(location, 1, false, dataArray, 0); this is enormous and I have absolutly no idea why this is. It gets even weirder because glUniformMatrix gets called another time, right before the stalling one and it has no visible performance impact in the profiler (literally). I noticed that updating the VBOs with glBufferData has a relative tiny overhead, so I changed the uniforms in the shader to attributes and the problems are gone. Does someone know why this is? Do uniforms cause some synchronization issue? *Edit And if it wouldn't be already weird enough, as the program keeps running this stalling gets noticable worser.
  14. Yes, thank you, even though I believe both methods are exactly the same, with the second being to render the fonts dynamically on program startup. What I do not understand about his approach (I am not a C++ guy) is he uploading a new quad for every character to be rendered?
  15. I was trying to implement text rendering and thought I was really smart using instancing in order to improve performance. Jesus, I couldn't have been more wrong than that. The question is: What is the best approach now? Do I really have to go the "OpenGL 1.1" route and upload every character model repeatedly to a VBO? The initial idea was that every character is basically a "quad" rendered at a specific "position", with character specific "scale" and "textureCoordinates". The idea was to save the character specific data in an uniform vec4 array on the shader side, accessed with a single "characterIndex" that is sent per instance in order to save performance by not sending tons of duplicate data. It works, but it is really slow and I think the problem is accessing the array: #version 310 uniform mat4 projectionMatrix; uniform mat4 worldMatrix; uniform mat4 modelMatrix; in vec4 in_Position; in vec2 in_TextureCoord; in float characterIndex; in float advance; uniform vec2[256] texturePosData; uniform vec2[256] scaleData; out vec2 pass_TextureCoord; void main(void) { int index = int(characterIndex); vec2 texturePos = texturePosData[index]; vec2 scale = scaleData[index]; gl_Position = projectionMatrix * worldMatrix * modelMatrix * vec4(in_Position.x * scale.x + advance, in_Position.y * scale.y, in_Position.zw); pass_TextureCoord = in_TextureCoord * scale + texturePos; } By just rendering a few strings, the FPS went from 60 to 5. The question is: What do I do now? Is it a better approach to pack and send the arrays (2*vec2) in a VBO to the shader? I tried to avoid just that, because a string with "AAAAAAAA" i.e. sends a bunch of duplicate data, where before, only the index referenced a specific character. So there is not only much more to upload for every rendered string, there is also 4 times more data to be prepared on the CPU side. Thank you very much
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!