Time to Move on?

I've already decided that if I DO treat the updates as a new version (and I probably will) that will be named Cronocrash.

I had long thought of that name anyway - after all it's the one I made up for our site, but figured using it for an engine name too might be a little arrogant. But after some people suggested it in earlier posts, I believe that's best way to go.

At the very minimum I will be starting a new code repository. SX made me the lead dev, but he forgot to send me admin credentials for the Sourceforge OpenBOR repository. I can't even update the front page!

For the moment though, I just had yet another setback... see here.

DC
 
I guess the name doesn't really matter, but it's kind of an odd name.  It could always be simple like BeatEngine or whatever...  Something that is slightly more obvious.
 
Sorry if I haven't shut myself for a while, but DC if you ever got ahead and have a new repository to the new engine, what will you use SF or GitHub? BTW, if you ever make the toolkit again, you can consider updating the tools, especially the Windows toolkit (MinGW). If you also ever make the thing updated for SDL2.0.3, I'll try to modify utunnels' code to update it for the new build, but that is if you're finished by it.

Damon Caskey said:
For the moment though, I just had yet another setback...
For the crash, I can relate to you about that. Hope that you get to fixed stuff there!
 
Damon Caskey said:
I've already decided that if I DO treat the updates as a new version (and I probably will) that will be named Cronocrash.

I had long thought of that name anyway - after all it's the one I made up for our site, but figured using it for an engine name too might be a little arrogant. But after some people suggested it in earlier posts, I believe that's best way to go.

Well, it's a bit of a stretch but we can rationalize it: with all recycled sprites from older games, and a love of beatemups, a genre that's sadly fading in modern games, it's like we are breaking away from that direction. You know, crashing the chronological expectations of the videogame industries...

... yeah, that's bad. I need sleep. :P
 
I believe OpenBOR can remain its name for different types of genres, since it's improving a lot and will be, rather than just Beat 'Em Ups. I think the public or the media thinks the name is generally and only for Beat Em Ups making. We know OpenBOR is used as a base for Beat Em Ups and it's possible to create genres as discussed here. In the future, it's always possible to create multiple genres like racing, a proper VS fighting, and some that will be made that haven't come up before. We've got platformers, RPG-style-based, and Shmups IIRC.

ELECTRO said:
As someone who just hangs out here and plays mods, but doesn't build them, I would still like to say what I feel. I don't see any problems or confusion if the name where something different but similar Like OpenBor_Advanced etc...

I thought about the name AdvancedBOR lately maybe a few days I think. Advanced Beats of Rage was the name I thought about since some of the many genres are made and will be for OpenBOR.

I thought and felt about keeping the name OpenBOR already.

SaintJudas said:
^ stuff like that makes me wish there was a "LIKE" button. LOL!

+1 LOL In this forum. LOL I'd agree.
 
Guys don't think so much about the name right now, let's use "Cronocrash" for now, he can still decide to change the name on a later point if it is necessary, right now the new engine and the planned changes are important.

DC can you tell us what you want to do on the Engine that can't be done with the current version of Openbor?

Problems that can't be fixed in the Old version or features that you want to add to the new engine etc. ?

Maybe you can create a little list of your plan for the new engine, like stuff that is important and stuff that will maybe added at a later point?
 
SaintJudas said:
^ stuff like that makes me wish there was a "LIKE" button. LOL!
On enworld.org we now have both a LIKE ("give XP", actually) and a LOL ("laugh at") buttons. Pretty handy! :P
 
Sorry DC.  You now have Admin privileges on the SourceForge Openbor Project.

As for your thoughts on moving forward with the engine's core.  I whole heartedly agree that anything new should be done using well known design patterns (Request Factories (Entity Generation), Abstract Interfaces (Low Level Video, Audio), Singletons (Managers), etc...) and utilizing a language such as C++ or another one that supports Object-Oriented Programming.

Personally my favorite language is C++ and being able to use STL containers allow me to focus on the task at hand versus re-inventing another linked list and I love the new enhancements that were introduced with version 11.  Furthermore, Boost is always a great addition to C++.

Its funny towards my end at OpenBOR I had started writing a new Engine that was completely OO based.

Good Luck!!!
 
I was coming here to make a comment, but before that, SX, It's been too long man, what's up with ya!

Ok, so, this is just me making some suggestions here, in case these incite any ideas or just good features to implement in the engine without having to use script, or just easy script commands, so take them as you will or ignore them.

1.Implementing an options menu directly in the pause menu so players wont need to use the screenshot button. It could even be useful for screenshots if they pause text could vanish somewhere as the button is pressed

2. Implementing a music menu somewhere in options, something close to how it's been on the OpenBOR menu already.

