GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Space Game Page Previous  1, 2, 3, 4, 5  Next
View previous topic :: View next topic  
Author Message
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Sat May 31, 2008 7:24 am    Post subject: Reply with quote

Nice! What IDE are you using?
View user's profile Send private message
Bean
Admin

Joined: 20 Aug 2005
Posts: 3776

PostPosted: Sat May 31, 2008 8:08 am    Post subject: Reply with quote

Quote:
Finalize your feature list and pick a subset for initial development
Crank out a barebones prototype with the most basic and essential of features (flying in space, landing, walking around) and call it done
Once everything is done and working and playable, branch the codebase and add the next feature on the list


Sage advice xearthianx.
I've always been aware of my having the same problem. But never have I seen such a simple and effective solution as that right there.


n29, that would be Visual Studio.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Sep 14, 2008 5:56 am    Post subject: Reply with quote

Yes, it's Visual Studio 2005 Pro. My school is a subscriber of the MSDNAA, which allows them to hand out copies of various Microsoft products to their teachers and students for free, as long as the software is used for educational purposes and not for commercial things. Writing games is highly educational, imo, even though I'm not doing this for a school project. ;P ;-)

Alright, after a long break in which I got absolutely nothing done(except some pixel art not related to this project), I returned to the IDE yesterday to write more code and now I have got a new class in my Framework, which I called 'BinaryFile'. Tada!

the boring details about that new class:
It automagically handles endian conversions involved in writing and reading the builtin value types(bool,char,int,long,float,double) to and from files. It also saves typesize information to the files.
Floating point values are converted to integer representations before they are written to the files, because I could not find any document that assured that the memory representation of these values would use a certain standard, so the endianness conversion of those values would probably have been quite the mess and I felt that using integers would be the safest way to store them. (I convert them so that each side of the . becomes a single integer number and then I save these.)

It disallows appending data to a file, if the typesizes on the machine that wrote the file are different than the typesizes on the machine that tries to append data. It does allow appending though and converts the new values to the endianness of the file if the typesizes match but the endianness of the file is different from the endianness of the machine wanting to append.

One thing it does not do yet is handling typesize mismatches upon reading a file that was written on a machine whose typesizes are different from the typesizes on the machine the file is read on.
This will be necessary though, because I still want to be able to read the data in that case, maybe into bigger sized value types.
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Sep 21, 2008 8:25 am    Post subject: Reply with quote

I resumed working on the basic engine framework this weekend and realized that I was having difficulties wrapping my head around it after such a long break (I also blame it on the unhealthy amounts of alcohol that I consumed over all those months which next-to-other-things certainly killed off a huge chunk of the code-fu in my head).

I did not add anything new but I refactored some of the stuff I already had to make it more simple. I noticed that two of my interfaces were identical(just a different name) so I got rid of one of them to simplify things.
The nice side-effect of that is that I can now attach a controller directly to the model without needing some weird in-between object anymore that would act as a messenger between controller and game model. (Now every game object is just a model too (submodel, part-model, whatever you want to call it conceptwise).)

I also re-implemented the views, so they're now using a common baseview class with the shared behaviour already implemented.

updated class diagram:


Next thing I'll have to do is finally get around to implementing a basic controller, so that I can grab input from at least keyboard and mouse, so that I can start making the editor for the planets.
_________________
0xDB


Edited by 0xDB on Sat Oct 09, 2010 7:20 am; edited 1 time
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Sep 28, 2008 11:12 am    Post subject: Reply with quote

Did not get much done this weekend codewise but even little progress is good progress I guess and I spent most of the time thinking about the controllers.

I started implementing basic controller logic that will be shared by all controllers and also started implementing an InputEvent class that will abstract all physical device input state information for the game model, so that I'll be able to have controller commands named like "PERFORMACTION1" or "ACCELERATE" that can be triggered by various state changes in actual physical input devices (for a start, I plan to support just Keyboard, Mouse and Joystick inputs).

Each InputEvent has a sourcedevice(mouse, keyboard, joystick), a sourcestate(some button, some axis, a certain key), some state variables and freely definable/combinable triggers that define what type of behaviour on the physical device state should trigger the command.

Example: There could be an action named SHOOT, which could be attached to a specific key on the keyboard, which would only be triggered if the specified key just changed its state from notbeingpressed to pressed (aka KeyDown).

For configuring actions, I will have a Factory class that will be able to detect events on physical devices and generate InputEvent instances accordingly.

Performance-wise, having clearly defined InputEvent with clearly defined physical device states triggering them, this should be better than polling all devices in every update, because I only need to poll the device state variables that are actually attached to any command.

