All of those are abstracted out, so if I want to load an asset I go into Tommunism Graphics (the namespace and the name of my engine), and then access Texture and from there Create Texture. If you imagine the engine layer is sitting there as a sandwich between core layer on the bottom and game layer on top, out to the side you have graphics, audio, input, etc. You build upwards from the engine layer to make your game, but it has all the tools for making a level, like placing tiles from assets. It also contains gameplay information, such as levels and the base level of your characters and players. The engine layer handles stuff like asset management, including the SWF 6 reader and Spine 7. On top of the core layer is the engine layer, which sits between the core and the game (which is at the very very top). The engine has a core layer which consists of memory management, threading, anything specific to system startup for consoles, file reading, and all the very low-level base systems that will change per platform. If it weren't for abstraction, porting games wouldn't have been nearly as easy for me. I attribute this quick turnaround time to how the engine is structured. So I ported to Xbox in about two days, and then PlayStation in a day and a half. At first, I thought I should just buy some computers, but then I looked over on my desk and saw my two Xbox dev kits.
Super meat boy flash 1080p#
Right before PAX last year, Forever was only running on Switch but two or three days before the convention, I realized I wanted to be able to show it in 1080p because I only had the handheld Switches to show at our booth. Being able to compartmentalize those systems actually allowed me to have that starting point. I think that was the biggest point of confusion for me. From that point, even when you have a triangle on-screen, where do you go from there? I think learning that I needed to compartmentalize,having: my asset loader, my game, my controller code, my audio code, having all those things.
Super meat boy flash how to#
The biggest point of confusion when I was starting out was actually learning how to properly abstract and compartmentalize and implant, because when you're at the beginning of making an engine, where the hell do you start? That's a huge challenge even getting something simple like a triangle drawing on the screen takes 100 lines of OpenGL 4 code or 200 lines of DirectX 5 code. There's very little concept of platform even in the engine code, which is the piece that actually talks to the platforms. For instance, the way my current engine is structured, there is no concept of Xbox, Switch, or Playstation in the code of Super Meat Boy or Super Meat Boy Forever. These are the places where you have to compartmentalize the different parts of development. It was just a quick and dirty way to make something that worked. This is important because in the first engines I would write, everything was all just one project. By the time I left that first company, I learned the benefits of engine abstraction 2 and trying to keep platform-dependent 3 code separate from game code. It prepared me more for working on the 2x engine 1 and then porting that engine to the Xbox 360 and working on the 360. I got really confused while working on it, but it was really helpful going through the process.
Regarding my first attempt at a game engine, I experimented with making a game engine right before I started working in the games industry. (The following is the edited transcription of a conversation we had with Tommy Refenes.) Compartmentalizing is Key ¶ He also appeared in Indie Game: The Movie.
Tommy Refenes is the programmer for the million-selling and award-winning Super Meat Boy and the lead programmer on the upcoming Super Meat Boy Forever. The Engine Sandwich: Made with Super Meat ¶ Rubberduck Developing: Forced Explanation
0 kommentar(er)
