• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

231 Neutral

1 Follower

About wurstbrot

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

2618 profile views
  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. Mobile 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.
  6. 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!
  7. 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?
  8. 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.
  9. I Need An Older Open World Engine

    How about JMonkeyEngine (JME) ? It's Java, it's open source and it's "code-centric" (i.e. much more a library than an authoring system, although it does have a visual editor, too). It's not "old", but as long as your GPU supports at least OpenGL 2.0, you should be fine. The rest depends on how complex you make your 3D world. A downside might be that it's not an out-of-the-box "open world" engine. This doesn't mean that you can't build an open world game with it, and not even that it is somehow suboptimally suited for this kind of game. But it'll require some work, compared to more genre-specific and feature-complete RPG engines like the one that e.g. Morrowind uses. I like JME a lot, and since I see some parallels between you and me (focus on coding, slight aversion towards the big players on the engine market), there's a chance that you might like JME, too. Just don't underestimate the amount of work that lies ahead of you. Considering this, there might exist solutions that could help you to reach your goal at least a bit faster than JME would. But since it seems to me that you prefer a feeling of self-achievement and maximal control of what's going on code-wise over fast progress, JME might be worth checking out.
  10. Dealing with frustration

    @RousingNotion: What you experience is perfectly normal. Programming - and especially game/graphics programming - simply *IS* an enormously wide and complicated field. Except for perhaps a few "genius" people with extremely high intelligence, learning all the stuff that is involved here just takes huge amounts of time, concentration and patience. I've been programming since about 20 years, have a M.Sc. degree in computer science, and I'm still a beginner in 3D graphics and learn new things almost every day. If you want to learn all the details, just go ahead and stop worrying about slow progress and whether you might be "not good enough". You are. If you want to get results faster, consider lowering your ambition to understand *everything* in detail and pick a 3D engine that does the wearisome low-level stuff for you (but even then, it will *still* be difficult). Most importantly, do what you enjoy. If you feel like you need a break, take a break. Rome wasn't built in a day, too, after all.
  11. Engine / Libraries / Work environment

    Hello! JMonkeyEngine ( http://jmonkeyengine.org/ )is exactly what you're looking for. I'm a bit surprised that it wasn't mentioned here already. It's Java, open source, (OOP) programming-centric, very flexible and quite powerful. I can't compare it to other engines like Unity or Unreal, since I haven't used any of them yet, but I love JME since I discovered it two years ago. You should definitely try it!
  12. Fair enough :). Nevertheless, thank you for your reply!   I very consciously decided to go for this type of game because of its relatively simple gameplay mechanics. Having a grid-based world with discrete states for everything makes a lot of stuff like collision detection and AI a lot easier. As I already mentioned, I really wanted to start something that has not-too-bad chances of ever getting finished. I already have clean and stable implementations of level structure, flexible "data driven" tile part definitions, player/world interaction (e.g. walking around, collision detection, switches etc.), map editor and level/samegame persistence (saving/loading). And all this in (I think, didn't count though) less than 200 hours of coding. Perhaps you can also create more complex things faster if you rely more on pre-made code from engines like the omnipresent Unity or Unreal, but that's not what I want to do.   Besides, I was quite impressed of how much fun Grimrock actually is, despite (or perhaps even *because of*) the ancient mechanics. It's so old that it is fresh and new again :).
  13. Hey Nafei!   Your work samples look great, and you might be exactly who I'm looking for.   I'm currently developing a 3D "dungeon crawler"-style game with mechanics similar to the "Legend of Grimrock" series or older titles like "Dungeon Master" or "Eye of the Beholder" (although I never played the latter ones). Basically, it's a first-person view RPG where you move in discrete steps from tile to tile in a grid-based world. Simple 80s gameplay, but with (more or less) modern graphics.   And that's exactly where I need an artist like you. I'm primarily a software developer. While I *can* create simple 3D models, and I'm even getting better at it, it's not what I love most to do, and it takes me a lot of time. So it would be awesome if you could support me.   Currently, the whole thing is a non-commercial "just for fun" hobby project, although I'm sometimes playing with the remote idea to sell it, should it ever get finished and be good enough. If this should ever happen, I'd of course share with you a fair amount of the profit, but for now, it would be a non-paid job.   As for seriousness and outlook for success: I'm a professional software developer with more than 15 years of programming experience and a M.Sc. in computer science. I know how to get done what I want to do. I also know that game development requires *huge* amounts of effort and knowledge even for seemingly "small and simple" projects. I have learned from several overambitious and failed projects, so I'm aiming rather low this time and try to apply the most simple and pragmatic solutions for everything, at least for a first prototype.   The setting/story of the game (and thus the required artistic style) isn't set in stone. Currently I'm doing mostly engine development, which is independent of the theme. Right now I'm aiming for a sci-fi setting, but if you prefer, say, medieval fantasy, we could talk about it. I can even imagine a "steampunk"-style hybrid similar to the Torchlight series, which I like a lot.   I'm currently in the process of preparing a "technical documentation for 3d artists and level designers", since I planned to ask for artistic help here in a few weeks. The document isn't complete yet, but I could send it to you as soon as it is, so that you can get an impression of what is required.   Write back if you're interested!
  14. Two or more monitors

    I had two old 19" 1280x1024 display for many many years until I replaced them with a single 23" Full-HD display 2.5 years ago. Just a couple of weeks ago, I had enough of it, bought another 23" Full-HD and went back to dual-screen.   Personal tastes are different, but I clearly prefer multiple smaller displays over one huge one. First, the pixels-to-cost and screen-size-to-cost ratios are *way* better. Second, you can position them at different angles to have an optimal viewing angle at both. And for work, the gap/bezels don't bother me much.   The thing that finally made me buy a second display again was editing of UV texture coordinates with Blender. On a single screen, there's just not enough space for a reasonably sized 3D view, 2D texture image view and a couple of other property editing sidebars. Of course, it has advantages for many other sorts of work, too, but these have already been mentioned.
  15. IMHO this is simply because the diagonal perspective is more "3D-like" and thus makes the view of the game look more natural. If you randomly select any rectangular object within your current real-world field of vision, chances are close to 100% that you see it from some diagonal angle and *not* perfectly aligned with (respectively, orthogonal to) it's edges. Furthermore, you get a much better impression of an object's shape if you look at it like this, because you can see three of it's sides (two walls + top) instead of just two (front wall + top), as it would be the case if the viewing angle was parallel to the side walls.
  • Advertisement