The game will not have to know about the source that triggered the respective command to fire on a controller, which I think is nice to have as it allows even other game objects or 'whatever else' to function as controllers for any model/submodel.

It will also allow me to introduce more input devices later(should the need arise) without having to change the game logic to make them compatible.
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Nov 16, 2008 2:16 pm    Post subject: Reply with quote

Hm, time flies. It's been over a month already again. :o

Well my plans for this weekend were to look into doxygen, document all code I have so far, start implementing basic GUI stuff and then work on the planet map editor.

I've accomplished only the first task, so now all my code is nicely documented and doxygen also rendered fancy class and collaboration diagrammes which help me keep track of stuff.

My main reason for chosing to document everything was to get my mind back into the game, because for that task, I had to read through all the code again and it forced me to think about each and every class and method again to write proper docs.
So for once in history of development, NOT documenting something from the very beginning on, proved to be useful, as it gave me a good excuse to re-read all the code, so I feel ready now to continue the actual development after the long break.

So yeah, just hacking away the ice to revive this little project from its beauty sleep.
_________________
0xDB
View user's profile Send private message Visit poster's website
Madgarden
Contributor

Joined: 31 Aug 2005
Posts: 324
Location: Kitchener, ON, CA
PostPosted: Sun Nov 16, 2008 7:45 pm    Post subject: Reply with quote

Have you looked into APE or Box2D for physics?
_________________
I know it sounds crazy, but it JUST MIGHT WORK
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Mon Nov 17, 2008 6:38 am    Post subject: Reply with quote

I have not yet looked into any implementation details of the actual game logic.

What I want to do next is the GUI system, then a basic planet editor that allows me to define the shape of a planet as a 2D map and then I want to implement the two different projections of the planet surface data (for outer space view and for on planet view), because that seems to be the most interesting thing for me to do next.
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sat Oct 09, 2010 7:28 am    Post subject: Reply with quote

Hail thread-necromancy! (but well, this is the correct place to post this)

I hadn't thought it had already been two years since I last touched this project. It has always (really, almost every day) been in the back of my head. Funny enough, I can't remember what got me distracted in November 2008 that I stopped working on this for so long.



I have no intentions of actually focusing on working on this project very much in the near future but I intend to port (to Allegro5) and expand upon the basic framework that I had written for SpaceGame to then take that framework to make a different game first.
_________________
0xDB
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3776

PostPosted: Sat Oct 09, 2010 9:15 am    Post subject: Reply with quote

Sure a rewrite wouldn't be better? It's easy to forget how much we learn as time goes on. You may be able to write something far superior now instead of porting old code.
Than again, if this is something you've worked on for ages you might not have that kind of time. I know I wouldn't. But it's something to consider.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Oct 10, 2010 12:11 pm    Post subject: Reply with quote

I'm sure a rewrite would be a waste of time. Actually my C++Fu might have even gotten worse over the time due to all that funky C#/.NET code I spit out at the dayj0rb.

Also, there isn't that much code to port and I already ported most of it.
Past-me decided to decouple everything as much as possible from Allegro, so the roots of the third-party code did not grow very far into mine to begin with.

Well, currently I don't make much progress, because I keep stumbling over oddities and bugs in Allegro (but that's ok as I know it's not a final release yet and this way I find and report(sometimes even fix) problems which helps getting the library more stable and that somehow makes me happy).
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Oct 17, 2010 9:54 am    Post subject: Reply with quote

Finished porting everything this week (even though most of this weekend got wasted watching Star Trek Voyager).

Next I'll rip everything not specifically space-game related out of it and put it into a new template project which I will then flesh out to serve as a basic starting point for new game projects/small prototypes and tests.
_________________
0xDB
View user's profile Send private message Visit poster's website
xearthianx
Developer

Joined: 28 Sep 2006
Posts: 771
Location: USA! USA!
PostPosted: Mon Oct 18, 2010 12:53 pm    Post subject: Reply with quote

I was really impressed by the 4.9 preview releases from a while back (when they worked). Structure seemed clean and intuitive. I'm concerned about the changes in licensing though; last time I checked they hadn't worked all the details out.

What are your thoughts, after working with the new code base?
_________________
Ionoclast Laboratories - Scientia et Dominatia!
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Tue Oct 19, 2010 12:13 pm    Post subject: Reply with quote

Oh heh, I haven't even read the license yet. XD

My thoughts on the new API... well it doesn't really matter to me whether I have to do things one way or another.

