Jump to content
  • Advertisement

wurstbrot

Member
  • Content Count

    48
  • Joined

  • Last visited

  • Days Won

    1

wurstbrot last won the day on March 11

wurstbrot had the most liked content!

Community Reputation

238 Neutral

1 Follower

About wurstbrot

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Programming

Recent Profile Visitors

3052 profile views
  1. You may want to take a look at Kotlin. Kotlin is basically a "more modern Java". It is compiled to Java bytecode (i.e. Kotlin programs run wherever Java programs do, including Android) and it's fully compatible with the Java ecosystem, i.e. you can use every existing Java library and framework with it. Thus, while Kotlin is admittedly still new and somewhat "niche" as a programming language, it is in no way limited in terms of the things you can do with it. Compared to Java, Kotlin has lots of new features which enable you to write shorter, more elegant code and use a wider variety of programming paradigms. And it might even be a little bit easier to learn than Java, since its syntax is somewhat less bloated/verbose, leaning a bit towards JavaScript.
  2. I see. Have you thought about composing your combined tile images by drawing multiple bitmap-based parts on top of each other with alpha transparency? Maybe pre-render the parts with line/path drawing in an invisible canvas and then copy the bitmaps from there? Also, keep in mind that with one canvas, you can make use of batch drawing, as long as you have enough shapes that should be drawn with the same settings. With many separate canvases, you lose this option since each canvas has its own drawing context. Another thing: You say you want to draw 100x100 tiles or even much more. Are you drawing the *entire* map at once? And if yes, are your tiles reall so small that the entire map fits on a single screen? If only a part of the map is visible at any given moment, you should of course only draw the visible tiles. This would save you a lot of time, too. I'd really like to see what image you want to draw :). I just don't want to believe that you really need thousands of individual canvases for that ;).
  3. Okay. I still don't understand which advantage you get from splitting the drawing up into thousands of separate canvases though. As far as I understand you at the moment, it is meant to be a measure against the need to redraw the entire map view even when only a small subset of the tiles need to be updated. Is this correct? If yes, you don't need to do this, as already mentioned. Just clear and redraw the parts of the canvas that have changed. Am I missing something?
  4. Hello Lode! I do not yet completely understand your use case, but perhaps these suggestions/comments can help? No. 1: If you don't need to update the entire map view on each frame, then don't do it. Only redraw the tiles that have changed. No. 2: The performance of path drawing on the canvas heavily depends on the number of state changes (i.e. changing of color, line width etc.) and "beginPath() ... fill() / stroke()" commands. It's the same concept as with OpenGL draw calls (and perhaps the very same reason behind the scenes). Try to "batch-draw" shapes that need the same draw settings, it will significantly speed up your rendering. No. 3: Are you aware that you can have invisible canvases (i.e. ones that just "hang around" as JavaScript objects, not added to the DOM), and that there is also the ImageData class which provides a low-level way to store image data? I still strongly suggest not to create thousands of canvases, but maybe you could use one (or, if absolutely neccessary, a few) extra hidden ones as a sort of buffer/cache for your line drawings? Maybe you could pre-render the line drawings to an invisible canvas and then copy parts of that invisible canvas to the right places on the visible one? Can you show a screenshot of how your map display currently looks like, or something similar to what you want to accomplish?
  5. Hello! Clearly "yes". Juggling with thousands of canvases to draw something seems like a very (very, very) bad approach to me. You could have done something like this in the pre-canvas days of HTML when your only option to draw a tile map was to use an individual <img> element to draw each tile. However, the whole idea behind the <canvas> element is that you can draw any sort of image dynamically so that you don't have to use such hacks any more. The solution is simple: Just use one canvas and paint your tile map on that. Drawing on canvas is quite fast, it is very unlikely that you run into unsolvable performance problems with that. In the end, of course, it depends on the resolution of the canvas and on the number of tiles, but a typical scenario (full HD, a couple of hundreds of tiles in the viewport) can probably be rendered at interactive frame rates (i.e. a complete redraw on each frame, including fluid scrolling).
  6. wurstbrot

    Native Android Studio Game Engine?

    Hello Jordan, In some way you are right: Every game can be considered to have an "engine", actually that's basically the game code itself (without the data like graphics, levels etc.). Speaking of e.g. the " StarCraft engine" or the "Sim City" engine is a totally valid thing to do, even if those games are not based upon a generic "engine" in the stricter and more often used sense, like omnipresent Unity or Unreal. The difference is just how de-coupled from specific game types/genres an engine is, and common understanding is that the more generic/flexible an engine is, the more it is considered a "true" engine, and also more often used of course (very game-specific engines are used for exactly one title, more generic ones sometimes for thousands). Also, note that when using a very generic engine, you still need to write game-specific code. It's just that you save writing the generic parts, since they are already provided by the engine. So, like Rutin said: As a beginner, just write your game first. You'll learn what you need and end up with a specialized engine which you can later generalize and re-use for your second game. Just don't over-do the generalisation right from the start. Not even total experts like John Carmack / id Software have started like this.
  7. wurstbrot

    Data Driven Item component system?

    Hello! Yes, AbstractComponent is the base class for all component classes. Each entity can have only one instance of one particular component class, but it can of course have multiple components of different classes. There is some discussion online about whether or not an ECS should support multiple components of the same class. I decided against that in order to keep it simple, but I think that's not your question ;). As for the armor/weapon case: My system can do that perfectly, just create an entity that has a ArmorComponent and a WeaponComponent. Actually a lot more complex things can already be done with this very simple system. I'm still quite new to ECS, and it's exciting to figure out new ways of using it. For example, one very powerful approach is to compose a single game object (in a purely conceptual sense, like "one enemy spaceship") from multiple entities (yes, multiple entities, not just multiple components). Generally, this is one way to get around the "only one component of the same class per entity" limit, but you can use it in very flexible ways. For example, you can create a "worm" character as a chain of entities where each entity (except the "head") follows a defined "leader", while the "head" entity decides where to go. All segment entities share the same HealthComponent, so no matter where at which segment the worm is hit, the whole creature suffers damage, and all involved entities die when the health drops to zero. Another possible use case is a large battleship with multiple turrets that can be destroyed separately. In this case, the turrets would have a PositionComponent that is configured to be relative to the main hull's PositionComponent, and separate HealthComponents (you'd have to make sure that the turret entities are destroyed when the main hull entity is destroyed, though). The ratio of flexibility vs. complexity/effort is really amazing.
  8. wurstbrot

    My first real game (since 20 years)

    Hello Ninja and masskonfuzion, thank you for your replies! And also thanks for the compliments :). masskonfuzion, what exactly hindered you in making the remake? If it was the same or very similar on the outside, I assume that it should be much easier to do now. Did you want to use bigger technology, something like 3D, where creating just one proper model takes longer than writing the entire original game? . I now believe that the iterative approach with a start at a very very low level might have a lot of potential even for bigger projects with a defined ultimate goal. At least for me, I think that the key is to have something playable and fun as soon as possible, so that you basically have a more or less "complete" game (almost) right from the beginning on. This also conforms with the Scrum philosophy, where you should ideally have a product that is ready for release after *each* iteration step, no matter how early. Doing this consequently would mean even a lot more work than what is required for a "normal" large project, since you'd inevitably create a ton of things that will eventually be replaced by something newer/bigger/better, but if it helps to keep the motivation high, it might be worth trying. For now, I keep working on Vectro. Even my girlfriend likes to play it, the first time ever for something I created ;). I added local multiplayer support yesterday and we played together, it was a blast!
  9. Or: "How I almost accidentally created something fun to play in just four days, after many years of starting and never finishing countless overambitious projects." Hello everybody! Today I'd like to share with you something that I'm currently quite proud and even more just surprised of. I see game development as a hobby of mine since a long time. The very first programs I wrote more than 20 years ago were games. They were very simple and very badly implemented, but still, they were games, and even finished ones. Back in the day, I completed a tic tac toe game, a pong clone and a simple 2D spaceship shooter (and also started a few things that I never finished - yes, even back then...). Later, my focus of programming interest shifted to other fields, but I returned to the hobby about 10 years ago. However, something very problematic had happened in the meantime: I became a much better programmer, and so my expectations towards myself and my projects rose significantly, and unfortunately they rose too high. While at least I was never unrealistic enough to have a "I'm gonna make the next World-of-Warcraft-meets-GTA-5-but-with-better-graphics MMOFPSRTS" phase, my projects were still too big. I even realized this early and stepped down a bit each time, but never enough. The result was a long list of started but sooner or later abandoned projects in different stages. Some never when further than a few concept thoughts, some progressed quite far, but none was ever finished. I think that a big problem was that my projects never reached a state where they became true games in the sense of something that provides a challenge and is fun to play. Each time, there was at least one part (usually multiple) that was too big, and without a foundation that was already enjoyable for the player, I became demotivated. Until just right now. At the beginning of this week, I decided to start something really, really, really small. Something that is far below my theoretical technical capabilities, but ultimately doable in a time frame short enough to prevent that dreadful loss of motivation. At least I hoped so, and I was right. To be precise, the actual project wasn't *entirely* new, but I scaled down an older idea even further and reimplemented it in Kotlin, a very nice and productive language that I had just learned a couple of weeks ago. And here it is: A graphically minimal retro-style 2D sidescrolling shoot'em'up with the working title "Vectro: Pathfinder". "Vectro" is a portmanteau of "vector" and "retro", and "Pathfinder" has two meanings here: First, it describes what the game is about: Finding your path through an asteroid field. Second, it describes the purpose of the project from a technical point of view: Developing technologies and concepts for an eventual larger game which might be an extension of the current gameplay, or something a bit different. I have an idea for this, but that's something for another thread. Also, I deliberately try to avoid planning ahead for this as much as possible for the aforementioned reasons. Finally, a few words about the technical side: As already mentioned, the game is written in Kotlin, and it uses LibGDX for input and graphics (currently ShapeRenderer, maybe someday changing to pure OpenGL, if that makes sense). The foundation is a self-written ultra-light-weight entity component system (plus a just as ultra-light-weight event bus), which results in a very small, elegant and flexible code base with loose coupling all over the place. I have used the ECS pattern in one other (unfinished) project before, but I'm still sort of a beginner with it, and I'm very fascinated by its power. There's almost zero duplication of logic, features and behavior can be added, replaced and combined incredibly easily, it's a pure pleasure to work with. All entities in the game, from explosion particles to the multi-segment "cannonworm" enemy, are defined in a data-driven way, and I know that I have only yet scratched the very surface of the possibilities. In the case that my motivation stays as high as it is right now, and I keep working on it, I'll keep you updated on the further progress. In any case, I have one big advice for everybody who, like me, frequently deals with motivation issues in hobby game development due to overwhelming tasks: No matter how much you know, start with something really really small. The feeling of accomplishment and the joy of actually playing your own creation, no matter how simple it is, is wonderful.
  10. wurstbrot

    Data Driven Item component system?

    Another thing: Also don't put methods like isWeapon() or isArmor() into your Item class. This goes towards the "god class" anti-pattern which is exactly what you want to avoid by using a component system. An item/entity should not make any fixed assumptions about what it is (or might be). Any actual "use case"- or "semantics"-related code belongs into separate classes/functions (the "systems" in ECS terminology). As already mentioned, best get rid of the Item class completely - in a good ECS design, it has no purpose.
  11. wurstbrot

    Data Driven Item component system?

    Hello! It looks good to me. My own minimal ECS is very similar. Just a few small notes: - You can directly use your Component object's type as the key for the HashMap, there is no need to go the detour over stringifying it. Just use a HashMap<Class, ItemComponent>. - Why store name and weight as direct members of the Item class? Put them in components, too, and you'll have a completely "pure" and generic ECS. - You could think about whether you need the Item class at all. In my implementation, an entity is just an integer (actually a "Long") ID, so the whole data structure of the ECS is a HashMap<Long, HashMap<Class, AbstractComponent>>. All code to manage entities, which is in your implementation partly located in Item and partly in ItemFactory, lies in a single "EntityManager" class.
  12. wurstbrot

    SFML in android

    Take a look at LibGDX. It's Java, it's modern and actively developed, and it is supposed to have very good and easy Android support (more or less one-click deployment, in theory). I personally haven't tried Android builds with LibGDX yet, but on desktop Linux it works great. Feature-wise, it is comparable to SFML, although the API is somewhat different. With some basic understanding of modern 2D graphics you'll get into it easily.
  13. wurstbrot

    Starting game dev with Java

    Hello, and welcome to gamedev.net! I like your idea, and it sounds like a good game dev starter project for somebody with a couple of years of general programming experience. You have realistic expectations, that's a huge advantage over many beginners who come along with far over-ambitious ideas. Some thoughts on how you could approach the whole thing: - Begin with a very basic console / text mode application and implement a basic simulation model of the plant: Which system components should be simulated (generators, cooling towers, pipes etc.)? Which data represent the state of each component? How does the state of each component change over time, and how do they interact? Start as simple as possible, and especially try to implement the interfaces between the different components (which data are exchanged between them?) as small and solid as possible. Try to find the best compromise between simplicity and future-proofness. This way, you can minimize the required effort to replace individual components with more complex/realistic models later on, since you won't have to make a lot of changes all over your entire program. - Then, let your simulation run in a loop and print various parameters to the console to see how it behaves. Maybe implement some reactions on different pressed keys to change the simulation state, cause problems and solve them. Then you already have a minimal version of your came and can see if it works. - Finally, create a graphical interface. There are many libraries that you can use for this. As you have already realized, it's wise to keep it in 2D for the beginning. One good option is JavaFX, which is perfect to build complex modern GUIs fast and easily (it has a visual form designer, and you can style your GUI elements with CSS). Another option, which is more oriented towards games, would be LibGDX. It's more low-level than JavaFX, but gives you even more freedom, probably better graphics performance, and the possibility to build your game for Android and web with very little extra effort. But you can still decide on a graphics library later, when you have your simulation model up and running. Have fun!
  14. wurstbrot

    Over-ambitious projects

    I think a big factor is that video games aren't physical things, but just data. Game development does - at least in theory(!!) - not require any money, supporters or physical resources beyond what most people (at least in rich countries) already own anyway. With infinite time and infinite knowledge, you could really create any sort of game completely on your own. You don't need to buy anything (all required software is available for free), you usually don't need to care about laws, and there is nobody you depend on who could just say "no" for whatever reason. Compare this to constructing a building: Even if you had all the knowledge that is required for all aspects of the construction, you still need to buy land to build on, you need to buy building material and machines, many tasks are probably physically impossible to do alone, and you need to folllow a ton of regulations to avoid being shut down. Without all these things, it is not so surprising that the efforts of game development are drastically underestimated by many people. Two more thoughts: - Since there is no initial risk involved at all, fantasizing about crazily huge unrealistic software development projects is just much less frightening. All you need to invest is some time, and if you fail, you haven't lost anything other than that time.. - The less you understand about software development, the less you can imagine how much work it is. Everbody has somewhat of an idea of what it takes to build a house, because you can see people doing it frequently somewhere in your town. But in a non-developer's everyday life, you usually don't see people working on video games, so how could you get a realistic impression of it?
  15. wurstbrot

    I Need An Older Open World Engine

    JMonkeyEngine is built on top of LWJGL, by the way. I personally wouldn't try to do this with LWJGL or LibGDX directly. LWJGL is really very low-level for such a task (except he really wants to do everything from scratch). And while LibGDX does provide some more higher-level abstraction, it appears to be oriented more towards 2D games. AFAIK, it's 3D toolkit is rather rudimentary compared to JME. Still, you are of course right. It is doable with LibGDX, and also with LWJGL. There's a very impressive guy who wrote an entire multiplayer 3D RPG in Java from scratch using LWJGL, and the best thing about it is that he put tons of videos documenting the development process on YouTube: Maybe this is helpful as a source of inspiration and valuable advices.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!