search

TRex22 / RapidGame

A framework that aims to make games easier, fun and from the code (old school). The Framework will hopefully support SDL, XNA and MonoGame projects for Windows, Linux and others. Porting from different systems should only require minor changes.
http://trex22.github.io/RapidGame
MIT License
2 stars 0 forks source link

Project Structure #64

Open edg3 opened 10 years ago

edg3 commented 10 years ago

What are your thoughts on moving to a different project structure where we build scaffolding per-platform for SDL/MonoGame/XNA etc - we can set up different solutions for different platforms.

An example for windows:

Solution:

The core would be all the functionality RapidGame gives, and it would leverage the XNAWindowsScaffold to get the correct calls to draw, create the game window, etc.

The TestGame would register the scaffold with the Core and do whatever else it needs.

This is more modular, and means you could set up more projects in parallel in the repo without needing it all in a single solution? This would also allow for more reach platform wise without needing to fiddle with solution and project files continuously.

This is something I have been thinking of for a while, and as part of it I would have to consider changing up the services system - I have some ideas in mind to make it work.

TRex22 commented 10 years ago

I was thinking something similar. I have a design for an abstraction layer in mind. I still have two exams so I can't really work on it at the moment, and after those two exams I have to catch up some work and then I have an internship. Ill have some time though after Wednesday to outline what I'm thinking and Ill send it to you. Mine has a bit more layers. I did find a SDL wrapper for SDL. Unfortunately Mono for Android costs $299 from Xamarin, so I wanted to create a c++ version of RapidGame which runs on Android.

TRex22 commented 10 years ago

The first thing I am doing is building a full game in XNA and MonoGame which I will then change into RapidGame as to have some kind of testing environment. Unit tests are hard with this kind of thing. I did find a major problem with RapidXNA which is why I closed off that code. There appears to be a Circular reference due to the XNA platform seeing Game1 as the 'head' of a singleton. When you close RapidEngine, Game1 still persists. My idea would be to make all the references to MonoGame, XNA or SDL or whatever renderer/framework we want to use in RapidGame and so the game you are making will only look at RapidGame libraries which then directs to the specific technology. That way changing technology or even platforms would be really easy and cool with RapidGame, and there would be no circular references.

TRex22 commented 10 years ago

I have quite a few ideas for the direction RapidGame should go.

I would like the framework to be well designed from the offset and quite flexible. The diagram attached I did during a coms lecture. (It was an intro to Java OOP, I have been to way too many of those) Its not necessarily a 100% correct diagram.

The problem with RapidXNA are too severe to sort of get around and then do some horrible voodoo to fix. rather we have an opportunity to redesign and make something really cool.

We need to setup a standard and some design documents. I use Resharper which standardises my code to either default (What I use) or a defined way. I am a little OCD and when my Visual Studios picks up spelling mistakes in comments or code renames or even just arbitrary code like using String instead of var, I tend to change it. I don't mean anything by it but when I see the highlighting it does get to me. We need a standard way of creating APIs ect...

I really liked what you did with services. At Entelect I helped to standardise an API subsystem, where I helped to create a generic class which I called a builder. Im sure there is some proper name for it and it has been used before. It works on the same principle as factories in MVC type applications but for classes and types of code rather than models. I would like to change it a bit so that we have a main builder which defines how the other builders need to operate. This would be in the core dll.

Every tentacle of the framework and the extended dlls of the framework would use generics for the different defined parts, such as services or extended built in game features.

Also different parts of the framework would probably have to be split up to allow for maximum support for different technologies. There will also be the need for wrappers (and a WrapperBuilder) to connect to different frameworks. The engine should be the head of everything, ie calling all the needed functions, frameworks and environs. The game and game maker will only have to worry about game specific code and resources which are then piped into the engine in a readable way.

The diagram attached allows for the programmer to add or remove any modular component (even external ie SDL 2) from his specific project allowing for great flexibility.

It would also be useful if there were 'pipes' or 'tunnels' which allowed direct access to the lower and lowest levels of abstraction if needed.

One thing we definitely need is to use an auto-builder and CI (continuous integration tester).

Also the license. The MIT license might not be the way to go. Maybe zlib? like SDL 2. Even that could be problematic. Not really sure.

We should probably make a GitHub group called RapidGame if we step up the development.

Here a cool Steam Developer talk I found. The youtube talk is very informative about SDL 2. https://www.youtube.com/watch?v=MeMPCSqQ-34

I forgot documentation. Its pretty important to make a good framework. Auto Generated as well as some written stuff and perhaps tutorials.