Alberth

Members
  • Content count

    1576
  • Joined

  • Last visited

  • Days Won

    2

Alberth last won the day on July 23

Alberth had the most liked content!

Community Reputation

9508 Excellent

1 Follower

About Alberth

  • Rank
    Contributor

Personal Information

  • Interests
    Programming
  1. Just getting started

    Hi, and welcome. Yes you are in the right place. Game development is complicated, it uses a lot of knowledge from lots of other disciplines, ie there is load of things to explore! Both game engines are very good (or so I read here, no personal experience), but they start at a much higher level than "write some code to draw something". For example, they start in a 3D world and extend from a basic setup. That means you should somewhat understand 3D, programming, and the common patterns of a game program. This sounds like a good plan. I would suggest you make another step, and just start with general programming at first. Learn about variables, statements like assignments and while or for loops, functions, classes, algorithms, and standard containers like list and map first. That way, you can understand what happens when they show you some code of a game. Similarly, I would recommend that you first write games that interact with you from the console, using text. Then switch to graphics in 2D, and finally to 3D. This makes that the interaction with the user is gradually growing in complexity, so you can concentrate more on programming. The first problem is then picking a programming language. In general, we recommend that you use whatever you already know, but since that doesn't really apply here, I'll give you list, with a bit of reasoning why that would lead you. Starting with the simpler, more high level languages: - Python. Very beginner-friendly, very hands-on, highly recommended. - C#. Defacto-standard Windows programming language, although it also runs at other platforms. No personal experience, but people here see it as an easy language too. Leads eventually to Unity. - Java. The older cousin of C#, a little simpler. When you want more control over what the computer is doing exactly, pick a bare-metal language. Generally, these languages assume you know what you're doing, and are not recommended to some one completely new to programming. - C++. Defacto-standard in this area, highly advanced, lots of features, leads to Unreal. - C. Much much older sister, used as low-level embedded systems programming language mostly, ie control electric input/output. Much much much simpler than C++ (ie a do-everything-from-the-ground-up language). The list is much less a choice for direction than you may think. Programming languages borrow concepts from each other, so what you find in one language, usually also exists in other languages, in a slightly different form. That means knowledge from one language transfers easily to another language. Especially if you stay within a single group (eg switch between different high level languages), you'llbe up to speed again in a very short time. Finally, a link with some more details on what to do in game development EDIT: Once youpicked a language, start with tutorials for that language, then write some games like mentioned in the article I linked to. That should get you going. Have fun!
  2. The main lesson in code style is that you find some set of rules that feels good to you, and learn to apply them while you enter or edit code. At some point you can do that automatically without thinking about it.
  3. Need help in creating quest/mission/task.

    I think the problem is understood, the solution is a bit more involved. This is a general game programming site. Very few blueprints are being made here (in this sub-forum). We mostly suggest them to new users that are not ready for not interested in full programming. As such, we likely don't have any tutorial. (I you want to know for real, you may want to check in the articles section, but that's the only place I know where it could exist. Don't expect much of it though if you manage to find one.) There are no guides on specific game types. Most of the code is needed for every type, so it's not useful to specialize. The few general guides that exist step in at a much lower level, eg C++, or Python. and you don't want to go there. We don't have a library of ready-made games, freely available. Many users here are indies that don't want their source linger around at public forums. Most other code eg at github is likely in the wrong language for you. If you want help in the form of another person writing the code, there is the hobby classified section, where you can apply to a project, or ask for help in your project. If you want to do it yourself, your best bet may be outside this site, at a forum specialized in blueprint coding. I have no idea where that is, but perhaps the unreal site knows. (Or else try a search engine.)
  4. Maybe your grid-based path calculation is the wrong approach? What if you convert the grid to navmesh, and then do continuous path computation? Unfortunately, the above sentence is as far as my knowledge goes, I have no idea of implications if you take that approach.
  5. Need help in creating quest/mission/task.

    Ah, ok. I wonder why you bother doing blueprint at all then, I mean, if you want to do game design, do game design. That would be in the game design forum (if you're not already posting there) rather than here, which is purely programming oriented. I don't really know if such an example is available. You could try eg github or some other site for blueprint projects, or perhaps a forum about blueprints has some announcement-like sub-section or so. Even if you don't aim for learning all about blueprint, it likely doesn't hurt to have some basic knowledge. Suppose you manage to find a piece of software, you would need to understand what you're looking at and where to change things, which implies you should have seen some blueprint code before, and preferably even made some things, since learning by doing still works the best.
  6. JoeJ was not saying to adopt the standards or adopt libraries that implement the standard, he was suggesting to just look at how they solved the same problem as a source of inspiration.
  7. Never programmed an AI, but as far as I know it's horribly complicated, and common practice is to "cheat" like you do. I believe it is mure important to keep a random element in it, it is very boring if you always get the same set of enemies, and if they always make the same moves. Random elements also hide somewhat that you're cheating, they have the effect of getting less precise knowledge than you really have.
  8. Computer industry isn't know for keeping old stuff around for long. Most people here use modern stuff, and don't keep old stuff around. That holds very much for games, which are always at the edge of what is possible today. My guess is your best bet is the Internet. Search for game software for your platform. Programming languages evolve slower, you may have more luck there. You don't say what programming experience you have, but if you have none, you could look for Python (python.org), Java (oracle.com), or C# (not sure how fast the latter evolves, maybe too fast for your platform). The problem then moves to getting supporting libraries. I don't know how far back you can find old versions for that, but the search engine is your friend!
  9. Need help in creating quest/mission/task.

    Blue prints at least seem simpler, I don't know them so I cannot say for sure though. No offence, but at your expertise level, you likely cannot judge complexity of your idea. What may look simple to you can be horribly complicated in reality. Computers have a very hard time doing seemingly simple things. I have this same problem with robots. Complete teams there spend eons on picking up an object, I mean, how can that be difficult?? Grab the thing, and lift from the table, how hard can that be??? Yet apparently it is, or they wouldn't need a whole team for it, right? It's very hard to estimate how difficult something is unless you already know how to do it. There is only one way to find out how difficult it really is, and that is by trying to realize it. So start reading about, and experimenting with blueprints.
  10. I find it annoying enough that I have started using the button in the overview.
  11. Need help in creating quest/mission/task.

    I'd start with working through some unreal bluieprint toturials. That should give you some ideas of how things work. After you did that, come back to your game to see how to apply what you have learned. You may also try to find a dedicated unreal forum for blueprint users. This site is more a general public which may not have all detailed blueprint knowledge that you need.
  12. I believe that pixel art is designed to be shown at exactly one resolution, namely the one it is created for. I don't know about you, but zoomed pixel art (and I don't even consider non-integer ratios, because ... just yuck!) just looks so "zoomed", it lacks the detail you'd expect at that zoom level. As such, I consider zooming of pixel art a dirty cheap programmers hack rather than a graphics artist preferred way of doing things. Ideally, you'd have art at every resolution you want to support, and you adapt levels to the display. If that's not feasible, you'll end up in the mess of resolutions and size of displayed level, like you describe. I would like to suggest that you consider zoom-level of art as a separate issue from size of the displayed level. The former exists also if I buy a screen that has a double (quadruple?) higher resolution than my current screen, but is physically the same size. The latter is also somewhat related to the game itself, for some games it's no problem, while for others it is a huge problem. For art, one option you may not have mentioned is downscaling rather than upscaling. Make the art in the highest resolution, then reduce its size as needed. It won't be as good as when you hand-design it, but it should be better than enlarging pixel art. This way, it might be more feasible to create art in various sizes. Make the large one, automagically reduce the size, then do some small touch up to correct the most obvious flaws. (I am not an artist, so no idea how feasible that is.) For level design, it may be possible to design levels such that it doesn't matter (much) how far you can look ahead. Hide eg coloured keys in a box, move surprises to behind a corner (ie when you enter a new screen). For focus, make the light and moving area near the player, and keep him so busy he has no time to look at the other parts of the level. Other options is to move the "point of no return" to much earlier. When I select one corridor, I have to walk further before I see the surprise, but make the corridor long enough such that the player with wide screen also has to walk into that corridor. You can also adapt the level, space out the obstacles depending on the displayed screen size. You can possibly add some background art here and there as well to fill the area. Player with the wide screen has to walk/fly/jump/crawl further, to reach the next stage.
  13. I quite hate these silly "If you press yes, the computer will forget about the posts you have not read yet. This may cause confusion if new posts are added at a later date that respond to the posts you have not read." nonsense that nobody ever reads, and just presses "ok" a second time.
  14. Depending on the number of particles vs the number of particles to track, it may be useful to store the latter separately from the former, and accept non-contiguous access there.