devconsole (during development)

haxpor

New member
3qY1A6U.gif
(gif image, wait for loading to see it in action)​

Hi, I just want to let community knows about additional feature I'm currently on to.
The goal is for faster iteration time in making a module, and better debugging right inside the game.

Right now, I've hard-coded key combination to be ctrl+alt+c to show/hide a console.
This feature is enabled only when you configure a directive inside dev.txt to enable it; in which I've planned to add ability to turn on/off features which are directly related to devs in there i.e. turn off showing engine's credits screen which popped up randomly etc. Just about now, focus is on devconsole.

Few ideas I can think of for benefit of devconsole
[list type=decimal]
[*]directly jump into specific level to play-test
[*]spawn specific enemy character/object/item etc
[*]reloading model.txt on-demand without a need to close the game, quicker to see things in action, reduce time
[*]what can be done with directive/commands  inside those .txt files should technically be possible right inside devconsole
[/list]

A concern and approach to tackle this
  • Performance & Security : I'm still thinking about this, no conclusion yet. What I thought is devconsole (and possibly entire dev.txt) should be enabled on-demand by devs that need it. This might possibly mean it'd be possible only when devs build openbor by themselves providing a certain compilation flag etc at build time. If build time has no such flag, even dev.txt is there, dev features won't be there, users cannot pop a console up in game as well as those related code won't actually be present when compile and won't get in the way of other part of execution; especially checking for key and input part. Something along that line. A use of compilation flag is to prevent devs from unintentionally release a module but with devconsole enabled, make it explicit when devs need it. What do you think? I'll think about this more.

In case anyone want to check out such feature (warning: hot code, not yet fully stable), clone dev_features branch from my forked repo https://github.com/abzico/openbor. Build it (for now) either with or without BUILD_DEBUG=1 then define the following lines inside dev.txt (putting at the same level of video.txt and others).

Code:
# console [bi]
# 1 - to enable in-game console support
# 0 - to disable in-game console support (default)
console 1

You have 2 commands
[list type=decimal]
[*]version - to get current openbor engine's version string
[*]level <filename to level file (.txt)> - to load and directly jump to play such level (warning: not work fully & cleanly yet as refactoring current openbor's code base need to be done in order to achieve this, you can still see problem like z limitation mis-match for such level, etc. Anway, this is a prove-of-concept.
[/list]

Feel free to let me know your thought here, anything you want to see and use in devconsole, suggestion, or anything. I will come back to continue working on this after a week.

Thanks

PS. Thanks to Kratus for amazing Streets of Rage 2 v.1.4 module which I used above for recording as gif, and a foundation for learning about OpenBOR as well. Your module works well even with latest OpenBOR's code base with changes added up until now.
 
I really liked this idea, and I can see some good usage of it. My only concern is if this would allow people to use it to bypass the engine credit screen - which I think it would be a big no-no in my opinion, but I would like to hear from Plombo and Damon Caskey

Since it's more a dev talk, this could be done at GitHub, so the outer devs can talk about it on a less distracted place.
 
Thanks for chiming in! Regarding to engine's credit screen, I'd prefer to have flexibility or less intrusive than currently is (it pops up randomly and it need key input to progress further), but anyhow engine might provide options to show credits at startup as splash screen or randomly as it is now or both, or none (just idea).
 
Hum, I am strongly against the idea of not showing the engine credits, to be honest. I don't think it's fair with all the developers over the years.

But I like the console idea
 
Thanks for feedback! Just to be clear I'm not here trying to remove credits or anything, just thought about providing more flexibility in the engine. I also really appreciated effort pushed into openbor, great engine.

That's alright either way or another in such regards. I will see what other people think about this.
 
I can tell you right away, most people will love this. Anything that looks like an easy button is sure to get cheers.

I'm not so sure though. It's funny how coding backgrounds tend to influence folks approach to solving problems. C guys = "Moar pointers!", PHP people = "Moar libraries!", and Linux dudes like you = "Console windows!".  ;)

Seriously, the credits thing we can talk about, but what I don't like is having a bunch of dev flags or yet another control system bolted onto the engine. I've spent years trying to clean it up and am not finished yet.

I'm not saying a flat no, but I am very cautious about this. IMO the effort would be much better spent on a separate development kit, or even a script library that does this - the functionality is already there.

DC
 
Damon Caskey said:

You said it right about how devs solve the problem, haha. Funny though.

Yeah, with that said, I don't plan to re-invent the wheel, the systems inside openbor can well serve such purpose. Anyway, I re-evaluate the effort, and whether this devconsole will really help reduce the time at the end. I noted about dev.txt as well.

Thanks for feedback DC!
 
love it! Also something to kill current enemies onscreen so we could easier go through the stage without having to fight with them, i partially doint that with attack with 9999 damage, maybe someone has better idea.
Anything that would make development faster is a good idea.
Ability to reload all entities when we are in the level and update their animations/frames etc would be good as well. So we dont have to restart the game all the time to load new stuff.
 
bWWd said:
Is it in current build so i can compile it ?

It's not merged yet. It's highly likely that I will revisit this again in the future. For now, it requires modifying too much of code-base, and risk producing more bugs and unstability.

Thank you for feedback, I noted your suggested use case. It will be handy when I revisit the implementation again.
Thanks to OIllusionista as well. The inspiration comes from id tech engine (which is used to make Doom 3) as you can reload a model after you adjust / modify the model externally via 3d modeling tool i.e. blender, etc.
 
Just having a look back at some thread archives, and thought I'd give a shout out to @haxpor. I took you off the dev staff due to more than a year with no activity, but if you're still out there somewhere and ever want to come back, we've got a seat at the table for you.

DC
 
Just having a look back at some thread archives, and thought I'd give a shout out to @haxpor. I took you off the dev staff due to more than a year with no activity, but if you're still out there somewhere and ever want to come back, we've got a seat at the table for you.

DC
I didn't see it before. Would be a great addition to the engine.
 
Back
Top Bottom