3. Was just playing Super Battletoads(arcade game) and had an idea here, maybe you could add a different BBox when the enemy is laying on the ground, and, if this can be done, make the player do a different attack(mainly ground pounding) if they're within range of this box. Kinda like how we use range to make non player entities do an attack when their in that set range, only pressing attack makes the player do a different move within it.(hope that came out right)

4. Another idea from Battletoads, when an enemy entity has had it's health taken down to a certain point, you can have a range set to activate when the health reaches a certain number, and when they do, like above, the attack entity can execute some sort of finish blow. This would even make it Killer Instinct 2 style, where you're able to pull off a finish move just by getting the enemy in danger and pushing the buttons you have to. There's also the Mortal Kombat route, and making them go into a dizzy state when their life is depleted.
If for example, multiple range commands like this are implemented, maybe you could give the commands a name for this? Rangebox/Rangeattack maybe, then using the standard numbers for setting those boxes up.

5. If one wanted to make a 1-on-1/Mugen like mod, you could add a new number to BBox. The first 4 numbers would be standard for setting the box, but the new fifth number could control whether or now the bob is solid, 0 by defualt meaning off, and 1 for on. When so, the entity, like in most fighters, can't be walked pass, but will slide over. Of course, there could be a header commands to make the entity solid, but this would work great for only allowing this in certain animations, like for example, Spider-Man's or Wolverine's special moves that make them dash towards opponents, and push them with them even if they knocked them down, as you know won't happen in OpenBOR, meaning they would just phase right past if moving.
On another note, this comment could have a sixth number, which would set the power/wight of the entity, this way, you can set a realistic difference in entities walking into each other, and the entity with the bigger number, pushing the other at a different rate. An 8 moving a 1 would mean them just getting shoved over, but an 8 moving a 7 would mean it moving back at a much slower rate then a 1. Could be useful for making some sort of solid wall like entity that's not meant to be moved and shove the player over.

6. An idea i had in my head for a while and meant to share for some time now(and could probably be done even now), but how about making in game cutscenes where every action of entities is controlled some invisible entity just going through a idle animation? As it goes down the list, it can command entities to walk, stop walking, jump, attack, display, change, or kill a block of text maybe? Like watching an scene in a 2D RPG, or even better, similar scenes from KOF whenever Kyo and Iori meet up, or even Sol and Ky in Guilty Gear, and they talk and/or fight each other before the gameplay actually starts. It would be a lot easier to create interactive cut scenes in mods, like that of Hatchet Ninjaz:
Hatchet Ninjaz Sega Dreamcast (part 2 of 2)

7. I know we have this command somehow but maybe an easier way to make entities switch in a certain move? Like playing as Goku or Sonic for example, and making either one go into a super mode/state when attack and jump are pressed at the same time for example, and of course, having them turn back once a set timer is up. I would also suggest this being a new entity type, maybe just call it super, but give it the same properties as weapon, but with said time limit.

8. I had a whole topic about this I think, but there was the money command I went through the trouble of copying from Matman's Mixmaster mod. This would be a lot easier if we could implement actual money in OpenBOR just as points are, and they would be accumulated through grabbing items with a money/currency entity header rather then score.

That's it. Again, these are just suggestions and ideas I had if they can be implemented in the new engine, which I don't even expect to be considered right off the bat, but maybe in the future. On another note, if this new engine is already in the works, and if there's any chance of it coming out soonish(Like 2 or 3 months), I have another new project that could act as a guinea pig for testing this engine with. I have no big plans for it at the moment and I'm not using too many animations, it's just something I want to make, so it'll most likely be another brawler. Get back to me if you can DC.

X)
 
DJGameFreakTheIguana said:

man, for about almost everything you suggested, its already doable by script so there is no need to be hard coded into the engine. Its a waste of resource.

But about this:
5. If one wanted to make a 1-on-1/Mugen like mod, you could add a new number to BBox. The first 4 numbers would be standard for setting the box, but the new fifth number could control whether or now the bob is solid, 0 by defualt meaning off, and 1 for on. When so, the entity, like in most fighters, can't be walked pass, but will slide over. Of course, there could be a header commands to make the entity solid, but this would work great for only allowing this in certain animations, like for example, Spider-Man's or Wolverine's special moves that make them dash towards opponents, and push them with them even if they knocked them down, as you know won't happen in OpenBOR, meaning they would just phase right past if moving.
On another note, this comment could have a sixth number, which would set the power/wight of the entity, this way, you can set a realistic difference in entities walking into each other, and the entity with the bigger number, pushing the other at a different rate.

You aren't aware of how big the nightmare is stading before you. This is one of things I most hate in mugen, and the 6th number idea is terrible, giving a lot of headaches. In Mugen, its very hard to make something NOT push you, like making obstacles. Its a pain to code and gives bugs in many aspects.

