I’ve been rather busy lately working on Wii U development using Unity and all things Reloaded have suffered. I haven’t touched Omega Core in a couple of weeks and don’t know when I’ll get to it again. I would like to wrap up 1.07a this weekend, but I don’t know how things are going to go. I’m knee deep in documentation for Wii U development and getting my dev kit ordered. Once I get that all going, I’ll be starting a blog for my Wii U game development.
The bottom line is that once I get 1.07a out the door, I don’t know if I’ll do any more on Omega Core. I may or I may not. It all depends on progress with Reloaded and whether or not I feel excited about doing any game development on the platform when new features get added.
I’ve been working on the 1.07a release of Omega Core and thought it would be a good time to give a progress update. Last evening I got a little side-tracked with trying to hijack direct input so I could have control over when the engine accepts input. The experiment was a failure and I’ve had to shelve the idea. I was also distracted with testing out the new TransportToIfUsed function provided in 1.0085.
However, I did also manage to get automated input mostly working. The new functions for automated input so far are:
Automated input allows you to simulate keystrokes and mouse movement through scripting. So, without even touching a key or the mouse you can have the player move and look around the game level. This is also useful for mapping new keys to already defined keys. For example, you could check for a “u” key press and tell the engine to hold the “w” key down to move forward. Finally, the MouseMove function allows you to simulate a camera shake effect. By rapidly moving the mouse back and forth and up and down in a random fashion, you make it appear that the scene is shaking. Very useful for big explosions, a rock slide, earthquake, etc.
I’ve also changed the ocVideoPlay function to accept a second parameter. The second parameter, if left blank, will simply cause the function to behave as it already does by playing the video using Windows Media Player. However, if you specify “ff” for the second parameter, the plugin will try to play the video using the mplayer application built on FFmpeg. You are responsible for providing the mplayer.exe application in the Files folder of your game. This added capability means that you don’t have to time the video playback yourself because mplayer will automatically end when the video is done playing. The mplayer application is also much faster when loading and playing videos fullscreen. This makes in-game cut scenes and intro videos much more viable.
As soon as I do some more testing and cleanup with the automated input and video playback, I will release 1.07a. Then it’s on to 1.08a where I plan to bring the first GUI commands for public access.
I may just have stumbled across the solution to a problem that I’ve wanted to solve in Omega Core since the beginning. Some early test code indicates that what I thought was previously impossible may now be possible. Mainly, the ability to intercept DirectInput in Reloaded and modify, block, or re-map input events on a very selective basis. If the test code can be extended to work with the “key” DirectInput function, it would be possible for me to create a full GUI interface with an independent mouse cursor.
That would make it possible to have an inventory window pop up that is clickable, or clicking on a quick slot bar, dragging GUI windows, etc. Re-mapping keys is another possibility so that you could, for example, change the F key for flashlight to the T key for torch if you wanted to. And I could prevent normal player input from occurring at all, but substitute alternate input. While Omega Core can block input across the board right now, this also prevents even Omega Core itself from processing any input. This new technique would open up input from Omega Core while preventing normal input.
This type of input manipulation is also crucial for an eventual 3rd person controller. But until TGC fixes the issue with Physics On/Gravity Off, we’ll still be unable to make a 3rd person controller.
I’m going to work on this new technique some time tonight and hopefully will have good news to report soon. This would definitely be a feature going into 1.07 if it works.
I’m currently working on some advanced A.I. scripts for FPSC-R. Initially, these scripts will not require Omega Core at all. I may, at some point, need to incorporate some Omega Core features in order to achieve a certain end goal, but not initially.
I’m developing a new demo game called Omega Strike that is going to involve complete custom A.I. using the stock Reloaded characters. As soon as I have some progress to show on this, I will be posting both here and in the WIP forum.
With the announcement that multiplayer is in the works for FPSC-R for the steam release, I’m holding off on any plans to continue my multiplayer code for Omega Core. At best, I would have multiplayer that would be tricky to implement and might not give us everything that we’d need. At least not with the currently accessible features of Reloaded. So, this one will be on hold until we see what TGC comes up with. Therefore, I’ll be concentrating efforts on the GUI, additional 3D sound support, and Artificial Intelligence.
I haven’t tried this myself yet, but I wanted to make it known that it is now possible to implement a primitive way to vary the player footstep sounds in FPSC-R using a combination of Omega Core expanded keyboard input and the 3D sound system. If anyone wants to give this a try before me, here is what you would need to do.
First step is to replace the default grass walk sound with a file of the same name that just contains about 1 second of silence. I’m not sure exactly which file this is so you’ll have to find that out for yourself at least for now.
Second, load up the footsteps sounds that you want to use for you game using the ocAULoadSound function. You should do this preferably in a global player.lua script that you attach to some object in the game world and turn Always On to true. So, you might, for instance, load up a grass walk and a stone walk sound. You’ll also want to use the new ocAUSetSound2D function so that you don’t have to update the sound position to player position every time he moves. Although, you might want to do it that for your own reasons.
Third, in your player.lua script you’ll want to check for movement keys like wasd and arrows. While in motion you can then tell Omega Core to play the appropriate walking sound in a loop and to stop playing when no longer moving.
So, how do you determine then which sounds to play? That’s why this is a fairly primitive implementation. Unless you do some complex location checks or lay down some really complex zones, you should only use this for entire areas. Perhaps you always play the grass walk sound outdoors, but when your player crosses a trigger zone into a stone building then you switch to always playing the stone walk sound.
While this is somewhat primitive and doesn’t handle complex cases, it should work very effectively in the simple cases. When I get some time I’m going to implement something like this in Rescue the Princess. Good luck to anyone who gives this a try. And don’t hesitate to ask me questions if you’re trying to do this and get stuck.
I’ve had nothing but trouble trying to get the MyGUI code built for my use. I’ve decided, at least for the moment, to continue with my own code implementation and simply clean up the loose ends and incorporate a new font system.
My first question to myself was whether or not I wanted to implement a bunch of function calls for creating the graphic elements or to provide an IDE for editing the GUI or both. In the end, I think I want both, but my first pass at this is going to be to provide an IDE for creating the GUI, which can then be manipulated by Omega Core with Lua scripting commands. Personally, I’d much rather drag and drop my graphics onto a design canvas, adjust layers, scale elements, and see what the GUI is going to look like without writing a single line of code.
So, I’ll be writing a simple IDE that allows everyone to create multi-layer GUI systems that can be easily manipulated in Lua. I want the ability to turn layers on/off with a single command, to control individual elements with Lua commands, and to have the resulting GUI scalable automatically based on the target primary display resolution. For easy control, you will be able to name your controls in the IDE and then reference those controls by name in Lua script. Layers will have an index value and can be controlled by referencing their index value.
Initial controls are going to be frame, text, list box, and progress bar. Frames will be simple containers for all GUI elements, including bitmap images. There will be texture and texture movie classes as well as font classes also.
I’m taking the evening to play some new D&D 5th edition so I won’t be working on this tonight, but might be getting to it tomorrow evening.