Jump to content
  • Advertisement

Ivorne

Member
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

482 Neutral

About Ivorne

  • Rank
    Member

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Education
    Production
    Programming
    QA

Recent Profile Visitors

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

  1. You said that it is open source. Where is the link to the source code?
  2. Ivorne

    algorithm challenge

    Is this a school assignment? It is of good manners to state that outright in your first post.
  3. Making memory allocator for bullets is nonsense. Correct approach on your scope is to have one object that manages all the bullets of the same or similar type in a scene. It can store the bullets in a std:vector or other container. Each bullet can be represented by few numbers - position and dirdction / velocity and possibly a subtype (enum). I would imagine that you update position of your bullets each frame. So you can just iterate over all the bullets in your vector and update them. In this update, you can check in the beginning if the bullet is stil on the map and if so, update it. If not, just remove it from the vector. As for rendering, you can either keep a pointer to the bullet sprite instantiation with each bullet in the vector, or you can have just one sprite and draw in on all the positions in vector (in a loop) during render phase.
  4. Ivorne

    Beginning to make games

    Consider trying openframeworks, it is more of a graphics framework rather than full game engine, but I find it very pleasant to work with, so it will be a good beginning. It will give you direct way to start to understand how computer graphics work, which is a huge part of game programming. It does not hold you by hand all the time, but C++ does neither. It will not help you with the general architecture of your game, you have to try to do it by yourself. It is a good thing in the beginning, but you may later run into problem that your game will get too big for how naively you designed the architecture (everyone has this problem at one point sooner or later). When that happens, you can either try to apply vast software engineering theory to build good game engine on top of it, or you can decide to skip that and move to bigger engine (possibly Unreal? I am not sure, I chose the first mentioned approach). You will greatly benefit from experience with low level framework like openframework when dealing with a big engine, because you will have better position to understand, how it generaly works inside. So, that is my oppinion, hope I helped.
  5. Ivorne

    Not motivated at all

    I also used to lose motivation on previous projects. I am now woking on a solo project for almost two years and I did not run into this problem yet. After I read your post, I was thinking about why is that. There are two connected reasons: 1. Life expectancy of my code went rapidly up. I am using code that I wrote year ago and I often don't feel, that it needs rewrites or refactoring. So when I write new code, I make sure that the API is optimal to be sure, that the resulting code will be long lasting contribution to the project. 2. I percieve my project as a complex structure of relatively independent parts. There is lots of parts and system that I can work on. I can focus solely on art for few weeks and I know that it is worth it even if it was the only succesful part of my game. Because I could use that part in another, simpler game or I could publish it as standalone art.
  6. Ivorne

    Arcade game opponent logic / AI

    For example you can have a variable 'target' which denotes the slot which the ghpher currently wants to steal. This value will be randomized each 5 seconds (once per 300 frames on 60 fps). Then each frame when you want to move the gopher, if target slot is right from gopher, move 1 pixel to right, if target slot is left from gopher, then move 1 pixel to left, if the gopher is under the target, then move 1 pixel up. Time to re-randomize target and the gopher speed can be tuned so that the gopher sometimes unexpectedly changes target but is still able to reach some targets. You also want to somehow handle the possible situation, that the random generator selects empty slot.
  7. Cocos2d-x - You can use it as a game framework or you can read its sources to understand how it works. Supports 2d and 3d but lots of code and api is for pure 2d. Has scene tree. It doe sno thave particularly good architecture or code quality, but it has lots of users and features and good performance. OpenFrameworks, Cinder - Use it as framework or learn from their sources. They do not have scene tree. They have excellent api if you are a beginner and you want to learn about opengl 3 style of rendering. I would really suggest at least swiftly reading through api and tutorial to one of these frameworks if you want to know how proper rendering works. But have in mind, that they are missing the scene tree, so you would probably have to implementi it yourself in proper game (not that hard). godot - Slightly older framework for 3d with scene graph. The rendering code is very easy to read and duplicate in your own rendering framework and has some great simple (tutorial-like) architecture designs in 3d rendering. The api is not perfectly prepared for modern rendering techniques but it is a good beginning for newbies. Ogre3d  -  Slightly older framework for 3d with scene graph. I would not suggest it for 2d games. It has slightly more features and users than godot, I think. I would suggest to look into ogre3d if you want to know something about gui libraries, lots of gui libraries used in ogre3d can be used stand-alone in your application. Or you can just look at their apis and implementations to learn about gui programming. SDL, glfw, freeglut, sfml - These are the simplest frameworks that only provide thin layer between your multiplatform c++ code and windowing system in target os. They basicaly create a window and allow you to fetch inputs form keyboard and mouse and to call opengl functions. Use them as frameworks if you want to write in opengl. Or read tutorials for them - many tutorials for these libraries are in fact good basic tutorials for basic opengl.
  8. Talking from experience of how i started programming, I would suggest anything, that has a long tutorial in his native language (10-15 parts minimaly) and is not difficult to install (even if you install it, difficulties with specific installation may occur). As I rememner, I wasn't initialy very interested in tutorials, but after a few parts, I was realy dragged in and was able to sacrifice most free time to go through the rest. The platform / language you choose does not have to be specificaly focused on game. If publishing the result is not expected, then some game-like projects can be done pretty much in everything. Now I was talking about programming. But if there is a chance, that he might become more interested more in art, then you might also want to choose platform, on which he can focus strictly on art (for people interested in art, the programing psrt is something like instalation for programmers - necessary boring task you want to get rid of as fast as possible).
  9. Or "Shared Fate". All damage, buffs and debuffs that are applied to a unit are also applied to all nearby friendly and enemy units. This is interresting, because it can be used to your advantage if you do not have many units.
  10. Variation on that AOE effect. You can have a unit, that has -5 armor aura that applies also to allies.   Or you can have positive non-stackable AOE aura. For example +5 armor to allies. If you would have two units that give this aura, you would still have +5 armor on each. Or you can say that the aura is not on self, so it would be most effective to go in pairs. Also you can make it so that auras do not generaly stack. So if you have one unit that gives +5 armor and second unit that gives +5 damage, third unit will only get +5 damage (suppose that this aura has higher priority). This will not realy encourage separation of units, but it is a aura mechanic that does not directly encourage units to stay together.   A non-stackable attack modifiers, for example a poison attack. On attack, 'poisonned' debuff is applied to target unit. This debuff deals some damage over time. Or you can have 'frost' attack modifier that slows target. You can also say that these attack modifiers do not stack on target with each other. So you can have an attack modifier on each unit in this faction and only one will be working at a time on single target. This is interesting, because it does not directly penalizes player for having units together, but it is ineffective to attack single target with all units at once.
  11. Note that it is discouraged to use 'using namespace' in header files. You should also avoid using 'using namespace' in cpp files if you can substitute with 'namespace something{ }'.
  12. Your snake is sequence of segments. Natural way to represent the snake is using linked list: struct Segment {     Vec2 position;     Segment * next_to_head; }; Head has empty next_to_head field. Next_to_head of segment after the head points to head and so on.   Each frame, you will update positions of heads and positions of all following segments and move them towards their next_to_head segment. You should update segments in specific order (from head to tail or from tail to head). Or you can have two copies of each segment, one at the beginnig of the frame, second at the end of the frame and in that case, you could paralelize the simulation.   The simple version, how to update a segment is to force it segment to be in given distance from its next_to_head segment: void update_segment( Segment * segment ) {   constexpr float RequiredSegmentDistance = 15.0f;   if( segment->next_to_head )   {     Vec2 dist_v = segment->next_to_head->position - segment->position;     float dist = sqrt( dist_v.x * dist_v.x + dist_v.y * dist_v.y );     float move_dist = RequiredSegmentDistance - dist;     if( move_dist > 0.0f )     {       Vec2 change = dist_v * move_dist / dist;       segment->position += change;     }   } } If you want it to look more dynamic during acceleration and decceleration, you will not have fixed distance of segments. Distance between segments will be bigger if snake accelerates and lower if snake deccelerated.
  13. The solution highly depends on what do you want to allow users to do with that interface.   There are two options: Let user code use the underlying hardware abstraction layer (SFML) so that they can use all its features. You said you do not want this, so you probably want to go for the second option - let users do only things supported by your interface api.   This interface could work with images or with meshes. Working with images is easier for users of your library, meshes give them more capabilities. If you work with images, then user code will send data describing source filenames of images, their positions and other transformations and modifiers (uses alpha, is clipping/stencil mask). When working with meshes, user code will provide data about positions of vertices, vertex indices that form meshes, materials, shaders etc. It is more low level, it is better for 3D with higher visual quality and it in fact mirrors the approach of Opengl 4 and direct3d 11.   I would suggest to not be afraid to use some idioms from data driven programming. What I mean is that you should not have a class or interface with method 'render' and then traverse scene tree and let everyone render itself directly. You shoul rather have a class that could be called RenderDataSystem. This would store all the data needed for render which I described in previous paragraph (set of images and their positions or set of vertices, meshes, materials and shaders). You will have one instance of this class and objects in scene tree (for example myFramework::Sprite) will just modify data in this class. Then you can have a RenderImpl class. You can have more of these and choose different ones on different platforms. This RenderImpl class will once per frame read data from RenderDataSystem and will draw them to screen.   If you do it like this, then myFramework::Sprite will at most contain pointer to RenderDataSystem and all code that uses SFML will be in RenderImpl class. Users or the library will have no need to modify the RenderImpl implementation unless they know that they are doing something naughty :-).
  14. Ivorne

    Graphic Editor Timed event

    I think the best would be to:   OnMousePressed:     previous_time = current_time     start updating   OnMouseReleased:     stop updating   OnUpdate:    current_time = getCurrentTime();    setAlpha( getAlpha() + alpha_per_second * ( current_time - previous_time ) );    previous_time = current_time;   Essentialy: keep updating your object when mouse is pressed on it and in each update use duration of the mouse press from previous update to set desired value.
  15. Thank you for answers. You are right that if I want persistence (for save and load, replays, logs etc.) when using mods, I need to derive the persistent ids from string names. External database for mods would work too, but I definitely do not want to centralize anything that I realy do not have to.   For this specific problem (names of input actions) I decided to use pointers to instances of an ActionEvent class as runtime IDs and string names as persistent IDs. I will have a global (in current game context) map that maps string names to ActionEvent instances. Each instance of ActioEvent will have its name as a member.   Listeners will connect to these ActionEvent instances and will receive callbacks from them. So in runtime, I will be able to use these pointers most of the time instead of string names. String names will be used only when registering new input or new ActionEvent instances and to save user-defined keybinds.
  • 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!