For sure a solid bbox would be useful, but not the push thing. The way the obstacles works now are perfect.
 
That can only happen if we have source code of these tools since they are not as developed than OpenBOR itself.

I did saw some sources from OBEditor that was grabbed by rofl0r via Github here, I don't know if this is 1.5.9, but in its changelog it says 1.5. The app is done in C++ with wxwidgets and can be compiled using gcc (open source and free). The advantage is that this can be ported for other systems other than Windows. Disadvantage is the size, since wxwidgets is known to be a disk space hog.

Unfortunately, building it is a pain since it requires scons than just doing a makefile for make instead (a pain becuase it needs Python aside from cygwin/mingw).

OpenBOR Stats on teh other hand is more illfated though since the sources are outdated (found a more or less updated openbor stats here grabbed from 0.5.1), plus it's done in Delphi7+JEDI component pack (so it's windows only).

I'm saying this to say that they can be updated by someone who is willing to continue to do so

@ Illusionista, you just got the words out of my keyboard.
 
That can only happen if we have source code of these tools since they are not as developed than OpenBOR itself.

I did saw some sources from OBEditor that was grabbed by rofl0r via Github here, I don't know if this is 1.5.9, but in its changelog it says 1.5. The app is done in C++ with wxwidgets and can be compiled using gcc (open source and free). The advantage is that this can be ported for other systems other than Windows. Disadvantage is the size, since wxwidgets is known to be a disk space hog.

Yeah, there is a 1.5.9 version. So its possible to updated that tool? Its pretty amazing.
I was trying to convince VirtuallTek, the guy behind the Fighter Factory, to make a OpenBORFactory. But is very busy right now.
Its sad, because he really knows how to make good programs (and have great beta testers ;) )
 
O Ilusionista said:
man, for about almost everything you suggested, its already doable by script so there is no need to be hard coded into the engine. Its a waste of resource.
I figured hat as much, as I actually stated somewhere in my wall of text, but like, will those same scripts even work the same way once this new engine drops?

O Ilusionista said:
But about this:
5. If one wanted to make a 1-on-1/Mugen like mod, you could add a new number to BBox. The first 4 numbers would be standard for setting the box, but the new fifth number could control whether or now the bob is solid, 0 by defualt meaning off, and 1 for on. When so, the entity, like in most fighters, can't be walked pass, but will slide over. Of course, there could be a header commands to make the entity solid, but this would work great for only allowing this in certain animations, like for example, Spider-Man's or Wolverine's special moves that make them dash towards opponents, and push them with them even if they knocked them down, as you know won't happen in OpenBOR, meaning they would just phase right past if moving.
On another note, this comment could have a sixth number, which would set the power/wight of the entity, this way, you can set a realistic difference in entities walking into each other, and the entity with the bigger number, pushing the other at a different rate.

You aren't aware of how big the nightmare is stading before you. This is one of things I most hate in mugen, and the 6th number idea is terrible, giving a lot of headaches. In Mugen, its very hard to make something NOT push you, like making obstacles. Its a pain to code and gives bugs in many aspects.

For sure a solid bbox would be useful, but not the push thing. The way the obstacles works now are perfect.

But wont I don't get is, how is the 6th number a terrible idea when the idea was meant to work for certain animations only, meaning the push will only work when specified, thereby having control of it, at, unless even trying that is more complcated. If that could be a problem though, maybe add 2 as another variable to make said obstacle unmovable.

And again to, I'm not that knowledgeable in coding, just ideas, and as I also stated, could just be ideas in the future, and while doable now, maybe more accessible in the future if given the time, which would, I think, cut down on help topics for the very same subjects over again(I mean with other script based problems other then mine), especially when there's no guarantee that said questions would even be answered(Which someone could create a forum page for those that have been answered for references).
I get that this could be a waste of resources and all, and it's not like I expect all this to go down, but maybe some of this could make the engine more accessible in the future, and maybe even cut down, by some  amount, on help topic having to do with script and such, and hell, I got a lot of scripts, not even sure if I'm using them all, but I can share what I got and you guys can back burn the idea of hard coding them. I know for one example DC was talking about trying to giving full control of jump controls for a Shinobi mod. Even something as simple as that can be made easier in this new engine if given the time(and a script is made for it in the current engine). Hell, maybe even archiving script commands that have been made in the past, somewhere down the line.
On another note, I'd like to know how much of a waste all this could be. I don't expect a simple copy and paste coding of scripts and then making entity headers, but then would this end up being a long and complicated process?

P.S. Forgot all about vaulting.  :P
 
Back
Top Bottom