My main motivation for changing to Allegro 5 was that it has builtin OpenGL support (no need for an extra addon (alleggl) anymore), so that's easier to set up and I kept procrastinating on learning OpenGL (and now I have no more excuses).

I like the new event system (which takes care of all the receiving/polling/translating of all sorts of input/display/system/whatnot events) and the state based drawing routines (much like old BGI from the pascal days, also comparable to the state based OpenGL API) although that can be irritating at first.

e.g. I was wondering why my app kept crashing after initialising some runtime-generated bitmap... it was because I forgot to set the target bitmap back to my display :P (quite silly and I didn't notice at first that there was in fact no target bitmap parameter to the drawing routines, you just set that by another function call and then all subsequent drawing routines know that (state based)).

I'm not actually using the input events though and it's still possible to poll the input state of the devices yourself (which I do, because I need some special state change logic to abstract physical device state/change sources from virtual events like "FIRE" "DOMAGIC", using my InputEvent class (described somewhere in this thread) and I also need (logical)frame-exact device states (actually I only have a gut feeling I will need those)).
_________________
0xDB
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4998
Location: Silicon Valley!
PostPosted: Tue Oct 19, 2010 6:56 pm    Post subject: Reply with quote

Ever thought of dumping Allegro? It took me over a month to do so with my project, but I'm kind of glad I did. There's not much I really miss other than the ability to super-quickly get stuff on the screen for prototyping purposes. Once you build up your own shell to do that, said benefit doesn't hold much weight.
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Tue Oct 19, 2010 9:57 pm    Post subject: Reply with quote

Another vote for dumping Alleg. Their like 10 years behind being relevant.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Wed Oct 20, 2010 10:11 am    Post subject: Reply with quote

I see no good reason to switch away from Allegro. It provides me with everything I need (except networking but there will be other libs for that but I don't need that for the little game I've planned to do next).

Allegro 5 is not directly comparable to the old Allegro (which I assume you're targeting with "10 years behind being relevant").
DOS support has been completely dropped for example and the new API is (well just different but also more cleanly structured http://docs.liballeg.org/index.html ).
As for being modern/relevant.. there is an iPhone Version of Allegro 5 (I don't know how feature complete it is since I don't do iPhone dev).

Depending on which addons (standard addons come with the library but are still implemented as addons, because not every app needs all of them I think) you use, there is also support for loading and rendering true type fonts (bitmap fonts too) and for accessing a few different pak file formats (including zip) using PhysFS (which also supports path virtualization, e.g. you throw a bunch of different packfiles, directories and whatnot in and you can access them all through the same virtual path in your code).

It's possible to write all rendering code in plain OpenGL (and still have the option to use Allegros methods for rendering stuff to the same displays/windows/bitmaps (also supports multiple windows now)).

The library also has some stuff that I'll probably not use, but has everything I need to keep my games easily portable (as easy as recompiling the same sourcecode in a different dev environment) and relatively easy to develop.

Time and ease of use is also a factor. Time is extremely scarce and I just don't have the time(and/or motivation) to write my own framework for each of the systems I intend to target (Windows and Linux mainly).

A few years ago, I had started to write my own platform independent framework and I started with the Windows version of it (using Win32 API and DirectX 7), I don't remember exactly how much I had already done (judging from the header files, I just examined though, it seems I had already written a large portion of what I'd need: atomic types, datafileclass, (bitmap)fonts(with an oldschool gradient rendering option), gfxfiles, memory, sprites, surfaces (to abstract from directx surfaces, keeping in mind portability)... seems I even already had my own generic list container class) but I think I eventually reached a point where I found that it was a waste of time to continue its development (or maybe I just ran out of time or there were other life problems distracting me) since I could just use Allegro, which already has all that stuff ready to use and for a wide range of different platforms too.
_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Wed Oct 20, 2010 12:00 pm    Post subject: Reply with quote

A tool is a tool; if you're highly productive with it, rather than in spite of it, you're using a decent tool. I think the "ten years behind" comment spawned from looking at where other libs were a decade ago. I see Allegro 5 aiming below the curve rather than ahead... so the group is eternally playing catch-up instead of trying to predict where development needs will be in five years and aim for that.

I've also heard it suggested that Allegro drop 3D entirely and aim to be a high performance raster-based library. I can't disagree with that; it's a niche that needs to be filled.

I'll stick with Allegro 4.x for my next few projects. Getting A5 to work would require a particularly large rewrite of my framework.
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4998
Location: Silicon Valley!
PostPosted: Wed Oct 20, 2010 3:24 pm    Post subject: Reply with quote

I dumped it because of shearing issues and always eating 100% CPU. My assumption was that these issues still haven't been fixed. As you can tell, I don't have a lot of faith. ;]
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Thu Oct 21, 2010 12:09 pm    Post subject: Reply with quote

I just had a crazy idea: lesbian space amoebae!
_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Thu Oct 21, 2010 12:11 pm    Post subject: Reply with quote

Did someone say lesbians?
View user's profile Send private message Visit poster's website
xearthianx
Developer

Joined: 28 Sep 2006
Posts: 771
Location: USA! USA!
PostPosted: Fri Oct 22, 2010 8:20 am    Post subject: Reply with quote

sonrisu wrote:
I dumped it because of shearing issues and always eating 100% CPU. My assumption was that these issues still haven't been fixed. As you can tell, I don't have a lot of faith. ;]

