Jump to content
  • Advertisement

All Activity

This stream auto-updates     

  1. Past hour
  2. Meet the almighty PLACEHOLDER! Isn't he cute? His round face, his little nose... I think he is the all time most used protagonist for games. He does all the hard work, and later another fancy model gets all the credit. So unfair. Let's give him proper animations for such a hero. I used Unity animation editor to create an animation controller and a bunch of animations for movement, idle times and combat using only position, rotation and scale transforms. Now my combat implementation was firing triggers in the animation controller and, suddenly, all this tiny capsules were alive. Even the flow of combat was easy to follow, admiring heros swinging their swords instead of squeezing my eyes looking for the damage line in a log. I admit it, they grew on me. I found myself cosplaying them and... well...let me tell you they are cute as hell. Fierce warriors I also added some more UI elements and some code to show Action Points cost while moving. All that felt like a big step. But just two warriors... even for testing purposes... was too boring. I needed more characters, and everybody knows behind every great warrior there is a great mage. And it would be a good test for the combat engine, as it would add more diversity to abilities. While implementing mage abilities soon I realized I was missing a key ingredient of combat and visual wowness... particle effects. Now I have to stop here and admire how many good videos about this subject youtube has. So many people doing such a great work. I would like to, at least, mention the videos from Gabriel Aguiar. Almost all particle effects I ended up using are "inspired" by his tutorials. Thanks, man. So now with the mage. I chose three basic abilities: Fireball. Of course. It works as a projectile. Fireblast. To introduce critical hits to combat. Firewave. An AoE. Everybody loves AoE. So much magic. When the spells were implemented, the game suddenly became gorgeus. It's amazing how much can movement and particles add to the most simple visuals. As I was enjoying the upgrade in graphics, I started messing around with post processing effects. It added another whole level to visual appealing. So much with so little... It was very basic, but it definitely was a game. Except for one thing. A huge thing, in fact. I was playing both sides all the time. Not very interesting. The fun part is beating another one, even if it is a dumb computer player. And so the next step became clear...
  3. GoliathForge

    When code just isn't enough...

    sure you bet. I started with c/c++ in the dx5 era. Found a fondness for ogl2. What am I doing? I'm porting my older stuff. Back and forth for a good time2 as we raced for raster and compute power. Then c# came around, I resisted at first, but actually Unity reversed that. UDK was my favorite. <sob> Yup, different mind set than frameworks. UE doesn't run on my machine, so no joy yet. pffttt. blender2.8 isn't on the table either (i5 HD9300 / the gt260(M) is cooked). So nah, I'm cool with what I do. It's great. I'll beef up the horse power when the time is necessary. Too many good things to be had right here and still a little localized glamour. Nice to have had the chat. edit: oh whoops...so are you saying look at my source please? I'm not certain. Every structure would be slightly different depending on the goal of the system. so, I'm sorry, I might have missed it.
  4. Where are you from? Your English seems fine to me. I'm not a very experienced developer yet and more a beginner, but I began so I should be able to give you some starting advice. You definitely want to use an engine or framework, otherwise, you need to build everything from scratch. I worked with Monogame and Unity and I can recommend you an engine. You got more control with a low-level framework like Monogame, but all the necessary stuff should be doable in Unity too. In my experience, you end up writing to much code for very basic stuff when doing low-level game development. Just try to make a simple text box where the players can enter a name, and you need hours for a good one. Also, you should be good at the programming language because it's all you got to make the game. I would recommend Unity. It would save you more time in the long run, and if you want to work with others together or get a job in a game dev career, it's useful to have knowledge about it. It may seem bloated and takes more time to get into it, but it will pay off. And maybe you should try to start with a way less complicated game. The hardest thing is to finish a game, starting to make them is always easier, and 5 years is a very long time. Your first game will always have not the best code, artwork, game design and marketing. You can practice it by making some smaller games first. I scraped over 100 hours of work, I used to make my first game but the game idea wasn't that good and working with Monogame was time-consuming. I found a new better game idea and need to get more into Unity, and I'm sure I can make my game in less than 2 years realistically. I wanted to make something short but hadn't a good game idea, so I'm now doing something bigger, which I probably could finish in a year, but you can underestimate the amount of work pretty easily, so I calculate with less than 2 years since I don't have finished a real game before. In the end, it was a very good choice to work on a different game. But if you work on a bigger game you need to do some good developing practice like DevOps, to ensure that you don't waste too much time on something bad. You need a good 2D platformer to make some money with it because there is a lot of competition in this genre. And Unity which is based on Monogame supports cross-platform development, so you can deliver your game on all operating systems, consoles and even mobile devices.
  5. I plan to write monthly updates about this project and fill each blog with a decent ratio of images to text. As I find blogs with large bodies of text hard to stay engaged in. I started this project almost 3 months ago when I finally finished a much needed update for my previous release. I was very much inspired by T.A.B.S (by Landfall) for this project. The animated physics in their game create satisfying simulation and unpredictable moments that normal animations don't provide. I had to try it myself. February I recycled many of the art assets and movement code from my past overly ambitious projects™ for this project so I could jump straight into creating the enemies and implementing animated physics. I watched this YouTube tutorial by TheCooperJ. He uses hinge joints to rotate rigidbody limbs by mimicking the rotation of an animated duplicate. Example GIF from tutorial: Here's what my implementation of his method looks like on a humanoid rig: Yeah, someone call him a taxi. So I did a Google Search and found out about a beautiful asset called PuppetMaster. This asset is extremely well made and optimized, I highly recommend it. It took a while to figure it out but I got there after a long night of pressing buttons and scratching my head. March I added a basic castle and some grass and used polyverse skies for the beautiful skybox. I also made a new enemy player model. I used the Unity NavMesh system and set up some basic AI and used animations from the asset store as placeholders to get a quick first prototype working. Even achieving this much made me feel genuinely happy and satisfied. I LOVE PHYSICS. I was about fall asleep sleep one night but instead I immediately jumped out of bed and onto my computer (I'm certain every dev has done this at some point) to implement the shield bash mechanic: April This is where the project is at now. I made a new scene, added more environment, adjusted the colours and lighting. I redid the enemies animations in Blender and improved their AI. There are 2 types of enemy right now: Archer and Melee. There are currently 4 items. I'm looking forward to adding more items that are more exciting and less generic, maybe even guns for a laugh. They can all be equipped in the left or right hand, you can throw them all, the bow is the only two handed weapon. The rest can be dual wielded. Even the shield: Here's a YouTube clip of me absolutely destroying these blokes skulls. I added a brutal head shot crunch sound. The game is still unnamed, I hate naming things, comment below if you have a suggestion. I have started conceiving a narrative for the game, I think explaining it is boring so I wont. Thanks for reading. I'll write another blog in a month, maybe. I actually wrote this blog spontaneously, never done this before.
  6. Osidlus

    Turn-based multiplayer combat

    Thank you for the comment and proposal. That frustration mentioned is not only from time having to wait- but also gives faster characters too much of an advantage. In reality both slower and faster character acts at the same time. And thing is some actions are kryptonite to the others and even slower character can succeed. Imagine toothpate lid drops you into water basin- starts spining around at speed yet you can catch it by putting your hand at relatively slow pace on to the outlet... I would definitely like to try your proposal as a game, but that hard gating on actions is something I personally do not like - rather see continually losing- by not acting...
  7. Steve_Segreto

    [ES2.0] Copying Internal Array Buffers

    You probably already realized this, but glCopyBufferSubData is available in GLES 3.0 if you would rather migrate from 1.0 to 3.0 in one step.
  8. Embassy of Time

    When code just isn't enough...

    Just a random thought: Once I have a very barebones version of the first test of the game, why don't you look it over and make a better one from its template? Kind of team experience, but still independent!
  9. Hi, Im 16 year old im a pretty good coder in unreal im creating a fishing game for my brother maybe if its cool i gonna publish it but i need help with the animations its like impossible for me to let the animations look good so if you wanna help me out Add my discord Koekjes_boy#2964
  10. Today
  11. SoldierOfLight

    Sharing shaders between PSOs

    It's going to depend on the driver. D3D will de-duplicate the bytecode and only send it to the driver once, but whether the driver recompiles it based on the surrounding state in the PSO, or whether it simply references it, is up to their discretion. It's also possible that they could have a middle ground and use a base compile followed by multiple patching steps for the surrounding state.
  12. Hello, I'm not a native english speaker so please bear with me, I need some help here, I'll get straight to the point. I just joined this site. Over the last year, I fleshed out my game, the mechanics and nearly completed the artwork/assets. Its a 2d action adventure platformer. Eventually in a bout 5 years when I finally complete it, I would like to maybe commercialize it, when I do I would like to be able to port it to consoles too. I should state that it is a side project, and even though I have a general timeframe, I find the quality of the end product to be more important than the speed at which I complete it. I think the quality comes from the knowledge I have gained and will be gaining. I have adept knowledge of C++, some basic C# syntax knowledge, python and general java syntax knowledge. I know the language but have yet to apply it fully with respect to game development. I do not know how I should begin in terms of resources.. That is where I need some help. I have made simple games with the help of tutorials but I find that its harder for me to learn when I'm not actually working on a passion project. I looked at game engines and frameworks as a starting point. For something as simple as a 2D linear adventure story-based platformer, I doubt I'd need something like unreal engine. I looked at Unity and Godot. I found Unity to be.. more bloated, yet helpful with regards to quick development, but I find myself wanting more control and freedom, independence from game engines. I don't need most of the services they're providing.. I looked to game frameworks like SFML, LWJGL and monogame, which seem rather low-level and overwhelming in terms of the starting point. I found SFML to be the easiest, but have been considering LWJGL for java's versatility in Mac and Linux; I'm using windows. I heard that java isn't exactly supported on consoles, which means if I use LWJGL, i gain the convenience of coding the game once but forsaking console support, which I am not sure is a decision I'm ready to make as of yet. With regards to SFML, though I find it easy, most tutorials cover small arcade-y platformers, wheras mine is much more complex, bigger and exploratory. The environment is designed by me alone (one big world where the events are taking place) and not generated by seeds etc. I am unsure of the way forward. It's basically a knowledge problem. At the end of the project, not only do I want to produce something, I also want to learn as much as I can and be free to code anywhere and not rely on an engine like unity or godot. What would you recommend I choose? I would appreciate a response and maybe some insight on those frameworks and engines, if any. Thank you.
  13. GoliathForge

    Suggestions needed for "Humanitarian game" mockup!

    I don't have world awareness, but... 'Open the door' 'Help (obj) across the (street)' 'pay the (coffee) bill' 'pick up (litter) in others area' <end try> just to kick it off.
  14. GoliathForge

    When code just isn't enough...

    I've been dying to take a 3D artist position or auxiliary programmer (engine side / game play side) on a project that matters. My own ideas excite me, so it's hard to find peace in outside ideas. But as we know, ideas generally have only so much value. Becoming a gear in a larger mechanism is desirable to me. So far though, from my experiences the road is full of holes an no pegs. i think mostly because the groups that I've touched were designers only or those that were managers in training needing direction input or proceeding by braille. But then again, it's difficult to know what I want with the team player experience (I don't have in this exact field). Thanks tough. I'll try to keep watch on this.
  15. I have 3 PSOs that all use the same code for their vertex shader. If I pass the same pointer into each of their D3D12_GRAPHICS_PIPELINE_STATE_DESC::VS fields, does that mean that they'll actually share the vertex shader? Or are they each going to make individual copies of the shader? (And by extension, does doing this eliminate a state change on the GPU?)
  16. It may not be the deepest of challenges, but in my work to create a semi-functional mockup of the humanitarian game I was poked to design, I need a bit of help. More precisely, I need suggestions on what Good Deeds / helpful actions players may be tasked with in the game. Things like "Help Benny with his homework" or "Help old man Gunther with his grocery shopping". Ideas for good deeds, without having to change the world. Anything you can think of is appreciated!!
  17. Embassy of Time

    When code just isn't enough...

    I have DOZENS of square pegs and HUNDREDS of round holes! I am very open for help What kind of squareholing(???) are you thinking of??
  18. SIr Pep

    Godot or not?

    Thanks very much @AticAtac!! Exactly the comment I was waiting for. I'm currently turning to dual booting my Mac because it's getting older, and since Godot is supported on Linux I may just take this time and dive into it.
  19. GoliathForge

    When code just isn't enough...

    good luck If you ever need a square peg to fit into a round hole, I might be your guy Ah, to play with others, the dream is sweet, the reality is something else to me so far. Nice to see a go at breaking of the mold in a sense.
  20. In order to stay out of trouble, I'm going back to work. Previous Blog Entry Today's topic is my drop in game state manager system for moving between game screens such as an introduction sequence, main menu hierarchy, game play and first say on app termination. I don't remember where I initially found this gem because it has been quite a number of years that I've been reusing this. The concept is simple though. Manage screens as a stack. Push a screen pointer to the back to become active and pop to activate the previous. So how do we get a system like this up and running? The following is a condensed version (bare bones). Two objects start us out, First a manager and an abstract base class. From the abstract, we derive the game screen objects. Each screen object handles their own behavior not knowing anything about the others. // file : GameState.cpp #include "olcPixelGameEngine.h" // <-- yours will be different #include "GameState.h" #include "States/intro.h" #include "States/game.h" #include "States/menu.h" using namespace Core; std::shared_ptr<States::Intro> introState; std::shared_ptr<States::Menu> menuState; std::shared_ptr<States::Game> gameState; void StateManager::initialize(olc::PixelGameEngine* engine, vec2 clientSize) { this->engine = engine; introState = std::make_shared<States::Intro>(this, clientSize); menuState = std::make_shared<States::Menu>(this, clientSize); gameState = std::make_shared<States::Game>(this, clientSize); states.push_back(menuState); #ifdef _RELEASE states.push_back(introState); #endif } void StateManager::shutdown() { introState->shutdown(); menuState->shutdown(); gameState->shutdown(); } void StateManager::changeState(States::Base_state* _state) {} void StateManager::pushState(States::Base_state* _state) {} void StateManager::popState() { states.pop_back(); } void StateManager::handleEvents(eStateAction _action) { switch (_action) { case eStateAction::pause: if (states.back()->name == "game_state") states.pop_back(); break; case eStateAction::play: if (states.back()->name == "menu_state") { int w = engine->GetDrawTargetWidth(); int h = engine->GetDrawTargetHeight(); RECT rect = { 0, 0, w, h }; states.push_back(gameState); } break; case eStateAction::win: if (states.back()->name == "game_state") { MessageBox(0, "you win", "", 0); //winState->winnerName = gameState->getWinnerName(); //winState->winningTime = gameState->getTimeString(); //states.push_back(winState); } break; case eStateAction::loose: if (states.back()->name == "game_state") { MessageBox(0, "you loose", "", 0); //states.push_back(scoreState); } break; case eStateAction::quit: if (states.back()->name == "menu_state") PostQuitMessage(0); if (states.back()->name == "game_state") { ::ShowCursor(true); ::ClipCursor(nullptr); states.pop_back(); } if (states.back()->name == "score_state") states.pop_back(); if (states.back()->name == "win_state") { // todo : record score gameState->reset(); states.pop_back(); } break; } // end switch(action) } void StateManager::update(float deltaTime) { states.back()->update(deltaTime); } void StateManager::draw() { states.back()->draw(); } With the manager out of the way, the base class for the stack-able objects. // file : base_state.h #ifndef _engine_core_states_base_state_h_ #define _engine_core_states_base_state_h_ #include <olcpixelgameengine.h> #include <string> namespace Core { namespace States { // abstract class Base_state { public: Base_state(void* _manager, std::string _name, vec2 _clientSize) { pManager = _manager; name = _name; clientSize = _clientSize; } virtual void initialize() = 0; virtual void shutdown() = 0; virtual void pause() = 0; virtual void resume() = 0; virtual void handleEvents() = 0; virtual void update(float _deltaTime) = 0; virtual void draw() = 0;s void* pManager; std::string name; vec2 clientSize; protected: Base_state() { /* empty constructor */ } }; } } #endif Correct me if I'm wrong (please) but of all the reasons to use polymorphism, this case is one of the better (subtyping). To be able to keep like items that are different in a common container. The derived class header would be as expected. Base class overloads in place plus specific functions and variables that would be required to make the new object behave as it will. Nothing new. I'll admit, I'm trapped in the common cycle that most online tutorials mold where the loop is divided into update / draw / check state / repeat. Is it correct? <shrug> So all this may be familiar and you hate it, or it's new and reader be cautious. The basic take away here is the stack concept. On the main loop side, we declare a Core::StateManager instance and initialize. During the loop, update and draw calls to the manager fire. I feel I don't need to list any additional modules but will list an example derived menu class. #include "menu.h" #include "../GameState.h" using namespace Core::States; void Menu::initialize() { rectPlay = { 360, 140, 440, 160 }; // 80 x 20 rectQuit = { 360, 165, 440, 185 }; // need more data or buttons are a known size } void Menu::shutdown() {} void Menu::pause() {} void Menu::resume() {} void Menu::handleEvents() {} void Menu::update(float _deltaTime) { } //template<typename ... Args> //std::string string_format(const std::string& format, Args ... args) //{ // size_t size = snprintf(nullptr, 0, format.c_str(), args ...) + 1; // Extra space for '\0' // std::unique_ptr<char[]> buf(new char[size]); // snprintf(buf.get(), size, format.c_str(), args ...); // return std::string(buf.get(), buf.get() + size - 1); // We don't want the '\0' inside //} void Menu::draw() { olc::Pixel colorDefault = olc::Pixel(255, 255, 255); olc::Pixel colorHover = olc::Pixel(255, 255, 0); // _ // .--- todo : don't like handling user input inside a draw routine...fix me ----. \_(O,O)_ // V V ~ \ // ------------------- Game Menu ------------------------- Core::StateManager* manager = (StateManager*)pManager; olc::PixelGameEngine* e = manager->engine; POINT cursorPos; cursorPos.x = manager->engine->GetMouseX(); cursorPos.y = manager->engine->GetMouseY(); e->DrawRect(rectPlay.left, rectPlay.top, rectPlay.right - rectPlay.left, rectPlay.bottom - rectPlay.top); e->DrawRect(rectQuit.left, rectQuit.top, rectQuit.right - rectQuit.left, rectQuit.bottom - rectQuit.top); std::string cursorInfo = "CursorPos "; char buf[16] = ""; //string_format(cursorInfo, "Cursor Pos");// { %d, %d }", cursorPos.x, cursorPos.y); //manager->engine->DrawString(10, 20, cursorInfo); _itoa_s(int(cursorPos.x), buf, 10); e->DrawString(20, 20, std::string(buf)); _itoa_s(int(cursorPos.y), buf, 10); e->DrawString(70, 20, std::string(buf)); vec2 textOffset = { 25.f, 6.f }; int x = int(rectPlay.left + textOffset.x); int y = int(rectPlay.top + textOffset.y); // Play ------------------------------------------------- olc::Pixel textColor = colorDefault; if (::PtInRect(&rectPlay, cursorPos)) { textColor = colorHover; if(e->GetMouse(0).bPressed) manager->handleEvents(Core::eStateAction::play); } e->DrawString(x, y, "Play", textColor); // Quit -------------------------------------------------- x = int(rectQuit.left + textOffset.x); y = int(rectQuit.top + textOffset.y); textColor = colorDefault; if (::PtInRect(&rectQuit, cursorPos)) { textColor = colorHover; if(manager->engine->GetMouse(0).bPressed) { if (MessageBox(nullptr, "Are you sure you want to quit?", "Serious?", MB_YESNO) == IDYES) exit(0); } } manager->engine->DrawString(x, y, "Quit", textColor); } The game screen state would be similar but behave as what the main game play would be. Every valid screen pointer lives the life of the application but only the one at the back of the stack is active at a given time. This has served me well for adding game state transitions in custom work. Input and drawing are engine responsibilities so there is a member pointer to contend with in the manager. Perhaps not the best approach, but I don't know of alternatives other than a hard global or worse, singleton. But a subclass gets this functionality through the manager held engine pointer. Crappy note to end on perhaps, but that's where I am. It works, I called it good and have been reusing a number of times. Tips from the leet are always appreciated assuming my words are better than a hodgepodge of nonsense.
  21. Embassy of Time

    When code just isn't enough...

    I have this theory. It goes "nobody has any real idea what they're supposed to do until they're done doing it". Case in point, the project to gamify good deeds that I have gotten somewhat financed (working title simply "The Good Game") is still under frantic construction. And yet, I've only ever written maybe a hundred lines of code (HTML, JavaScript and PHP). How is that? Well, much to my chagrin, the massive bulk of this project is... talking. The design of the game is novel, as in "nobody seems to have made anything even resembling this kind of game before", so every idea, every concept, every feature pilfered from some other game, they all need to be discussed endlessly, regarding their need, the consequences of bringing them in, potentials both short and long term, and so on and so forth. That's a lot of talking!! Right now, at the very least, we're dealing with actual game design, rather than abstract concepts like gamifying ethics, player psychology, social impact, etc. No graphics to speak of, and the proposed method for testing is... amusing? It's chaos, is what I'm saying. But, hopefully, creative chaos! Wish me luck. I need it!
  22. This is of yet a place holder blog entry which I intend to edit as I progress. This go around I'll be using the software pixel plotter I mentioned in a previous blog entry. At this time of writing, all I have is my napkin design concept, which I think I really have something here.... you know...the whole no weapons thing...We let that simmer for a week. Hop over to the forums for some inspiration. Will my game idea cut it? Shouldn't matter. But it does you know it. So whats' happening, a partial automatic background simulation running pretty smooth and reliable. I'm testing with some debug visuals, all good. My bodies go stable, perfect..,,whoops it somewhat quickly starts to sink slowly. Slowly, at a speed that appears to be on purpose. Umm...little bug. I go find it, and stop...wait...that's actually pretty cool. I have it trigger when it completely buries itself. So, slap a feature label on it instead. Sha-bang. Now we're talking Okay that's week one. And...we're back. Week two and maybe a few. I got distracted, but didn't ignore. My little pixel got tucked in every night and thought about during the day. So, I've always thought this challenge game thing should be played slightly different. Everyone goes off to do one of their next best things, or show off this or that. In the end it's great. But what about the middle...right? <-- Here's my go at it for today. The following listing is my collision code. I'm using this goofy thing that might be worth a share. Right out of the gate, don't laugh. trying to write a little game here. Thanks, actually this is one of the 'why do you do it' things right here. Those times when math dances that dance and it's so nice to looks at. If this is one of those times, we'll see But right now the simplistic approach at its finest and I think per pixel. Check it out, I'll walk though real quick like. physicsObjs is a std::list of an abstract class. Then inheritance gives me other objects but all in the same list. So we walk it and early out if it's not active. Here we go...now expert I am not, but I want to do something cool. I choose a lite physics sim and first up is that downward force. All right, equals mc what? Telling you... truth. didn't even bother to look. I don't care. This is my game, we're doing it how I want...it's going to be banging...What's that value 9.8 something, size should effect this thing and we'll chop it into a time slice. Nice, let's build our first force direction do-dad. Umm, I appear to be short on some overloads with the framework I choose. No problem, long hand it, mix it with some outside influence and put it in a next desired holding spot. Clamp it for good measure. Now that we know how fast we want to get there, we calculate where that might put us and hold on to that. So what this is, is a circle against 2D pixel terrain. Terrain is stored on a grid larger than the screen size so we have some indexing math to contend with. I start off with a check against the grid height of the memory terrain so I don't flow into memory that's not mine and I'm scanning down. I want to look at all the pixels in the lower hemisphere of my search grid. So I build that rectangle and walk it bottom up. I assume that against terrain, my objects only care about bouncing and a bounce will never be directly above. Hence only test the bottom half. Object-object collision is a separate pass. What is important to me also is where is this bounce going to take me. So here's what I do. From the bottom center I go horizontal negative per pixel, on hit, I record the vector offsets. No big boy math. If it's terrain, take that raw offset and add it to the reflection accumulator. Found one, okay stop. move up a pixel and go again until another hit or just pass through. Repeat on the positive side. Now we have this ugly 2d vector, so I normalize and then scale it by the magnitude of what we were. Squeeze it with a cheep decay and off we go. // update physics --------------------------------------------- for (auto &obj : physicsObjs) { if (obj->bDead) continue; // apply force .................................... float gravity = 9.81f * obj->mass * fElapsedTime; vec2 force = { 0.f, 0.f }; // todo : mass / size maybe / etc.. obj->acc obj->nextVel.x += force.x; obj->nextVel.y += (gravity)+force.y; // clamp velocity ................................. if (obj->nextVel.x > 10.f) obj->nextVel.x = 10.f; if (obj->nextVel.x < -10.f) obj->nextVel.x = -10.f; if (obj->nextVel.y > 10.f) obj->nextVel.y = 10.f; if (obj->nextVel.y < -10.f) obj->nextVel.y = -10.f; // calculate desired position obj->nextPos = obj->pos + obj->nextVel; // potential positions established and next desired state set (free form) obj->bHitThisFrame = false; // reset for next run (hmmm...not sure i want or need) // check against terrain (sudo raycast) vec2 reactionAccumulator = { 0.f, 0.f }; // sum all positive hit vectors int numHits = 0; if ((obj->nextPos.y + obj->radius) < terrain.nMapHeight) { // assuming a positive downward velocity (only test lower hemisphere) int xL = int(obj->nextPos.x - obj->radius); // left index int xC = int(xL + obj->radius); // ---- center vertical ---- int xR = int(xC + obj->radius); // right index int yT = int(obj->nextPos.y); // slice center top int yB = int(yT + obj->radius); // bottom index float objR2 = obj->radius * obj->radius; // radius squared for (int i = yB; i > yT; i--) { // scanline search for terrain (bottom up) int scanlineIndex = i * terrain.nMapWidth; for (int j = xC; j > xL; j--) { // scan center to left- break on first hit if (terrain.map[scanlineIndex + j] == 1) { vec2 v = obj->pos - vec2(float(j), float(i)); if ((v.x * v.x) + (v.y * v.y) < objR2) { reactionAccumulator += v; numHits++; break; } } } for (int j = xC; j < xR; j++) { // scan right to center - break on first hit if (terrain.map[scanlineIndex + j] == 1) { vec2 v = obj->pos - vec2(float(j), float(i)); if ((v.x * v.x) + (v.y * v.y) < objR2) { reactionAccumulator += v; numHits++; break; } } } } if (numHits > 0) { vec2 unitReaction = reactionAccumulator.norm(); obj->vel = unitReaction * obj->nextVel.mag(); obj->nextVel = obj->vel * 0.94f; // decay if (numHits >= ((yB - yT - 1) * 2)) PostQuitMessage(0); numHits = 0; } obj->pos = obj->nextPos; //todo : get closet to contact point // object position wrap terrain screen if (obj->pos.x > terrain.nMapWidth) obj->pos.x -= terrain.nMapWidth; if (obj->pos.x < 0) obj->pos.x += terrain.nMapWidth; } else { obj->bDead = true; } } Okay, that was fun. Last night I shoe horned in my game state manager, adapted it to draw in this fashion with the base menu switch I use to start out with and it should be mostly game play stuff this week... I'm excited to pull out one of my real old sprite sets for this player charcter. "I'll be back" And a week old screenshot Let's do this thing...still pumped. Part two continues here.
  23. This sounds like an amazing project, I wish you all the luck with it's development. I hope you're able to help many people with the result.
  24. RoKabium Games


    Keeping up with the twitter hashtag of screen shots on Saturday!
  25. Hey hey hey! It's you again! This is happening, this is now, this is your favourite weekly update blog coming to you right now! But to be honest, this week wasn't quite as proactive as usual. There was a lot of waiting involved, so not a whole lot of things were done. However, there's still some new stuff to showcase, so let's get right to it! The Fountain First, let's get the simplest thing out of the way. I've added a new interactable prop (akin to rest areas): the fountain. This props can, like rest areas, spawn at the center of a normal room if the player is lucky. When encountered it gives the player the opportunity to drop a few coins in for smalls luck boost. However, this comes with a caveat... If the player puts too many coins in, then the fountain's motor will overheat and explode in a big way, voiding its effects and hurting the player in the process. The actual limit is actually not linked to the player's luck but is randomly picked. Will you try and get the best possible luck bonus or will you play it safe and just put a few coins in? The choice is yours... The Landfill Redesign Second, let's talk about the landfill. For those who didn't know, the landfill is a special room where the player has the opportunity to regain their previously discarded items. Previously it was quite a barebone and didn't really had any distinctive things in it. Now the landfill looks a lot more like a landfill, with garbage piles and garbage cubes filled to the brim with, well, garbage. Each discarded items lays on a compact garbage cube in the middle of the room. But that's not all! Sometimes, if the player is lucky, they can find low-quality items in those big garbage piles. Hurray for recycling! Finally, the room also has a looping fly sound (like in most cartoons and whatnot). I'm also planning for some kind of cartoonish miasma coming out of them. Pretty disgusting if you ask me... Minor Updates An exploding bomb now leaves bomb pieces behind when exploded; The shards of malls' breakable windows now got unique models; Added a metallic map to all of my shaders. Optimized, refactored and fixed shaders. Fixed a long-lasting bug with the player controllers' step snapping physics Next week Next week is going to be all about adding at least two new special rooms that I'm currently working on. There's also the redesigns that, to be honest, I didn't really work on last week. Aside from that, there's always the rest of your usual suspects like relics, capacities, enemies and items. Last week was quite a slow week too, full of waiting and more waiting. Now I'm determined to set aside the more compiling intensive work to really add some meaningful things rather than adding a small insignificant detail that takes an hour to compile...
  26. Wolf Beaumont

    Building a Team

    My name is Wolf Beaumont and I've worked on five games over the past decade. The first was a free game that I produced which we completed (SolarBASIC). The next three were designed and produced by me and they failed spectacularly for various reasons. But I learnt some great lessons from these failures. My latest game is Dragon Kingdoms, a digital card game which we are currently wrapping up development on, which has been a great relief and sense of achievement for both me and the team, for whom it is their first game. I'm looking to put a new team together, to develop prototypes and explore our more interesting results as full games. The idea is to create several small games with quick development cycles that we can easily take to market without the need for funding. By quick I mean 3-4 month pipelines. So at this stage, I'm open to any and all applications from every skillset. I'm looking to put together a highly-skilled team looking for a tight unit that is result orientated. Any revenues would be split equally amongst the team. I believe I'm a great designer and producer, but I've got plenty of failures in my past both in and out of my control. What I can say is that I'm committed and loyal. If you think you've got the skill and you're looking for a team that sounds like this, contact me on discord (I prefer real-time communication and we'd be communicating ultimately via discord anyway). Discord ID: Wolf#6791 Sincerely, Wolf P.S. If for some reason Discord doesn't work, my email is wolf.beaumont at gmail.com
  27. Alessandro

    Points constraint approach

    Hello, I'd like some suggestions and pointers about what approach I could take for this specific matter. I basically have a line made of n points (well, a hair): when I move one or more points, I need the other points to be constrained so that the hair length remains the same. I'm currently using verlet integration which works just fine: the only issue is that requires a 2nd step, so first, the points are moved to "unconstrained" positions; after that, the verlet integrations moves them back to the correct positions so that are constrained (and hair length remains the same). So I was wondering, there is an approach that would require 1 single step? Perhaps I could achieve the same behavior with Euler or quaternions? Thanks for any suggestion!
  1. Load more activity
  • 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!