• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
yats55

Has there ever been game engines or libraries in assembly?

14 posts in this topic

I know a bit of C++ and know about modern engines and libraries and am interested but don't know much of it.

 

I've noticed that back in the day when assembly was almost the standard for developing games (Nes, Genesis, Snes) that there were barley any shared engines. The only thing I've heard of is that Batman Forever on SNES and Genisis used Mortal Kombat's (Genesis port's) engine, and Super Noah's Ark 3d using Wolf 3d's (Snes port's) engine, but I imagine those games were programmed in C.

 

It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.

Edited by bigbadbear9885
0

Share this post


Link to post
Share on other sites
There's nothing special about assembly that prevents you from making reusable functions, data types, etc. There are assembly developer tools such as MASM and NASM that let you simplify/reuse things more easily.

Transport Tycoon and Roller Coaster Tycoon were both supposedly written primarily in x86 assembly, though I'd wager only reusable functions involved in input and rendering were reused (those games both used pure software rendering).

Also, consider precompiled .lib files (static libraries). Regardless of their original language, they're in machine code now (Machine code is typically just a direct binary encoding of assembly language). The library is still usable by any language that is compatible with the library's ABI. Edited by Nypyren
1

Share this post


Link to post
Share on other sites

A lot of DOS games were also written in a mixture of C and assembly, where C was used for the logic and inline assembly was used for rendering, etc.

 

I wrote my own library in assembly using TASM for doing drawing operation which worked faster than the native graphics library that came with Turbo-C++ and I used that in several small games that I wrote.

0

Share this post


Link to post
Share on other sites

Apparently VD-Dev's Big Bang engine for 3DS is entirely written in assembly. http://nintendoeverything.com/interview-vd-dev-talks-ironfall-streetpass-support-tech-details-and-lots-more/

 

 

The engine used in Iron Fall is called the ‘Big Bang Engine’. Its an engine we have programmed from scratch and is optimized for the Nintendo 3DS. It took us several months to write (days and nights), and is written fully in assembly code, using all the ARM optimizations we know.

 

Although I wonder if the reality is that large chunks of code are hand-written assembly within a more traditional c/c++ framework, but the guy doing interviews isn't techy enough to know the distinction. If it really is 100% hand-written assembly, then it's a pretty impressive feat really, even if it does seem rather an unwise approach. Even if the game is a great success, they might want to port their engine to other platforms one day, and their premature optimisation of non-performance sensitive parts of the engine will make that harder. Can't help but wish them the best of luck though, I admire their chutzpah.

2

Share this post


Link to post
Share on other sites

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.

1

Share this post


Link to post
Share on other sites

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.

 

To be fair, its a very different thing, and a lot more straight forward, to write asm for 8 and 16 bit processors, then it is for a modern processor, but implementing something like a C compiler on 8 and 16bit processors isn't very efficient.

With limited memory and resources the push for high level languages wasn't that big.

Edited by Olof Hedman
1

Share this post


Link to post
Share on other sites

The Lucas Arts Adventures like Monkey island and Day of the tentacle used a virtual machine called scummVM. Actually I don't know if they used assembly for the engine but given the time I'm pretty sure large parts of it were written in ASM.

 

Also, Another world (Out of this world) was written as a virtual machine and could thus be ported to a lot of different platforms.

1

Share this post


Link to post
Share on other sites

For commercial game developers, directly handling in assembly has a few advantages but at the sacrifice of many of the advantages of middle or high level coding. Game engines are supposed to make coding of functions much more extensive and adaptable. The high level coding over a game engine in the middle over the assembly is much more friendly to features, innovation, and art assets.  Art assets in particular typically take a large shop of tools which I doubt will ever be available like that for assembly and far from it likely.

 

You just simply get much more for the dollar or the hour with middle or high level coding compared to assembly.

0

Share this post


Link to post
Share on other sites

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.


At least in the case of the NES and SNES, development in high-level languages is unrealistic, owing to low clock speeds (1.79 MHz and up to 3.58 MHz, respectively), limited register counts (1 general-purpose and 2 index registers), small stack space (256 bytes for the NES, up to 8 KB on the SNES), and in the case of the NES small RAM (only 2 KB) and compiler-unfriendly bankswitching to increase the effective address space.

It's no coincidence that the first console to see significant use of high-level languages was the Sega Genesis, whose 68000 CPU has a much more compiler-friendly architecture. (For example, some Genesis EA sports titles were programmed in Pascal rather than assembly.)

I know a bit of C++ and know about modern engines and libraries and am interested but don't know much of it.
 
I've noticed that back in the day when assembly was almost the standard for developing games (Nes, Genesis, Snes) that there were barley any shared engines. The only thing I've heard of is that Batman Forever on SNES and Genisis used Mortal Kombat's (Genesis port's) engine, and Super Noah's Ark 3d using Wolf 3d's (Snes port's) engine, but I imagine those games were programmed in C.
 
It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.


What you're seeing is largely due to the fact that the idea of a "game engine" is relatively new in terms of game development - in the era when games were predominantly programmed using assembly, people didn't really talk about "engines" per se.

Part of this is that people didn't really talk much about "engines" before the era of 3D games and especially before the 21st century, where the sheer amount of code that can be reused from game to game increases drastically (due to 3D graphics being far more code-intensive than 2D graphics) coincidentally more general-purpose solutions become feasible (due to increased RAM and more powerful processors). Another part of it is that what we now call using an engine was just called code reuse back then, and was as a rule done in-house rather than with engines licensed from 3rd parties.

But make no mistake, large amounts of code were reused. For example, Square released 3 Final Fantasy games on the Famicom in Japan, and all three share significant amounts of code*. Square's SNES RPGs also have a lot of code in common. Super Mario Bros, Metroid, and Kid Icarus share code. Most Capcom-made NES games are built on one of two code bases depending on when they were developed.

As a general rule, any game made in the 8- and 16- bit eras will share a decent amount of code with other games from the same developer on the same platform (Batman Forever on SNES and Genesis and the Genesis port of Mortal Kombat II, which you mentioned, were developed by the same studio, Probe Entertainment), and this trend increases in the early 3D era up to the modern day where many games are built upon large collections of general-purpose code - which we now call "game engines" - that are often licensed from other developers (much like Wisdom Tree licensed the Wolfenstein 3D SNES code from id software to make Super Noah's Ark 3D).

---

* This includes, for the first two, segments of code that serve only as placeholders for English-language ports - one of which never got made. The NES port of Final Fantasy uses different bankswitching hardware than the Famicom original. The Famicom games have code that does nothing in the Famicom version, but can be easily changed into code that controls the bankswitching hardware used in the NES version of Final Fantasy without changing code size or performance.
2

Share this post


Link to post
Share on other sites

 

Part of this is that people didn't really talk much about "engines" before the era of 3D games and especially before the 21st century, where the sheer amount of code that can be reused from game to game increases drastically (due to 3D 

 

I still find a name "engine" as a unpleasant term (personally), the bettter term imo would be a 'subsystem' or something like that

 

I liked the old term library, in the domain of windows programming 

people stopped to call winapi (api) things as a library because it was

part of the system but now i think it eventually can be called library

too 

 

I also somewhat dislike the term SDK, at the beginning of learning this term i also disliked the term 'framework' but now i am not to much angry

on that

0

Share this post


Link to post
Share on other sites

Engine is more descriptive whereas the other terms are too vague.  Like a vehicle, the motive source of the operations for a game is typically in the game engine but the computer brain of the vehicle is the game source code.

1

Share this post


Link to post
Share on other sites
Back when I was writing games in high school using QuickBasic 4.5 all the libraries were written in assembly language. The libraries were mostly for rendering, but often also provided things like better joystick and keyboard handling or high-red, high-color screen modes that QB didn't offer directly. IIRC, some of them offered access to SoundBlaster cards and to extended/expanded memory.

You can probably still find them online if you want to take a look. You could write C-language bindings pretty easily I think, but of coarse you'd have to build your code against DOS. The big one was DirectQB, the other was CosmoX.

There's a part of me that wants to do just that myself some day, as an exercise in nostalgia. Edited by Ravyne
1

Share this post


Link to post
Share on other sites

Engine is more descriptive whereas the other terms are too vague.  Like a vehicle, the motive source of the operations for a game is typically in the game engine but the computer brain of the vehicle is the game source code.

subsystem is more clear and general (you could name everything applicable as a subsystem), engine term is at least for me somewhat opaque

 

what is engine? is this a pack of dll's or something more?

0

Share this post


Link to post
Share on other sites

The game engine is everything that propels the development and operation of a game.  It typically includes render to screen libraries such as graphics APIs, device input library, sound library, miscellaneous dlls, encoders and decoders, runtime clock. scene graph, compilers, JIT compilers, extractors, installers, effects libraries, physics library, and sometimes a whole workflow pipeline for software development is included but often used are interfaces to outside applications and external software for integrated workflow pipeline.  Sometimes only the parts of the game engine needed to execute and play the game are included but sometimes part or all of the development tools are included for developers and modders. Game source code can be distinct from game engine source code, partly integrated, or fully integrated. Packaging only the game coding and game engine libraries needed for game execution and play is the most common distribution to end-users. It is possible to create a game code which interfaces interoperably with two different versions of a game engine. This is sometimes the case when the game code on a new release version of a game is fundamentally the same as the original game code but it is run with a new game engine.  Some players have complained that they got tricked by the publisher advertisement when a game was advertised as being built on a new game engine but the actual game structure and function was basically the same. On the other hand, some "once and done" development has the game coding and much of the game engine so integrated that it is either impossible or impractical to separate them.   

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0