L33TMaster
Member
I lurk and mess with tiles, not much else to say.
Posts: 108
|
Post by L33TMaster on Feb 29, 2016 13:23:17 GMT
Any progress?
|
|
|
Post by ckraniak on Mar 16, 2016 15:38:52 GMT
Not much recently. I kind of get into programming grooves now and again, and atm I'm not in one, more in an irl groove for now. That's the main reason I said I wasn't going to promise anything and made it open source: I can't guarantee I'll be interested forever. Pretty good chance I'll come back to this, since I still have things I want to do / am interested in, just can't say when. Maybe in a few weeks or a month.
|
|
Fool
Junior Member
Posts: 58
|
Post by Fool on Mar 16, 2016 15:46:06 GMT
Do it CK. Love technical stuff like this. Almost makes me want to pick up C++ again.
|
|
L33TMaster
Member
I lurk and mess with tiles, not much else to say.
Posts: 108
|
Post by L33TMaster on Mar 16, 2016 16:04:53 GMT
Not much recently. I kind of get into programming grooves now and again, and atm I'm not in one, more in an irl groove for now. Yeah, I get that feeling too from time to time. Anyhoo, glad to see you didn't disappear from the face of the Earth and decided to check in.
|
|
|
Post by ckraniak on Mar 16, 2016 16:14:09 GMT
This is basically a big itch-scratching project. I like to read about lots of things programming related, and having a practice codebase is nice.
Consider it a game engine project for now. Once the dispatcher is done (mostly writing test cases and adding a "Stateful" capability) and the CES thing, it should theoretically be straightforward to add new functionality.
|
|
|
Post by ckraniak on Mar 16, 2016 16:49:08 GMT
Not much recently. I kind of get into programming grooves now and again, and atm I'm not in one, more in an irl groove for now. Yeah, I get that feeling too from time to time. Anyhoo, glad to see you didn't disappear from the face of the Earth and decided to check in. I'm learning just how valuable your encouragement and interest is. You're one of the best people on this forum just because you're so encouraging. Thank you.
|
|
|
Post by ckraniak on Apr 30, 2016 9:32:16 GMT
So zaimoni's work makes this a bit redundant, but since it's really a personal just-for-fun project to code things I feel like coding for fun ... whatever.
I was able to finish out the basic testing of the dispatcher. Bugfixes, mostly not too bad, definitely better than the first try. I do have it sending a message from the WM_QUIT case to the AsciiDisplayCESystem, so it's basically decoupled things nicely so far, which was the point, mostly.
So I ran into problems on my first try at a dispatcher. Probably the bigger one was I was never able to decide how to pass data from the event raiser to the handler in a generic way that I liked. (Should it use char** the way main() does? A vector of strings? A void*?) The other one was where I couldn't decide how to map events to event handlers. Do I have an "ANY" event that runs all handlers? Do I have a dedicated "shouldRunEventHandler()" in the dispatcher, and how do I avoid it becoming cluttered with special case handling from possible future systems? I did make a shouldRunEvent(), and very quickly discovered that was going to introduce problems, and the enums felt like they were getting clunky, so I gave up on that approach.
My solution to the event-to-handler mapping was to have events described by "types", where an event can have more than one type (e.g. an event with types {"on_keypress", "on_numkeypress", "on_num7keypress"}) and have the handlers tell the dispatcher what event types would trigger them with a boolean-type string (e.g. "on_numkeypress AND NOT on_num5keypress"). It currently requires the type to have a no-argument constructor, but this isn't too bad for a code wart IMO. The data passing was "solved" by using templates ... for certain definitions of "solved"; it works, anyway. The events and handlers will need to coordinate types, but the dispatcher itself won't need to care, and I won't need to clutter my headers with enums or make special enum-only headers to define the events. The bigger wart here is the GE_HND macro that makes event handler declaration "convenient", for certain definitions of "convenient". Templates, function pointers, lambdas, and preprocessor macros in the same few lines of code. Maintenance is for losers anyway. This is better than it used to be.
I also decided that having the dispatcher manage game states (as in, did the "in_game" vs. "paused" type of things) would be nice. I have no idea why I thought this, but I decided it wasn't substantially worse than the template crap I was already doing. Essentially, I can add an event type on the fly to the effect of "state_STATENAME", so that event handlers that specify "state_STATENAME AND (other_conditions)" only fire in the certain state. The dispatcher manages the actual doing of this, so you only need to call setState(). I'm not sure if this was a good idea, but it felt like a natural extension of the hyper-generic event type system.
So in order to have my "walk" handler (in the Movement system) only fire in-game and only if a numpad key that isn't 5 is pressed, I just give the handler a "match string" of "state_game_running AND on_numpadkeypress AND NOT on_numpad5keypress", and the handler is only executed if an event with those types (or the specified boolean combination of types) are met. Then I can have WndProc() kick out an event of types {"on_keypress", "on_numkeypress", "on_num7keypress"} every time I press Numpad 7, and I can have the program call "setState("game_pause")" in places it makes sense.
So I find myself writing the CES code now. I think I'll transition the current game to be functioning entirely on the dispatcher, i.e. decouple the WinProc code from the different CESystems that are driving the current game's functionality. Then get the entity concept fleshed out and get the systems running on entities. I've got a pretty good idea of the system structure I want now, so once that is all made I think the actual game logic coding ought to go fast. So I can reach the stated goal for alpha 1 quickly (fixed map with walls, dumb zombies, medkits, food, and club-style weapons) and turn my attention to the stated goal for alpha 2: OpenGL (which is maybe 30% done already).
I'm also interested in a game loop design a blog post turned me onto, involving multithreading the update() and render() pieces with a tri-state, no-lock system that simultaneously solves the framerate-unlocking and variable-delta-t problems. It sounded like fun. For a zombie quad game, it's so very overkill. Such glorious overkill. But I've never threaded anything serious, and I feel like I want to try. I might implement a (different) task-based thread system later as well, so that I can do cooler AI in the background.
I'll push the code sooner or later. But not this second; I'm tired.
|
|
|
Post by ckraniak on Jul 3, 2017 0:11:30 GMT
New code binge.
I have to actually finish the CES before I finish decoupling WinProc from the CESystems. I had to (well not HAD TO had to but still) write a couple of good fileio / directory traversal classes to let me get to the CES part, and those are done and reasonably stable now.
The design for the CES is basically done, though. I now like it a lot more than before.
Once I do the CES it should come down to adding gameplay functionality, mostly, except in some places where I will need to temp-kludge some display stuff until I sit down and do that for real after alpha-1.
Reminder that this has basically turned into a game engine project. I am surprised it seems to be going as well as it is.
I can push the code I have now if there's any interest, but unless someone asks I will probably wait until after I finish the CES.
|
|
|
Post by ckraniak on Jul 5, 2017 3:13:39 GMT
CES is done enough for now.There's ways to make it faster but I won't do that until I need to. Also WndProc is no longer directly tied into anything besides the event system. This is actually kind of a big deal. Executable available here: github.com/CKraniak/OpenRS/blob/master/build/openrs_v0.9.0-prealpha-4-4.zipIt's the same, except now you can go into resources/data/entity_player.orsce and change the player ascii char and have the one you pick come out on the screen. Oh, and you also need the .exe in the same folder as the resources folder and configuration.txt. Besides maybe a sweep for older code and / or comments that need updating, most of what's left to get to the original alpha 1 idea is actually implementing gameplay stuff, so the next stuff should look like it actually changed something.
|
|
|
Post by zaimoni on Jul 5, 2017 21:41:01 GMT
Also WndProc is no longer directly tied into anything besides the event system. This is actually kind of a big deal. Congratulations. I'll have to schedule looking at this as a cross-check on an object-oriented component-entity-system simulator I've been building out, using the Dragonfly tutorial as a guide. (C++14, Boost license, won't bother trying to reverse-engineer into Rogue Survivor Revived; repository also on BitBucket so should be easy to find). It's too object oriented to be a component-entity-system, but has much the same goals.
|
|
|
Post by ckraniak on Jul 6, 2017 5:25:49 GMT
template <class this_type> class adces_on_esc : public GameEventHandler<int> { public: adces_on_esc(this_type that) : GameEventHandler<int>("on_key_esc", []( void * parent, int input, void * that_) -> int { static_assert(std::is_pointer<this_type>::value, "adces_on_esc() called with non-pointer"); INFO_MSGOUT("Exiting now"); reinterpret_cast<this_type>(that_)->test_handler(); return 0; }, that) {} };
IT'S GROSS
If you can read the garbage that is about half of my code you honestly have my respect. The CES is at the "kinda sorta works" state and while it is generally a lot better than this outside of component.h/cpp I would absolutely not recommend it as study material if your goal is to learn.
|
|