So it's probably a bad idea for me to make this thread now or at all, but I'm gonna do it anyway. Enjoy!
Ventus is my remake of Blam! to use with Halo files. The word "ventus" is Latin.
License is free.
"Free as in air. Don't use it for evil, and it will go well with you."
Last week, I shared a progress video on the HBO Discord:https://www.youtube.com/watch?v=fvTRQpr-fbQ
Today, I wrote an overview of the development pipeline and re-iterated a bit about the immediate purpose for this project:
Quote: The step I'm on is designing functions for parsing serialized data (Halo-related files) into the structs. Of course I've done these things many times in different ways over the years. Generally, I'm still on the "reading files" stage. I'm taking today off, and tomorrow I do some memory management. Still to do is some more fun reverse-engineering of "binary data" structures. That will likely involve libraries like OGG Vorbis and DXT Bitmaps and Unicode support... but I will do those all later as part of the platform-native GUI stage. To use with the parsing functions, I also design constraints functions and debugging (development phase testing) blocks. Related are data validation functions. Towards the end of this stage, I check all stock files for bytes that are not stored in struct elements, and supply elements for that data. Once that's done, I anticipate still needing to do the "writing files" stage. Towards the end of that I probably will do processing functions, which will include functions that translate the data from the de-serialized struct storage into arrays suitable as buffers for rendering (OpenGL now, later some other platform-native things like Metal and DirectX). That will be a transition into the platform-native development stage, which is where you start seeing usability. During that stage, I do the user interface design, localized text, interactive features, keyboard and mouse controls, and so on. Around that time, I also do the engine behavior, which is like putting all the assets together: sound, 3D environment, physics, and so on, fitting it all together into the processing pipeline. Then I do networking stuff.
I've experimented with all of these things in the past (except physics) and I would like to have a result that lets you play Halo game assets in a superior engine that is compatible with modern hardware and software and allows for more creativity while relieving the players and map makers of burdensome artificial limitations, while still supporting those limitations for full compatibility with the Halo Editing Kit and Blam. So I'm making a new engine for Halo to bring the ideas I had earlier, including multiplayer dynamic map making (editing maps while playing them, like in Cube3D's Sauerbraten), removing the artificial limit of 16 players per game server, and most of all, simply making available a game engine that runs Halo files that people can use to make their own games.
Ah yes, and the networking stage would of course include what has been termed "ai synchronization" among its behavior features.
If that was confusing, then in brief, Ventus is my ultimate opus built upon my old Zeus experiments. Ventus is a new game engine that is compatible with Halo files, but does things better than Blam. Basically, if one were to go back and take all the work that was done on Blam for Halo: Combat Evolved and redo all the HEK programs and put all the stuff into a new game engine with integrated game editor and make new, fun features, that's Ventus. But there is a lot of work to do... which is the whole point!
For anyone interested in C, C++, Java, Android, or Perl programming, I suggest reading these relevant coding standards -- https://wiki.sei.cmu.edu/confluence/
-- and I would like to share these summary guidelines I wrote for my project:
Quote: Summary of Guidelines as rules:
1. Be consistent.
2. Never dump a struct.
3. Serialize to disk and (encrypted pipe) network using only imposed memset and memcpy.
4. Don't use shorthand or be lazy.
5. Use maximum compiler optimizations and warnings.
6. Check optimized assembly before release.
7. Before using userland data values (after parsing), check integers using built-in integral minimums and maximums and check floats for -0 and NaN using math.h and necessary limits and desired bounds using functions for the math; filter before using math.h functions.
8. Keep identifiers short.
9. Be deliberate and specific with data types and operations. Avoid ambiguity by always using parentheses with order of evaluation.
10. Pair every calloc with one free and NULL assignment... Never pass a zero value to calloc. Check calloc's return value to determine that the entire memory block is initialized.
11. Prompt the user for sensitive data and store, use, wipe with overwrite, free, and annul that data properly and immediately within one function and before errors can occur.
12. Always check all function return values or cast the function call to void.
13. Only use pointer math within the same object (initialized memory block) and after casting to the uint8_t* type.
14. / and % must check for divide-by-zero.
15. Compare structs by element value, not by bit pattern; compare floats by value, not bytes.
16. Const is normal.
17. Don't use snprintf with userland data. Store and pass userland data until use with printf or fprintf with variadic arguments. Otherwise, use fputs.
18. Put integer literals into an enum.
19. Place variables and functions into the minimal scope and as opaque types in a header file.
There is still a lot more to do. Here are some screenshots just now:
So that's today's news about Ventus.
For more news, join the Blam comments channel on the Galaxy Verge Discord
. To see only blurbs about development milestones, you can join the HBO Discord
Q: Is it a new game?
Q: Is it illegal?
A: No. Halo files are not released with Ventus. But if you just so happen to possess Halo files for whatever reason, they'll work. But you won't need them.
Q: When will it be ready?
A: I don't know.
Q: How many details are you planning to share about this project?
A: As of today (August 11, 2019), I have no plans to share anything besides the occasional video, screenshot, or copy-paste of a small section of the source code, because development is dynamic so there's little reason to post code besides a preview to show the kind of thing that I've done and to mark development milestones. Besides that, nobody really cares anyway.
Q: Will the game be open source?
A: I have not decided that yet.
Q: Will it balance my checkbook?
A: No. Try calculator.exe on Windows and calculator.app on Mac.
Q: How can I contact you?
A: Best way is to join the Galaxy Verge Discord
server. This forum thread is merely a one-off, but you can reply to this thread also. I've posted enough stuff on this forum already
Q: Why C?
A: C is considered portable. I like C. I don't like C++ or Java or Python, although pretty much every other software developer in this community likes one of those.
Q: Will it run Crysis?
A: Right now, I'm doing the C part. The platform-native part is to be done in Objective-C for Mac and C# for Windows. The rendering would be done in OpenGL at first, then for Metal or whatever is a contemporary Mac thing and DirectX or whatever is a contemporary Windows thing. Linux would keep the OpenGL I guess.
Q: System Requirements?
A: Well, the C part could probably be run on a parking meter (just kidding), but basically it will be made available (at least upon request) such that you should be able to easily port it to Mac, Windows, and Linux. But as for what I'm planning to compile it for, it should run on both 32-bit and 64-bit systems under Mac OS X Snow Leopard, Windows 7, and whatever CentOS 7 is. But again, if kernel matters to you, feel free to compile it on your own -- but you might be required to do some programming.
A: I'm thinking maybe Lua like how SAPP uses LuaJIT, but that's not something I'm integrating at this point.
Q: Easy to use? Fast and smooth running? Fun to play?
A: You'd better believe it! But how fun it is depends upon how many players there are and how creative you want to be.
A: What I have in mind is a centralized but archivable asset library like my former INCY Online projects. If you have network access (you're reading this on a web site, yes?) then you can collaboratively design assets like tags and maps.
Q: If you're adding stuff, how will it work with HEK compatibility?
A: I consider HEK files to be static formats, so it will be made clear what can and can not work with the HEK programs and with Halo. Otherwise, it doesn't really matter since it's a different game engine.
Q: Open Sauce and HAC2 support?
A: Well, those are Halo hacks and this is not Halo. Map files in .yelo format can be supported, but at the end of the development, since that's not a priority and it would probably be trivial to add support (I'm talking a matter of a couple minutes of work and done within a couple hours).
Q: What's the general approach? Why has this taken so long to develop?
A: My work is cumulative. As I gain experience and realize things, and look and find things, I evaluate and use that information. Until now, I went about reverse engineering in different ways, but then I determined to use the kind of data definitions as indicated in the actual HEK programs. It's fun work, so I don't mind that it has taken years of effort, on and off. Ventus will be the result of this work.
Q: What does GXV1 mean?
A: galaxyverge project 1