I dunno, man... I'm on a Mac, and a simple combination of offscreen drawing, vsync and judiciously yielding the CPU solved all those for me.
_________________
Ionoclast Laboratories - Scientia et Dominatia!
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Fri Oct 22, 2010 8:28 am    Post subject: Reply with quote

It was a long time ago, but I ran in to the same shearing issue on PC (vsync was emulated, not actually supported). I had to refresh my game faster than 60 fps to avoid the issue.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Oct 24, 2010 5:59 am    Post subject: Reply with quote

Sirocco wrote:
Did someone say lesbians?
:D

This weekend wasn't as productive as it could have been. Spent the majority of Saturday setting up my development environment on my old machine here (parents house) and then just fixed a couple of minor issues (one of them being CPU at 99% all the time, due to redrawing everything all the time even if the game was paused, now down to 20% - 30% simply by limiting the FPS and letting the main thread sleep longer if no game-logic updates need to be performed (pretty basic stuff ya, dunno how I could forget about implementing it in this iteration of the framework, probably accidentally axed it in the porting process)).

I shall be more productive when I'm back at my main machine.

Plan for next weekend is to go through this thread, collect all the information I wrote two years ago and consolidate it into a single design document and then expand upon that over the next few weeks, just writing down ideas, sorting subsystems, doing concept sketches and a lot of daydreaming.

Listening to the new Iron Maiden album "The Final Frontier" has inspired me to work on this again.

The design document currently only contains this ASCII header (I decided to just keep the name Spacegame):
Code:

      __________  ____  ____ ________   ____  ______  _____
     / ____/ __ \/ __ \/ __// ___/ __\_/ __ \/ _  _ \/ ___/
* ___\__ \/ ____/ __  / /__/ ___/ /_  / __  / // // / ___/___ *
  \______/\/    \/  \/\___/\___/\____/\/  \/\/ \/ \/\_______/

(wow, that looks really shitty in the code tag, due to the line spacing,font and the html pre element does not seem to work)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Tue Oct 26, 2010 12:21 pm    Post subject: Reply with quote

While I'm thinking about stuff (almost every waking hour and sometimes even in my sleep), I've found a minor flaw in the control scheme.

back then, I had though up this:
http://www.dennisbusch.de/shared/sp_05.png

I still think it's fine for the most part, except for "C" on the Player controls being the key to open the inventory. That's nonsense. "C" should be the "jump" button. The inventory can just always be the first entry in the action menu.

Also, I thought about the action menu... it needs a little modification. Previously I thought it would have to show the actions available for the nearest interactive object, now screw that, it will have to show the actions for ALL nearby interactive objects. And those objects should be able to expose their available actions quite easily either by using my model to model messaging system or some standard interface that is yet to be defined. The action menu wouldn't have to show all actions in a single list though, there could(and should) be little arrows in the title bar of the menu, indicating that there are other interactive objects nearby to which the player can switch and they should get marked visually as the target for the selected action (e.g. a green box around a door keypad and actions for pressing buttons on the pad or even better for accessing the pad and then press the buttons in an interactive display where they can be selected with a cursor).

I'm also considering changing the messaging system. It's highly flexible as it is, as I'm just passing around strings but I'm a bit worried this might become a performance problem with many objects and message emitters which may fire their message somewhere, causing thousands of objects receiving it (e.g. huge explosion in a horde of space cabbage munching sabertooth hamsters). So I might want to have a few standard messages (hardcoded) for these cases with tightly packed parameters that don't need to be parsed first.

Still want to keep the string messages though for flexibility and for some easy to tag on scripting possibilities and an in-game console circulating around somewhere in the back of my head.
_________________
0xDB
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Space Game Page Previous  1, 2, 3, 4, 5  Next

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.