I’ve made this game in three days on recent Ludum Dare jam event. My experience with Urho is still pretty poor, and I decided, that participating in a jam is a good opportunity to learn. I went with script only, because I’m not familiar with C++. It also was my first game jam. I worked in CodeLite with AngelScript autocompletion set up with help of this thread: groups.google.com/forum/#!topic … WOOGAdwlEU
I really enjoyed working on Urho. It performs like a beast. And I figured out a lot of new things in that three days despite the lack of documentation and tutorials for noobs like me. Anyway, here are several things, that I want to clarify:
Later in development the Urho3d player started to crash pretty often. There is no particular action, causing it. It should be something in my code, but is there a way to debug a Urho3d player crush (other than building and running it in debug mode)? Is it dumping crash logs somewhere?
Is there a way to restart the whole game? I ended up with scene_.RemoveAllChildren(); and then creating everything up again. Is it okay? Or maybe there is something else I have to remove manually?
Updates. Is there a place where I can find the list of all available update functions, and order in which everything gets updated?
At first, I was happy to find out, that I can read input from any place, like Update() or FixedUpdate() of script objects, but actually, that’s doesn’t work sometimes, and sometimes depends on FPS. Examples are not constant in the ways, thay handling input, so what is the basic do/ do not?
Nice entry for being done in 3 days! In particular, I like the weapon design, the chaining, and the zombies.
One thing I would suggest for future events is to modify the Urho3D player yourself. There is no reason (Though Game Jams sometimes require you to forsake all reason) to require someone to run GAME.bat. Instead, you can change Urho3D player to match the defaults you expect, and let other players modify those defaults with the command-line switches made available if they want to do their own thing.
You can specify the log level of the Urho3D Player with the -log switch:
I believe with the Urho3D player, you’re doing a good job of “restarting” the game. The alternative would be to recreate the scene entirely. With a C++ game, there would be more available to you, but your solution works fine.
You can view the main loop at Engine initialization and main loop. Additionally, there are C++ headers for events, such as PhysicsEvents.h, that will give you a more verbose list of what events you can hook. I’m not familiar enough with AngelScript to offer exactly how to translate these, but it will all work.
Input is handled during then E_BEGINFRAME update. You can check for Input anytime after this event, and expect it to be consistent across the frame. Therefore there is no real “standard” to check it. You could listen for input events, or check the Input subsystem yourself. It’s really up to what works best for you.
You can look through the Urho3D documentation here. There’s a drop-down box at the top-right corner if you’re using an older build (Such as 1.32).
[quote=“thebluefish”]One thing I would suggest for future events is to modify the Urho3D player yourself. There is no reason (Though Game Jams sometimes require you to forsake all reason) to require someone to run GAME.bat. Instead, you can change Urho3D player to match the defaults you expect, and let other players modify those defaults with the command-line switches made available if they want to do their own thing.
Yeah, that’s a shame, indeed. As I said, I’m not very familiar with c++ yet. My only experience is - building Urho. I knew, it’s should be easy, but I was afraid to get stuck on this task and lose too much time.
I also thought, would be cool, if Urho3Dplayer would be trying to start some default filename like autoexec.as (.lua), or checking for file to start in some simple text file. Ability to make games without diving into c++ is a nice feature to have.
I’ve enabled log file writing. But there is nothing engine writes right before the crash.
That’s seems to be exact thing I (over)looked for.
Log file could be in a different location, but I can’t seem to locate where the default is. If it crashes before creating the log, then it’s having a problem early on. I believe initializing the Engine subsystem is what creates the log file.
As I mentioned earlier, I’ve already built Urho from sources, it was stable version however. The process, indeed, is reasonably easy. I also built your TIFF packer, though I was close to asking you for binary.